Scaling Postgres to 1M durable workflows per second
Comments on “Scaling Postgres to 1M durable workflows per second”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
DBOS reports scaling its Postgres-backed durable workflow engine from 20K workflows/sec on one server to 1M on 50 RDS shards, using the PgDog sharding router. Past roughly 8-16 shards, dequeueing hit a feedback loop: slow shards attracted more concurrent pollers, and lock contention made them slower. Per-shard advisory-lock limits fixed it. The figures come from DBOS's own benchmark of no-op workflows with no steps, and the claim check could not independently confirm them. The code is open-source.
Why it ranked
No. 19 of 127 with a score of 0.64. The panel rated it highest on new information (0.92) and technical depth (0.82), lowest on audience breadth (0.53). Placed No. 19, No. 50 by score alone: the placement terms moved other stories past it.
- AI judgeJudge 2claude-haiku-5-5
- Solid engineering writeup on sharding Postgres for durable workflows with concrete benchmark setup and metastability analysis; vendor-adjacent but substantive, relevant to database and infrastructure builders.
- AI judgeJudge 3gpt-5.6-luna
- A detailed, reproducible engineering write-up with benchmark parameters, architecture, failure analysis, and a concrete stabilization technique. It is highly actionable for Postgres, workflow, and infrastructure builders, though results depend on a narrowly optimized workload and include a modest product pitch.
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.60
- Reader interest0.77
- Audience breadth0.53
- Practical relevance0.78
- Substantiated0.76
- Technical depth0.82
- New information0.92
- Counts against: Promotional0.26
- Counts against: Overclaim0.24
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.57 | 0.50 | 0.72 | 0.60 | 0.22 | +0.24 | +0.143 |
| Reader interestWould a well-informed senior engineer or tech founder want to read this today, and likely pass it on? | 0.62 | 0.80 | 0.90 | 0.77 | 0.28 | +0.26 | +0.201 |
| Audience breadthHow many people who build technology does it concern? | 0.52 | 0.50 | 0.58 | 0.53 | 0.08 | +0.13 | +0.069 |
| Practical relevanceHow useful is it to someone who builds software or tech products? | 0.80 | 0.70 | 0.85 | 0.78 | 0.15 | +0.22 | +0.172 |
| 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.84 | 0.60 | 0.84 | 0.76 | 0.24 | +0.05 | +0.038 |
| Technical depthHow technically substantive is it? | 0.88 | 0.75 | 0.82 | 0.82 | 0.13 | +0.05 | +0.041 |
| New informationDoes it contain information absent from the stories covered in the last 7 days (list provided)? | 0.88 | 0.90 | 0.98 | 0.92 | 0.10 | +0.05 | +0.046 |
| 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.14 | 0.35 | 0.28 | 0.26 | 0.21 | −0.19 | −0.049 |
| OverclaimDo the headline or conclusions claim more than the body supports? | 0.24 | 0.30 | 0.18 | 0.24 | 0.12 | −0.11 | −0.026 |
| Sum of contributions | +0.635 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.635 | ||||||
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-10-30/19/"><img src="https://rubric.hrih.si/badge/2026-10-30/19.svg" alt="Ranked #19 on Rubric, 30 Oct 2026" width="245" height="28"></a>Claim check
Claim check: 1 matches source · 4 no source given · 3 couldn’t check. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
Couldn’t checkBenchmark result
By sharding durable workflows with PgDog, DBOS linearly scaled workflow throughput from 20K workflows/sec on one Postgres server to 1M workflows/sec on 50 Postgres servers.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “we linearly scaled durable workflow throughput from 20K workflows/sec with one Postgres server to 1M workflows/sec with 50 Postgres servers”
The source says No passage could be compared.
Source cited by the article: github.com/dbos-inc/dbos-postgres-benchmark
Couldn’t checkNumber
Each shard in the benchmark was a db.m7i.4xlarge RDS Postgres instance with 16 cores and 64 GB of RAM.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “Each shard is a db.m7i.4xlarge RDS Postgres with 16 cores and 64 GB of RAM”
The source says No passage could be compared.
Source cited by the article: github.com/dbos-inc/dbos-postgres-benchmark
Couldn’t checkNumber
The benchmark launched 48 worker processes per shard, totaling 2400 worker processes at 50 shards.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “We launch 48 worker processes per shard, for a total of 2400 worker processes at 50 shards”
The source says No passage could be compared.
Source cited by the article: github.com/dbos-inc/dbos-postgres-benchmark
No source givenNumber
20K workflows/sec is the maximum sustainable throughput of a single shard.
The article gives no link or citation for it.
The article says “20K workflows/sec is the maximum sustainable throughput of a single shard”
The source says No source to compare with.
Matches sourceNumber
A single Postgres database can handle tens of thousands of operations per second.
The cited source says the same thing.
The article says “a single Postgres database can get you remarkably far, handling tens of thousands of operations per second”
The source says “a single server can support a sustained throughput of 144K writes per second, or process 43K workflows per second”
Source cited by the article: dbos.dev/blog/benchmarking-workflow-execution-scalability-on-postgres
No source givenNumber
In initial tests, sharded workflow performance became metastable beyond roughly 8-16 shards (~200K workflows/sec), collapsing cluster-wide if any shard was perturbed, such as by a large VACUUM.
The article gives no link or citation for it.
The article says “past a certain point (roughly 8-16 shards, or ~200K workflows/sec), performance was metastable”
The source says No source to compare with.
No source givenCausal conclusion
The metastability was caused by a negative feedback loop in dequeueing: slower dequeue queries led more processes to dequeue concurrently, causing lock contention that made queries slower still.
The article gives no link or citation for it.
The article says “The reason for this metastability was a negative feedback loop in dequeueing workflows”
The source says No source to compare with.
No source givenCausal conclusion
Limiting concurrent access to each shard with Postgres advisory-lock-based dequeue locks broke the feedback loop and allowed stable scaling to 1M workflows/sec.
The article gives no link or citation for it.
The article says “This design prevents a single shard from being overwhelmed, breaking the feedback loop and allowing stable scaling to 1M workflows/sec”
The source says No source to compare with.
Also covered by
No other coverage was clustered with this story.
Elsewhere
Elsewhere: HN 3 pts, not on front page
Recorded for context only, checked 30 Oct 2026, 05:47 UTC. It played no part in the ranking.