
Postgres SKIP LOCKED: A Job Queue Without Redis
Summary
Build a reliable production job queue using only Postgres FOR UPDATE SKIP LOCKED.
Every backend eventually needs a job queue: send the welcome email, transcode the video, run the nightly report, retry the failed webhook. The default reach is Redis with BullMQ, Sidekiq, or RQ. That works, but it adds a second stateful system to operate, a second source of truth for data that almost certainly lives in your Postgres database already, and a whole new failure mode where the job got enqueued but the row didn't commit.
Postgres has a feature called FOR UPDATE SKIP LOCKED, added in 9.5, that lets you build a real, production-grade work queue using a single table. No Redis. No broker. Same transaction semantics as your business data. In this guide you will build one from scratch, harden it with a visibility timeout, add retries with exponential backoff, recover stuck jobs, partition for retention, and benchmark it. By the end you will know exactly when to reach for this pattern and when to stick with a dedicated broker.
Keep reading — it's free
Enter your email to keep reading — plus the best of AI & tech, daily. Free, forever.
Already a member? Sign in
Comments
Be the first to comment