Your app stores its data in SQLite (or Postgres). Now you need a background job queue — send the welcome email, resize the upload, fire the webhook — and the reflex answer is automatic: "add Redis, and Celery or Sidekiq or BullMQ on top."
That works. It also adds a whole second datastore to your system: another thing to run, back up, monitor, and reason about. And it quietly introduces a correctness bug that's easy to miss. For a surprising number of apps, there's a simpler answer that's also more correct: put the queue in the same database, as a table. Here's how that works, why it's safer than a separate queue, and where you genuinely do still want Redis.
The hidden bug in a separate queue
Picture the normal flow. A user places an order, so you do two things: write the order to your database, and push an "send confirmation email" job onto Redis.
INSERT order into the database ← step 1
