PostgreSQL 19 Beta 2 on Amazon RDS Preview: REPACK CONCURRENTLY Bench and Upgrade Best Practices

2026-07-16 was a double ship day: the PostgreSQL Global Development Group released PostgreSQL 19 Beta 2, and AWS put that same beta into the Amazon RDS Database Preview Environment in us-east-2 (Ohio). Community GA is still targeted for roughly September/October 2026. If you run RDS for PostgreSQL (or are waiting on Aurora’s later major-version wave), this is the week to stand up a disposable Preview instance — not to schedule a production cutover.

Reproduce this — Clone the harness under examples/architecture-blog-2026/postgresql-19-beta-rds-preview/repack-bench/. ./run-bench.sh starts postgres:19beta2-alpine, builds a bloated bench_orders table, and writes out/results.csv. We ran it on 2026-07-17 (server_version=19beta2).

First-party REPACK CONCURRENTLY numbers

Opinionated take: On PostgreSQL 19, test REPACK (CONCURRENTLY) before you invent another pg_repack runbook — with the trade-off that beta lock timing and VERBOSE accounting can still change before GA.

We could not create an RDS Preview instance from the authoring IAM principal (no rds:*), so the timed run used the official community image postgres:19beta2-alpine — the same Beta 2 engine AWS announced for Preview. Label the numbers honestly: community Docker, not managed Preview.

On this workload, CONCURRENTLY cost about 8% more wall clock than blocking REPACK while keeping every probe SELECT successful. Size dropped from 873 MB to 429 MB (~51%). Full CSV: repack-bench/out/results.csv.

What broke — Day of the Beta 2 bench (2026-07-17). Blocking REPACK reported ~2.03M removable row versions; the CONCURRENTLY path logged 0 removable in VERBOSE while still rewriting the relation down to ~429 MB. Concurrent SELECTs stayed green (60/60). Treat VERBOSE removable counts on CONCURRENTLY as unreliable in Beta 2 until you reconcile them against pg_total_relation_size before/after — do not drive capacity planning off the INFO line alone.

Context for the SQL (PostgreSQL 19 Beta 2, Docker postgres:19beta2-alpine):

-- Blocking rewrite (ACCESS EXCLUSIVE for the full operation)
REPACK (ANALYZE, VERBOSE) bench_orders;

-- Short exclusive window; needs PK / replica identity
REPACK (CONCURRENTLY, ANALYZE, VERBOSE) bench_orders;

Architecture for how we recommend AWS teams use Preview (dump → load → REPACK + app suite → export findings):

PostgreSQL 19 Beta RDS Preview architecture (draw.io)

What AWS operators should test first

Maintenance: REPACK and parallel autovacuum

REPACK lands in core with a CONCURRENTLY option so table rebuild no longer implies a long exclusive lock for every maintenance window. Autovacuum gains parallel workers (autovacuum_max_parallel_workers) and a scoring view for prioritization. Why it matters: large OLTP heaps that previously needed pg_repack or VACUUM FULL downtime can be exercised in Preview before GA. Who breaks without it: teams still planning multi-hour exclusive locks for space reclaim. For vacuum lag, index bloat, and hot partitions on Aurora, use the existing field guide — PostgreSQL vacuum, index bloat, and sharding — rather than re-learning bloat here.

Logical replication: sequences and dynamic WAL

PostgreSQL 19 synchronizes sequence values on logical replication and can enable logical decoding without a restart when wal_level starts at replica, with effective_wal_level reporting what is actually in effect. Why it matters: major-version upgrades and blue/green cutovers stop needing manual sequence reconciliation as often. Preview tip: restore a schema with sequences into Preview, create a publication/subscription pair, and assert sequence parity after catch-up.

SQL/PGQ and temporal / partition DDL

SQL/PGQ brings property-graph queries into standard SQL. Temporal FOR PORTION OF expands for UPDATE/DELETE. ALTER TABLE ... MERGE PARTITIONS / SPLIT PARTITIONS reorganize partitions in place. Why it matters: relationship traversals and partition surgery stop requiring external graph stores or brittle partition swap scripts. Preview tip: pick one hot query that today fans out in the app layer and rewrite it as PGQ against a small graph — fail fast if your ORM cannot carry the syntax.

Monitoring

New views such as pg_stat_lock and richer vacuum/analyze progress (including who started the job) make Preview testing measurable. Why it matters: upgrade readiness memos need lock and maintenance evidence, not anecdotes.

Amazon RDS Preview Environment — rules that bite

From the 2026-07-16 AWS What’s New for PostgreSQL 19 Beta 2:

• Instances live in the Preview Environment with managed RDS benefits for evaluation.
• Maximum retention 60 days, then automatic deletion.
• Preview snapshots restore only inside Preview.
• Bridge data with dump/load (not promote-to-prod).
• Pricing follows US East (Ohio) Preview rates.

Aurora PostgreSQL does not list 19 yet (current major track remains 18.x on the public calendars as of this writing). Preview today is the RDS for PostgreSQL path.

Best practices checklist

1. Never put Beta on a production endpoint. Preview and community beta are for compatibility and feature proof only.
2. Script dump/load both directions before you care about REPACK timings — Preview snapshot policy will strand you otherwise.
3. Calendar the 60-day TTL. Treat Preview like an ephemeral lab account.
4. Pin engine version strings in your notes (19beta2) so Beta 3 results are not compared blindly.
5. Require a primary key (or replica identity) before CONCURRENTLY appears in any runbook.
6. Run the application regression suite against Preview, not only DBA smoke tests — grease-mode and driver quirks show up in clients first.
7. Inventory extensions (pg_stat_statements, PostGIS, pgvector, custom C extensions) against Preview availability; fail the upgrade plan on missing extensions early.
8. Separate Aurora from RDS timelines. Do not promise Aurora 19 dates from an RDS Preview announcement.
9. Prefer core REPACK after GA on your managed engine; keep pg_repack only where GA has not landed yet.
10. Measure with relation size + app probes, not VERBOSE removable counts alone (see What broke).

What to Do This Week

1. Launch a PostgreSQL 19 Beta 2 instance in RDS Preview (us-east-2) or run the community harness above.
2. Dump a non-production schema that includes your largest heap and sequence-heavy logical-replication path.
3. Time REPACK (CONCURRENTLY) on a bloated copy; keep a blocking REPACK control run.
4. Execute the app smoke suite (migrations, ORM queries, connection pooler).
5. Write a one-page memo: blockers (extensions, SQL/PGQ appetite, Aurora wait) vs proceed-to-GA checklist.

What This Post Doesn’t Cover

• Aurora PostgreSQL 19 GA timing or Limitless behavior on 19
• Full planner/AIO changelog (anti-join, incremental sort, pg_plan_advice)
• Self-managed PostgreSQL on EC2 hardening
• Isolation-level semantics — see PostgreSQL transaction isolation on AWS
• Deep vacuum tuning — see vacuum, index bloat, and sharding

If you want a Preview readiness review against your RDS estate, talk to an AWS database specialist.