TL;DR. PostgreSQL 19 Beta 3 landed on August 13, and GA is expected within weeks. Two features matter more than the rest for anyone responsible for a production cluster: REPACK, which brings online table rebuilds into core after a decade of trusting external extensions, and pg_plan_advice, which ends twenty years of refusing query hints by shipping something better than hints: plan constraints generated from real plans, stored outside query text, with honest feedback about what was honored. The two features share a design shape. Each takes an intervention that used to be a hand-run, side-channel operation and turns it into a declarative artifact that can be reviewed, versioned, and gated. That shape is not aimed at the DBA of 2015. It is aimed at the automation, increasingly agent-shaped, that is taking over maintenance work.
On August 13 the PostgreSQL project shipped 19 Beta 3 alongside minor releases for every supported major version. The headline features of the 19 cycle are easy to list: property graph queries (SQL/PGQ), parallel index vacuuming inside autovacuum, logical replication of sequence values. But the two features that will change how production clusters are operated are quieter, and they are best read together: a new top-level command called REPACK, and a contrib module called pg_plan_advice. One rebuilds bloated tables online. The other pins query plans. What they have in common is the more interesting story: both convert a risky, hand-run intervention into a reviewable operation, and reviewable operations are the precondition for delegating maintenance to software.
Table rewrites come in from the cold
Every Postgres table that takes sustained updates and deletes accumulates dead space that plain VACUUM cannot return to the operating system. The traditional in-core answer, VACUUM FULL, rewrites the table while holding an access-exclusive lock for the entire rewrite, which on a large table means blocking every read and write for minutes to hours. Nobody runs it on a hot table on purpose. So for over a decade the real answer lived outside core: the pg_repack extension, which captures concurrent changes with triggers while copying the table, and pg_squeeze, which does the same job through logical decoding.
Both tools work, and both ask for trust that core never asked for. They must be installed and version-matched per major release, which on managed platforms means hoping the provider's extension allowlist includes them. An interrupted run can leave artifacts to clean up. And the operation itself is exactly the kind that teams encode in tribal knowledge: which flags, which table, which maintenance window, who watches it.
REPACK is the project absorbing that whole category. The command rewrites the table into a new file with no wasted space, optionally ordering rows by an index (the old CLUSTER behavior), and VACUUM FULL and CLUSTER now run on the same rewrite infrastructure internally. The option that matters is REPACK CONCURRENTLY: the copy proceeds while concurrent data changes are captured through logical decoding and applied to the new file, and the access-exclusive lock is held only for the final file swap. One long-running community write-up describes it as pg_squeeze brought into Postgres core, which is roughly right, and is high praise: the design that proved itself in production for years is now maintained by the people who maintain the storage layer it depends on.
The preconditions are stated plainly in the documentation, and they are the honest cost of the approach. The table needs a primary key or an index-based replica identity. A replication slot must be available. Unlogged tables, partitioned tables, system catalogs, and TOAST tables are out for the concurrent path, and the command cannot run inside a transaction block. A concurrent rewrite also still costs what it costs: a full copy's worth of I/O, transiently close to double the disk, and logical-decoding overhead for the duration. REPACK removes the external-dependency risk and the lock catastrophe, and it removes no physics.
Twenty years of refusing hints, then advice
The planner side is the more philosophically loaded change. For roughly two decades the project's answer to "can I hint a query plan" was no, on the argument that hints embedded in query text rot silently, get cargo-culted, and paper over planner bugs that then never get fixed. The workarounds practitioners actually used were worse than hints: flipping enable_seqscan-style planner GUCs around individual queries, or restructuring SQL until the planner happened to pick the right plan, then hoping the next ANALYZE or minor upgrade did not flip it back. Plan regressions of that kind are a classic reliability incident: nothing deployed, nothing changed in the schema, and p99 latency is suddenly ten times worse because one join flipped from hash to nested loop.
pg_plan_advice, a contrib module in 19, is the project conceding the need without conceding the argument. The mechanism is deliberately unlike Oracle-style hints. You run EXPLAIN (PLAN_ADVICE) on a query and Postgres emits a compact advice string describing the decisions the planner made, in a small declarative language: JOIN_ORDER(f d) HASH_JOIN(d) SEQ_SCAN(f d) NO_GATHER(f d). To pin the plan, you set that string in the pg_plan_advice.advice configuration parameter. The advice constrains the planner rather than commanding it: it works by ruling out choices, and it cannot force a plan the planner considers unviable. Crucially, the feedback loop is explicit. EXPLAIN reports per piece of advice whether it matched, was partially matched, not matched, inapplicable, conflicting, or failed. A companion module, pg_stash_advice, stores advice and applies it automatically by query identifier, which is the plan-pinning workflow: capture the known-good shape, stash it, and the planner recreates it until you say otherwise.
The differences from hints-in-comments are exactly the differences between a hack and an operation. The advice is generated from a real plan, not hand-written from folklore. It lives outside the query text, so application code does not accumulate optimizer archaeology. And it tells you when it stopped working instead of failing silently. The documentation carries its own warning, worth taking seriously: the planner's judgment is usually right, and overriding it can easily backfire when data distributions drift under a pinned plan. Advice is a tool for stabilizing known-good behavior and for surgical intervention, and it will hurt whoever uses it as a default.
Both features are the same feature
Put the two side by side and the design shape is identical. Before 19, the two scariest routine interventions on a production Postgres, rewriting a bloated table and overriding a planner decision, were performed through side channels: an external extension with its own failure modes, a GUC flipped in a session, a query rewritten until the optimizer cooperated. Side-channel operations resist review. There is no artifact to look at, so approval means "I trust the person at the keyboard," and the operation exists nowhere except in the shell history of whoever ran it.
After 19, both interventions are artifacts. A bloat rewrite is one statement naming one table, with documented preconditions the system checks. A plan intervention is a short string with defined semantics and machine-checkable feedback. Artifacts can be diffed, versioned, attached to a ticket, and, most importantly, gated: a policy can say which tables an operator may repack and when, or which queries may carry pinned plans and who signs off on pinning them.
That matters now because the operator is increasingly not a person. The vendors shipping autonomous DBA agents are proposing to hand exactly this class of maintenance to models, and the benchmarks that finally measure the full lifecycle show maintenance is where models are weakest. Google's database agent gates its fixes behind human approval, and the unresolved question in every approval gate is what, precisely, is being approved. "The agent will fix the bloat" is not an approvable statement. REPACK (CONCURRENTLY) orders USING INDEX orders_pkey is: bounded, checkable, revertible in the sense that it either completes or it does not, with preconditions the database enforces regardless of what the agent believes. The same logic applies to migrations with a human in the loop: review works when the thing under review is small, declarative, and complete. Postgres 19 does not ship an agent, and does not need to. It ships the substrate that makes automated maintenance reviewable, which is the part the agent vendors keep treating as an afterthought.
What to do with the beta window
GA is weeks away, and the beta window is the cheap time to learn both features. The project's standing guidance applies: betas are for test environments, not production.
For REPACK, restore a copy of production, since staging shaped nothing like production will teach you nothing about a rewrite's real cost. Find your most bloated large table, run REPACK (CONCURRENTLY, VERBOSE), and measure wall time, I/O, and peak extra disk. Then check the preconditions across your whole schema: any large table without a primary key or replica identity, and any partitioned table, is outside the concurrent path, and that inventory is worth having before you plan on the feature.
For pg_plan_advice, pull your five most regression-prone queries, the ones that have flipped plans after an ANALYZE or a version bump, and run EXPLAIN (PLAN_ADVICE) on each. Read the advice strings. They are short, and they are the first artifact Postgres has ever given you that names the planner's decisions in a form you can store next to the query in version control. Whether or not you ever pin a plan, that record of intended plan shape is cheap insurance for the next upgrade, and comparing feedback across 18 and 19 on a restored copy is a better upgrade test than most suites.
Where Datapace sits
Datapace is building the context layer between your databases and your AI: resolved meaning validated by the people who own the data, the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. Postgres 19 is good news for that model, because a policy gate is only as good as the operations it can gate, and REPACK statements and plan-advice strings are exactly the kind of bounded, declarative operations a gate can reason about. If you are working through what governed, agent-run maintenance should look like for your estate, book a call.
Sources
- PostgreSQL Global Development Group, PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24, and 19 Beta 3 Released, August 13, 2026.
- PostgreSQL documentation, REPACK reference page, read via the postgres/postgres source mirror.
- PostgreSQL documentation, pg_plan_advice and pg_stash_advice, read via the postgres/postgres source mirror.
- Robert Haas, pg_plan_advice: Plan Stability and User Planner Control for PostgreSQL?, March 2026.
- Christophe Pettus, REPACK Moves In, The Build, April 29, 2026.
- Hubert "depesz" Lubaczewski, Waiting for PostgreSQL 19: Introduce the REPACK command, March 19, 2026, and Add pg_plan_advice contrib module, March 22, 2026.
- pgEdge, Looking Forward to Postgres 19: The New REPACK Command.
- pganalyze, Waiting for Postgres 19: Better Planner Hints with Path Generation Strategies.