One incident instead of two: what SKIP LOCKED actually buys you

The unit of accounting here is the dead tuple. Claiming a job is an update, completing it is an update, retrying it is another, and Postgres writes a new row version for each one ^[2]. That makes the jobs table the highest-churn object in a schema whose other tables are mostly read. At the ceiling the cited benchmark reports, about 660 messages a second ^[5], even a minimal two updates per job puts roughly 1,320 dead row versions a second in front of autovacuum ^[14]. Gunnar Morling's argument, in his November 3, 2025 piece, is that vacuum eventually loses that race and the WAL piles up behind it ^[8]. Brandur Leach, formerly a staff engineer at Stripe, describes the same end state as table bloat, index fragmentation and autovacuum starved of room ^[7]. The vacuum budget and the WAL are not queue resources. They are the customer's.

The throughput gap is the headline number, and it is the less interesting one. RabbitMQ moved 25,000 messages a second in the same test environment ^[9], about 38 times as much ^[12]. The comparison worth sitting with is FIFO SQS, the deliberately capped managed option at 3,000 messages a second ^[10]: still roughly four and a half times the Postgres figure ^[13]. The complexity being avoided is a queue URL.

Recovery is where the shared substrate actually bills you. AWS engineers described the loop in a December 17, 2021 Architecture Blog post: a stalled delivery process pushes backpressure onto the database, which produces more failed work ^[11]. A broker backlog is drained by adding consumers. A bloated jobs table is drained by vacuum, which needs the write rate to fall, which needs the workers to back off, which is the opposite of what a retry loop does. Meanwhile every worker node holds a connection, and Postgres forks an OS process per connection, so polling workers churn through the pool that user-facing queries are drawing from ^[3].

The evidence for the throughput half of this case is thin: one benchmark, one date, one payload size, 38ms at P95 ^[5], with no methodology quoted. Hardware and batching would move that figure a long way. The coupling half needs no benchmark, and the article's own carve-out is the useful sentence in it: sporadic background work at low rates is fine, and the failure is assuming that behaviour survives production volume ^[4]. So the threshold is a metric, not an architecture. Watch dead tuples and vacuum lag on the jobs table against the rest of the schema, and answer the question the piece poses directly, which is whether your database goes down when your queue does ^[6].