Postgres 19 REPACK: Built-In Online Table Bloat Cleanup
Comments on “Postgres 19 REPACK: Built-In Online Table Bloat Cleanup”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
Postgres 19 adds a built-in REPACK command. REPACK (CONCURRENTLY) rebuilds a bloated table using logical decoding, with no extension, while it stays readable and writable. In Craig Kerstiens' Snowflake blog test, a 493 MB table shrank to 228 MB in 9.4 seconds, against 2.7 seconds for the locking VACUUM FULL. The timings come from one constrained system, and the claim that the overhead ratio holds on faster hardware is unsourced. Limits include a primary key requirement, no partitioned tables, 2x disk space and incomplete MVCC safety.
Why it ranked
No. 19 of 137 with a score of 0.64. The panel rated it highest on new information (0.93) and technical depth (0.89), lowest on audience breadth (0.52). Placed No. 19, No. 35 by score alone: the placement terms moved other stories past it.
- AI judgeJudge 2claude-haiku-5-5
- Practical, detailed tutorial on Postgres 19's built-in online REPACK feature with reproducible commands and measurements; useful to database builders, though a single-database-engine topic with modest significance.
- AI judgeJudge 3gpt-5.6-luna
- A highly actionable, technically detailed explanation of a major PostgreSQL maintenance feature, with SQL, operational constraints, performance measurements, and comparisons. Confidence is reduced by limited primary-source evidence and potentially speculative release details.
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.62
- Reader interest0.69
- Audience breadth0.52
- Practical relevance0.80
- Substantiated0.58
- Technical depth0.89
- New information0.93
- Counts against: Promotional0.06
- Counts against: Overclaim0.33
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.62 | 0.45 | 0.78 | 0.62 | 0.33 | +0.24 | +0.148 |
| Reader interestWould a well-informed senior engineer or tech founder want to read this today, and likely pass it on? | 0.57 | 0.60 | 0.90 | 0.69 | 0.33 | +0.26 | +0.179 |
| Audience breadthHow many people who build technology does it concern? | 0.49 | 0.50 | 0.58 | 0.52 | 0.09 | +0.13 | +0.068 |
| Practical relevanceHow useful is it to someone who builds software or tech products? | 0.71 | 0.80 | 0.88 | 0.80 | 0.17 | +0.22 | +0.175 |
| 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.55 | 0.60 | 0.58 | 0.58 | 0.05 | +0.05 | +0.029 |
| Technical depthHow technically substantive is it? | 0.99 | 0.80 | 0.88 | 0.89 | 0.19 | +0.05 | +0.045 |
| New informationDoes it contain information absent from the stories covered in the last 7 days (list provided)? | 0.92 | 0.90 | 0.98 | 0.93 | 0.08 | +0.05 | +0.047 |
| 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.09 | 0.05 | 0.04 | 0.06 | 0.05 | −0.19 | −0.011 |
| OverclaimDo the headline or conclusions claim more than the body supports? | 0.40 | 0.25 | 0.34 | 0.33 | 0.15 | −0.11 | −0.036 |
| Sum of contributions | +0.643 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.643 | ||||||
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-04/19/"><img src="https://rubric.hrih.si/badge/2026-11-04/19.svg" alt="Ranked #19 on Rubric, 4 Nov 2026" width="238" height="28"></a>Claim check
Claim check: 2 matches source · 6 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 givenCausal conclusion
pg_squeeze was developed by CYBERTEC, the same team behind much of the Postgres 19 REPACK work.
The article gives no link or citation for it.
The article says “from CYBERTEC, the same team behind much of the Postgres 19 REPACK work”
The source says No source to compare with.
Matches sourceVersion
pg_squeeze uses WAL-based logical decoding to capture concurrent changes without triggers, the same approach used by Postgres 19's built-in REPACK (CONCURRENTLY).
The cited source says the same thing.
The article says “This is the same approach that PG 19's built-in REPACK (CONCURRENTLY) now uses”
The source says “we use [logical decoding][4] instead of triggers to capture concurrent changes”
Source cited by the article: github.com/cybertec-postgresql/pg_squeeze
Matches sourceVersion
pg_repack creates a log table and installs triggers on the target table to capture INSERT/UPDATE/DELETE operations during the rebuild.
The cited source says the same thing.
The article says “It creates a log table and installs triggers on your target table to capture all INSERT/UPDATE/DELETE operations during the rebuild”
The source says “create a log table to record changes made to the original table - add a trigger onto the original table, logging INSERTs, UPDATEs and DELETEs into our log table”
Source cited by the article: reorg.github.io/pg_repack
No source givenNumber
In the author's test, REPACK (CONCURRENTLY) shrank a table from 493 MB to 228 MB (54% reduction) in about 9.4 seconds.
The article gives no link or citation for it.
The article says “Before: 493 MB → After: 228 MB (54% reduction”
The source says No source to compare with.
No source givenBenchmark result
In the author's test on a 493 MB table, VACUUM FULL took 2.7s, REPACK 5.9s and REPACK (CONCURRENTLY) 9.4s.
The article gives no link or citation for it.
The article says “REPACK (CONCURRENTLY) 9.4s 228 MB Yes (brief lock at end only”
The source says No source to compare with.
No source givenGeneralization
REPACK CONCURRENTLY overhead is roughly 1.5x to 2x the basic REPACK time, and the ratio holds on faster production hardware.
The article gives no link or citation for it.
The article says “The CONCURRENTLY overhead is roughly 1.5x to 2x the basic REPACK time”
The source says No source to compare with.
No source givenCausal conclusion
REPACK CONCURRENTLY is not fully MVCC-safe, which is the same limitation pg_repack had and is documented in the Postgres 19 release notes.
The article gives no link or citation for it.
The article says “This is the same limitation pg_repack had, and it's documented in the Postgres 19 release notes”
The source says No source to compare with.
No source givenFirst, only or fastest
REPACK CONCURRENTLY is the most significant DBA-facing feature in Postgres 19 and eliminates the need for pg_repack in most cases.
The article gives no link or citation for it.
The article says “REPACK CONCURRENTLY is the most significant DBA-facing feature in Postgres 19”
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 4 Nov 2026, 05:47 UTC. It played no part in the ranking.