Show HN: Drop-in SQS replacement based on SQLite

Original Article ↗ Hacker News Discussion ↗

Licensing and Monetization

  • Project is AGPL-licensed, prompting debate:
    • Some dislike AGPL “on principle,” preferring MIT and arguing it discourages commercial adoption and proprietary integration.
    • Others argue AGPL best preserves openness, ensures improvements flow back, and doesn’t block monetization—only requires publishing modifications.
  • Monetization plans are unclear; ideas include a hosted service with multi-tenancy and billing, but the current focus is on “scratching an itch,” not a polished business model.
  • Discussion about whether every OSS project needs a business model and whether talking about monetization is appropriate or expected on HN.

Use Cases and Target Scenarios

  • Strong interest for:
    • Local development and functional testing as an SQS-compatible mock (alternative to LocalStack/ElasticMQ).
    • Simple self-hosted queues for small teams, on-prem / private cloud, k8s/k3s deployments, and edge/“local-first” workloads.
  • Some see potential as an operationally “smarter” queue: built-in rate limiting, routing, per-partner throttling, observability, and admin tooling, reducing bespoke ops work.

Comparison to SQS and Other Queues

  • Many note SQS is already very cheap and highly engineered, globally available, and HA; hard to compete purely on cost.
  • Others report bills where SQS costs exceed the servers doing the work at very high volumes.
  • Alternatives discussed: RabbitMQ/AMQP, Kafka, Redis Streams, beanstalkd, filesystem-based queues, ElasticMQ, and another SQLite-based queue prototype.

Technical Design, Distribution, and Reliability

  • Current design: single Go binary using SQLite; SQS-compatible HTTP API only; SigV4 signing handled server-side.
  • SQLite praised as rock-solid and widely deployed; objections that “single node SQLite” sounds less “production” than AWS SQS.
  • No distributed implementation yet:
    • High-level idea: mostly independent nodes, minimal coordination, queue metadata shared; possible use of S3/Dynamo, rqlite, libsql, Litestream, etc.
    • Critics say distributed semantics, at-least-once guarantees, FIFO, replication, and failure handling are being hand-waved.
  • Implementation details:
    • Foreign keys disabled for performance; cascading deletes handled manually in transactions.
    • Future thoughts of mixing backends (SQLite, RocksDB, DuckDB) for performance and analytics.

UX, Code Quality, and Tooling

  • Suggestions: compatibility/feature table vs SQS, example apps, testcontainers support, richer UI metrics, better number alignment.
  • Codebase praised as small, readable Go; some guidance offered on more idiomatic Go packaging.