Show HN: Drop-in SQS replacement based on SQLite

Original Article ↗ Hacker News Discussion ↗

A new open source project, SmoothMQ, aims to be a drop‑in, self‑hosted replacement for Amazon SQS by implementing the SQS HTTP API on top of a single Go binary backed by SQLite. Commenters are enthusiastic about its simplicity for local development, testing, and small deployments, but raise questions about high‑availability, distributed operation, and whether it can realistically compete with SQS’s scale, reliability, and already low pricing. Much of the debate centers on trade‑offs around the AGPL license, potential monetization, and the broader appeal of lightweight, self‑managed infrastructure versus fully managed cloud services.

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.