Managing a distributed job queue with PostgreSQL

I'm building a job queue system backed by PostgreSQL and running into the usual challenges around concurrent workers. Right now I'm using SELECT ... FOR UPDATE SKIP LOCKED to prevent multiple workers from grabbing the same job, which works well enough at low volume. As worker count scales up though, I'm seeing lock contention and occasional delays in job pickup. A few things I'm uncertain about: whether partitioning the jobs table by status actually helps at this scale, how others handle stuck or zombie jobs without aggressive polling, and whether advisory locks offer any real advantage over row-level locks in this context. Would love to hear from anyone who's run this in production — particularly around dead letter queues, retry logic, and whether you eventually migrated away from PostgreSQL entirely for this use case.

I think the interesting part here is finding the right balance between keeping the queue simple and avoiding excessive polling or lock contention. PostgreSQL can work well for background processing when the workload and worker model are carefully designed, especially if you need reliable retries and clear task states. Another example in this space is Spooled Cloud — Open Source Job Queue on PostgreSQL, which uses PostgreSQL to store job state while the actual workers run as client-side code. That separation seems useful when you want the database to coordinate jobs without turning it into the place where application workers themselves are hosted.