---
title: PostgreSQL 19 Beta 2 on Amazon RDS Preview: REPACK CONCURRENTLY Bench and Upgrade Best Practices
description: On 2026-07-16 AWS put PostgreSQL 19 Beta 2 in RDS Preview. Our first-party REPACK CONCURRENTLY run cut an 873 MB bloated table to 429 MB in 4.5s with 60/60 concurrent SELECTs succeeding.
url: https://www.factualminds.com/blog/postgresql-19-beta-rds-preview-best-practices/
datePublished: 2026-07-17T00:00:00.000Z
dateModified: 2026-07-17T00:00:00.000Z
author: palaniappan-p
category: Cloud Architecture
tags: postgresql, amazon-rds, database, aws, aurora
---

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

> On 2026-07-16 AWS put PostgreSQL 19 Beta 2 in RDS Preview. Our first-party REPACK CONCURRENTLY run cut an 873 MB bloated table to 429 MB in 4.5s with 60/60 concurrent SELECTs succeeding.

**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/`](/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.

| Metric                                       | Value                          |
| -------------------------------------------- | ------------------------------ |
| Target rows                                  | 2,000,000                      |
| Live / dead tuples before                    | 1,969,251 / 2,028,674          |
| Size before                                  | **873 MB** (915,357,696 bytes) |
| Blocking `REPACK (ANALYZE, VERBOSE)`         | **4.167 s** → 429 MB           |
| `REPACK (CONCURRENTLY, ANALYZE, VERBOSE)`    | **4.494 s** → 429 MB           |
| Concurrent SELECT probes during CONCURRENTLY | **60 ok / 0 fail**             |

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`](/examples/architecture-blog-2026/postgresql-19-beta-rds-preview/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`):

```sql
-- 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)](/examples/architecture-blog-2026/postgresql-19-beta-rds-preview/postgresql-19-beta-rds-preview.drawio)

## 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](/blog/postgresql-vacuum-index-bloat-sharding-hot-partitions-aws/) — 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](/blog/postgresql-transaction-isolation-acid-vs-base-aws/)
- Deep vacuum tuning — see [vacuum, index bloat, and sharding](/blog/postgresql-vacuum-index-bloat-sharding-hot-partitions-aws/)

If you want a Preview readiness review against your RDS estate, [talk to an AWS database specialist](/contact-us/).

## FAQ

### Should I upgrade production RDS or Aurora to PostgreSQL 19 Beta?
No. Beta releases are for evaluation only. Community and AWS both warn against production beta. Use the Amazon RDS Database Preview Environment (us-east-2) or a disposable community engine build to exercise REPACK, SQL/PGQ, and your application suite. Plan the production cutover only after RDS for PostgreSQL 19 GA, and separately when Aurora PostgreSQL ships a 19-compatible engine.

### Is PostgreSQL 19 available on Aurora PostgreSQL yet?
Not as of 2026-07-17. Aurora PostgreSQL release calendars list major track 18.x as current. Preview Environment coverage announced for PostgreSQL 19 Beta is for Amazon RDS for PostgreSQL. Treat Aurora 19 as a later wave and do not block Aurora roadmaps on Preview-only features.

### When should I NOT use REPACK CONCURRENTLY?
Skip CONCURRENTLY for UNLOGGED tables, partitioned parents (repack partitions individually), tables without a primary key or index-based replica identity, catalog/TOAST targets, and anything inside an open transaction block. Also skip when max_repack_replication_slots cannot allocate a slot. Prefer a blocking REPACK (or a maintenance window) when you need physical clustering via USING INDEX and can afford ACCESS EXCLUSIVE for the full rewrite.

### What could go wrong in the RDS Database Preview Environment?
Preview instances are deleted after a maximum of 60 days. Snapshots created in Preview can only restore inside Preview. There is no promote-to-production path. Pricing follows us-east-2 (Ohio) rates. Dump/load is the supported bridge in and out. If your test depends on a Preview snapshot living past day 60, you will lose it.

### Does REPACK CONCURRENTLY replace pg_repack?
For managed engines that ship core REPACK, prefer the built-in command once GA lands on your engine — fewer extension privilege and version skew issues. Until your RDS/Aurora version includes REPACK, keep pg_repack only where you already operate it safely. Beta Preview is the place to prove CONCURRENTLY against your schema, not the place to rip out a working extension on production.

### How is this different from vacuum and index-bloat guidance?
Autovacuum still owns dead-tuple hygiene and planner stats. REPACK rewrites the relation to return space to the OS and (with CONCURRENTLY) shortens the ACCESS EXCLUSIVE window. For vacuum tuning, partitioning, and hot partitions on Aurora, use our vacuum and sharding field guide — this post is about PostgreSQL 19 Beta features and Preview testing, not a re-teach of bloat mechanics.

---

*Source: https://www.factualminds.com/blog/postgresql-19-beta-rds-preview-best-practices/*