Keep the Queue in the Same Database as Your Business Writes

A common architectural pattern places the application's primary data in one store (typically Postgres or SQLite) and the background-job queue in a separate broker (Redis, RabbitMQ, SQS). The pattern looks clean on paper and falls apart on a specific failure mode: the enqueue completes but the business write rolls back, or vice versa, leaving either an orphan job processing a row that doesn't exist or a row whose follow-up work never runs. The failure is silent and timing-dependent, which makes it expensive to track down. Typical mitigation strategies — adding retry logic, polling on the worker side, moving the enqueue inside a database trigger — gradually reconstruct, with more moving parts, the property that an in-database queue gives for free: enqueue and business write share a single ACID transaction, so a rollback drops both atomically. This is the engineering argument behind Postgres-side libraries like Oban and pg-boss (which sit in the same database as application tables) and the SQLite-side equivalent Honker: SQLite Extension for NOTIFY/LISTEN, Task Queues, and Cron in One .db File (which puts the queue rows in the same `.db` file). The pattern generalizes beyond queues. Anything that needs to be "transactionally consistent with the business write" — outbox tables for downstream messaging, idempotency keys, audit logs, scheduled tasks — benefits from living in the same database. The dual-write problem between two independent datastores is one of the more painful classes of distributed-systems bugs, and the cleanest mitigation is usually to remove the second datastore from the critical path. The corollary is that the right queue is the one that lives in the database you already chose for application data. Postgres-primary stacks should reach for Oban or pg-boss; SQLite-primary stacks (edge deployments, Turso, LiteFS, single-binary tools) gain a similar option in Honker.