Keys to shipping more: - Fewer meetings - More trust in teammates - Listen exclusively to heavy metal / hardcore / metalcore

Postgres 19 is in beta, and whew is it a doozy of a release. Each Postgres release is a bit different. Sometimes there is a single marque feature, sometimes there is a bunch of small quality of life improvements, often there is something around performance. Postgres 19 seems like it has really some of everything in it including marque areas. I'm going to spend some time over the coming weeks highlighting some of whats coming. And today I want to start off with a bang, built in REPACK! If you have operated Postgres for long enough, you have probably had a moment where you wanted to reclaim table bloat, rewrite a table, or reorganize data, but you very much did not want to take the lock that came with VACUUM FULL. There has long been an extension ecosystem around this problem, most notably pg_repack. That alone tells you something: users had a real need, and the ecosystem filled the gap. And even then pg_repack came with a few caveats in running it. Postgres 19 brings a new REPACK command into core, including support for REPACK CONCURRENTLY. That's right, not just REPACK in core, but being able to run it CONCURRENTLY just like we do for index creation! This is the sort of feature that may not excite someone building a toy app locally, but it matters a lot once your database is large, busy, and important. The difference between "yes, we can clean this up online" and "we need to schedule a maintenance window" is not a small difference. It is the difference between routine maintenance and a project plan. I expect REPACK CONCURRENTLY to be one of those features that production Postgres users care about more than the average release-note reader might expect.