Task Queues on SQLite vs Postgres: Landscape Comparison (2026)

Durable task queues built on top of relational databases avoid the operational cost of running a dedicated broker like Redis or RabbitMQ. The Postgres side is mature and converged on two gold-standard implementations; the SQLite side is younger and more fragmented. **Postgres-backed queues**: Oban (Elixir / Ecto) and pg-boss (Node / Knex) are production-grade and use LISTEN/NOTIFY for sub-second job dispatch with built-in cron scheduling. River (Go / sqlx) is also production-ready but uses polling rather than LISTEN/NOTIFY. **SQLite-backed queues**: - Huey (Python only, by Charles Leifer) is mature with roughly 5,000 stars, supports cron, but has no cross-process notify and no ORM compatibility. - LiteQueue (from the litements project) is a minimal Python queue with no cron, streams, or notify. - liteq (Go only) is a maintained but bare queue. - BlockQueue (Go only) adds notify via NutsDB as a second dependency. - Honker: SQLite Extension for NOTIFY/LISTEN, Task Queues, and Cron in One .db File is the most ambitious entrant — eight language bindings, 1 ms cross-process notify, durable streams, ORM compatibility — but only ten days old at the time of writing and explicitly labelled experimental. The practical implication: if Postgres is already in the stack, Oban or pg-boss remain the default and Honker is not a reason to migrate. The relevant audience is projects where SQLite is the primary datastore — edge deployments on Turso or LiteFS, single-binary CLI tooling, the Bluesky PDS architecture — where introducing Postgres just for the queue contradicts the deployment model. Postgres 19 adds an optimization to LISTEN/NOTIFY that fixes long-standing scaling problems with many channels, which strengthens the case for staying on the Postgres side wherever Postgres is already present.