Just how far can the FOR UPDATE SKIP LOCKED Postgres queue go?
Comments on “Just how far can the FOR UPDATE SKIP LOCKED Postgres queue go?”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
A garbage collected benchmark of a FOR UPDATE SKIP LOCKED job queue on Postgres 18, capped at 1 CPU, found throughput peaking near 375 jobs/s at 64 workers, before the 100 connection slots filled. CPU hit 86% while memory stayed well under the cap. At 128 workers throughput fell to about 200 jobs/s and 29 workers failed to connect. A shared pool of 20 connections reached 652 jobs/s, though the client process may have been a limit. It is a single run with simulated 100ms jobs.
Why it ranked
No. 14 of 107 with a score of 0.64. The panel rated it highest on technical depth (0.87) and substantiated (0.84), lowest on significance (0.46). Placed No. 14, No. 30 by score alone: the placement terms moved other stories past it.
- AI judgeJudge 2claude-haiku-5-5
- Practical, measured benchmark of Postgres SKIP LOCKED queue limits with clear data and pooling comparison, though single-run, single-CPU scope limits generality and significance.
- AI judgeJudge 3gpt-5.6-luna
- A practical, technically detailed Postgres queue load experiment with reproducible SQL, worker code, measurements, bottleneck analysis, and pooling results. Its scope is narrower than landmark research, and conclusions are appropriately caveated.
Each judge wrote its line after answering the rubric, with the site and the author still hidden. Every answer behind this is in the table under Score.
Score
0.64total under rubric v2.3
- Significance0.46
- Reader interest0.74
- Audience breadth0.53
- Practical relevance0.78
- Substantiated0.84
- Technical depth0.87
- New information0.79
- Counts against: Promotional0.04
- Counts against: Overclaim0.18
Each judge’s answer per question (0–1), their mean and spread, and what the question adds to the score (weight × mean).
| Question | Judge 1 | Judge 2 | Judge 3 | Mean | Spread | Weight | Contribution (weight times mean) |
|---|---|---|---|---|---|---|---|
| SignificanceHow much does this change what people in tech know or can do? | 0.50 | 0.30 | 0.58 | 0.46 | 0.28 | +0.24 | +0.111 |
| Reader interestWould a well-informed senior engineer or tech founder want to read this today, and likely pass it on? | 0.67 | 0.70 | 0.86 | 0.74 | 0.19 | +0.26 | +0.193 |
| Audience breadthHow many people who build technology does it concern? | 0.48 | 0.50 | 0.62 | 0.53 | 0.14 | +0.13 | +0.069 |
| Practical relevanceHow useful is it to someone who builds software or tech products? | 0.86 | 0.70 | 0.78 | 0.78 | 0.16 | +0.22 | +0.171 |
| SubstantiatedHow well is it backed? Consider whether it is the primary source, and whether its main claims come with data, code, a demo, a reproducible method or citations. | 0.97 | 0.70 | 0.84 | 0.84 | 0.27 | +0.05 | +0.042 |
| Technical depthHow technically substantive is it? | 1.00 | 0.85 | 0.77 | 0.87 | 0.23 | +0.05 | +0.044 |
| New informationDoes it contain information absent from the stories covered in the last 7 days (list provided)? | 0.83 | 0.60 | 0.93 | 0.79 | 0.33 | +0.05 | +0.039 |
| PromotionalIs it mainly marketing with little substance (a press release, ad or sponsored post with no real information)? A launch post that carries real news is not promotional. | 0.04 | 0.05 | 0.04 | 0.04 | 0.01 | −0.19 | −0.008 |
| OverclaimDo the headline or conclusions claim more than the body supports? | 0.20 | 0.25 | 0.08 | 0.18 | 0.17 | −0.11 | −0.019 |
| Sum of contributions | +0.642 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.642 | ||||||
Spread is the highest minus the lowest judge answer. marks a spread above 0.40: the judges disagree, and the story is marked contested.
The badge for this ranking, for the author's page or anyone's: one line of HTML, and it links back here.
<a href="https://rubric.hrih.si/editions/2026-11-07/14/"><img src="https://rubric.hrih.si/badge/2026-11-07/14.svg" alt="Ranked #14 on Rubric, 7 Nov 2026" width="238" height="28"></a>Claim check
Claim check: 8 no source given. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
No source givenNumber
On a Postgres instance capped at 1 CPU, the FOR UPDATE SKIP LOCKED queue's throughput peaked at about 375 jobs per second with 64 workers.
The article gives no link or citation for it.
The article says “stalls at around 375 jobs per second at 64 workers, before the 100 connection slots, which is Postgres' default, are even used up”
The source says No source to compare with.
No source givenNumber
At 128 workers without pooling, throughput fell to around 200 jobs per second and 29 workers could not connect.
The article gives no link or citation for it.
The article says “At 128 workers it falls to around 200 jobs per second, and 29 of them couldn't connect at all”
The source says No source to compare with.
No source givenBenchmark result
Median query time rose from 8ms to 45ms between 32 and 64 workers, and p99 latency rose from 25ms to 393ms, then to 1.6s at 128 workers.
The article gives no link or citation for it.
The article says “from 8ms to 45ms, and p99 latency climbs even quicker, from 25ms to 393ms, then to 1.6s at 128 workers”
The source says No source to compare with.
No source givenNumber
Postgres's single CPU was at 86% at 64 workers and 100% at 128 workers, while memory never came close to the cap, peaking at around 560MB of 1GB.
The article gives no link or citation for it.
The article says “Postgres's one CPU was at 86% at 64 workers and 100% at 128. Memory, on the other hand, was never close to the cap”
The source says No source to compare with.
No source givenCausal conclusion
Throughput stalled because CPU ran out, with connections contending for the same CPU, the write-ahead log and the same few pages, not because connection slots or memory ran out.
The article gives no link or citation for it.
The article says “past a point, adding workers just adds more connections fighting over the same CPU, the same log and the same handful of pages”
The source says No source to compare with.
No source givenBenchmark result
With a shared pool of 20 connections, 128 workers achieved 652 jobs per second instead of 208, and p99 fell from 1.6s to 360ms.
The article gives no link or citation for it.
The article says “With the pool, 128 workers managed 652 jobs per second instead of 208, p99 fell from 1.6s to 360ms, and every worker got the connection it needed”
The source says No source to compare with.
No source givenNumber
Connection memory private to Postgres connections grew from 11MB with one worker to 183MB with around 100 connections, roughly 2MB per connection.
The article gives no link or citation for it.
The article says “from 11MB with one worker to 183MB with around 100 connections, so roughly 2MB a connection”
The source says No source to compare with.
No source givenNumber
At 64 workers the most common wait event was LWLock:WALWrite, and at 128 workers LWLock:BufferContent took over with 24 connections waiting at a time.
The article gives no link or citation for it.
The article says “At 64 workers, the most common wait was LWLock:WALWrite”
The source says No source to compare with.
Also covered by
No other coverage was clustered with this story.
Elsewhere
Elsewhere: HN 1 pts, not on front page
Recorded for context only, checked 7 Nov 2026, 05:47 UTC. It played no part in the ranking.