PostgreSQL 19 RC1 Is Your Upgrade Rehearsal, Not Your Production Upgrade

PostgreSQL 19 RC1 is useful because it lets you practice the work you will need to do before the final release. It is not a green light to make the release candidate your production database.

The PostgreSQL 19 RC1 announcement says the candidate is mostly identical to the initial release but that more fixes can land before general availability. It also lists RC2 for 12 November and an expected general availability date of 19 November. That gives production teams a clear window: turn the future upgrade into a measured rehearsal while failure is cheap.

Make the Rehearsal Answer Real Questions

An upgrade test should leave you with decisions, not a screenshot of a successful command. Start by writing the questions the rehearsal must answer.

• Can the application run its critical flows against PostgreSQL 19?
• Which extensions and drivers need changes or newer builds?
• How long does the selected migration method take with representative data?
• Which monitoring, backup, and replication checks change?
• When would the team stop or return traffic to the old cluster?

Those questions give the test a useful finish line. A version that starts cleanly on an empty local database is not evidence that a production cutover is safe.

Establish the Current-State Inventory

Collect the facts that make two apparently similar databases behave differently: PostgreSQL version, operating system, storage class, locale, encoding, collation provider, extensions, replication roles, backup tool, connection pooler, and the services that are allowed to write.

SHOW server_version;
SHOW data_directory;
SHOW shared_preload_libraries;
SELECT extname, extversion FROM pg_extension ORDER BY extname;
SELECT rolname, rolsuper, rolreplication FROM pg_roles ORDER BY rolname;

Record the application queries and jobs that carry business risk. A login path, a write-heavy order workflow, a reporting query, a background worker, and a schema migration can expose different compatibility problems. The representative workload is not the biggest query you can find. It is the smallest set of paths that would make the cutover unacceptable if they failed.

Include the Edges of the Topology

Production databases rarely stand alone. Include replicas, logical subscribers, read pools, PgBouncer or other poolers, scheduled jobs, data exports, observability agents, and restore targets. An upgrade that passes on the primary but breaks a replica slot or backup validation is not ready.

Also identify dependencies that encode server version assumptions. Some libraries, ORMs, migration tools, dashboards, and extension installers branch on a server version. A rehearsal catches those assumptions while there is time to update them.

Choose a Migration Method Before You Measure It

PostgreSQL's upgrade documentation describes three broad paths: logical dump and restore, pg_upgrade, and replication-based upgrades. The correct method is a constraint decision.

Dump and Restore

Logical dump and restore is straightforward to reason about. It creates a new cluster and repopulates it from exported logical data. It is often the clearest choice for small or moderate databases, major topology changes, or an environment where a clean rebuild is useful.

Its cost is elapsed time and a larger data-movement operation. Test the actual data size, role restoration, extension setup, large objects, grants, and post-restore maintenance. Do not extrapolate from a ten-gigabyte developer copy to a multi-terabyte production cluster.

pg_upgrade

pg_upgrade can make a major-version upgrade much faster by reusing or linking existing data files under the supported procedure. PostgreSQL's documentation still requires careful preparation: compatible binaries, a clean old and new cluster state, checks before the switch, and a plan for follow-up analysis.

pg_upgrade --check \
  -b /path/to/old/bin \
  -B /path/to/new/bin \
  -d /path/to/old/data \
  -D /path/to/new/data

Run the check against a representative clone first. It reveals blockers early, including extension or configuration assumptions. It does not replace a full rehearsal. You still need to measure the real upgrade duration, verify application behavior, and practice restoring service if the validation phase fails.

Replication-Based Cutover

Replication can reduce a final write outage, but it adds operational parts. The team must define the synchronization point, writer freeze, sequence and identity behavior, lag threshold, client reconnection behavior, and what happens to writes during a rollback.

Choose it because the business requires a shorter cutover and the team can operate it, not because it sounds more advanced.

Build a Representative Rehearsal Environment

A useful rehearsal has a recent, access-controlled copy of production shape. It need not contain every sensitive value, but it needs enough data volume, schema complexity, index variety, extension use, and traffic behavior to make timings meaningful.

Protect the Test Data

Use approved masking or a production-safe clone mechanism. Limit access, remove external integrations that could send mail or charge cards, and verify that background jobs cannot write to production services. A migration rehearsal should not become a privacy or side-effect incident.

Keep the Version Boundary Visible

Install old and new PostgreSQL binaries separately. PostgreSQL explicitly recommends parallel installations for cautious users so client applications can be tested before a full switch. That separation also makes it easier to prove which binary, data directory, and configuration belong to each side of the rehearsal.

Test Extensions and Server Settings Early

Extensions are often the part of an otherwise clean upgrade that needs vendor coordination. List each extension, required version, installation path, and upgrade command. Confirm that it supports PostgreSQL 19 in the environment you deploy.

Do the same for settings supplied by configuration management. A removed, renamed, or behaviorally changed parameter can prevent startup or produce a subtle difference after cutover. Read the migration sections of the release notes for each major version you crossed, as PostgreSQL recommends.

Validate Roles, Grants, and Authentication

Run your ordinary application connections against the new cluster. Check least-privilege service roles, administrative maintenance access, read-only reporting users, and failover or backup identities. A test that uses only a superuser can hide a role or authentication failure that will appear immediately after a production cutover.

Exercise the Application, Not Just SQL Syntax

PostgreSQL 19 RC1 includes fixes since Beta 4 across areas such as REPACK (CONCURRENTLY), pg_plan_advice, logical replication behavior, parallel autovacuum, postgres_fdw statistics import, and COPY JSON key behavior. The release notes are important reading, but they are not a substitute for your workload.

Run a written application test pack. Include critical reads and writes, schema migrations, job processing, report exports, full-text or JSON paths where relevant, timeout and retry behavior, and any query whose plan or result shape affects customers.

EXPLAIN (ANALYZE, BUFFERS)
SELECT *
FROM important_query_view
WHERE account_id = $1;

Capture representative plans and query timings without declaring a small difference a regression by default. Look for large plan shifts, changed result semantics, errors, or timeouts. The database is allowed to choose a different valid plan. Your concern is whether the new behavior serves the application correctly within its operating limits.

Test Backup, Restore, and Observability

An upgrade that cannot be restored or observed is incomplete. Run the backup tool you intend to use, restore into a disposable target, and perform a small integrity and application check. Confirm backup retention and encryption settings did not silently reset with new packages or service units.

Check dashboards, log parsers, alert rules, exporter compatibility, and on-call procedures. Version labels, catalog queries, and metrics can change. The rehearsal is a better time to fix a fragile dashboard query than the first hour of a production cutover.

Rehearse the Cutover and the Return Path

Write the production sequence in minutes and then execute it in rehearsal. Include traffic drain, write freeze, final backup or synchronization checkpoint, migration, startup, validation, pooler or DNS changes, and communication.

Define the Go and No-Go Checks

For example, the new cluster must accept application roles, pass a defined smoke test, report replica health, produce expected metrics, and complete a data-consistency check before writes are opened. A failed check should pause the change.

A Rollback Is a Traffic Decision

For a major upgrade, rollback commonly means returning traffic to the old cluster before accepting new writes on the new one, or restoring from a verified backup according to a documented loss window. It is not a casual downgrade command.

Decide who can make that call, how long the validation window lasts, and what data reconciliation is required if writes have begun. The team needs this decision before production, not after a user has changed data in two places.

Turn RC1 Results Into a GA Plan

After the rehearsal, write down the migration method, measured durations, extension changes, configuration changes, unresolved risks, stop conditions, and owners. If a blocker appears, that is a successful rehearsal result. It is cheaper to learn that an extension needs a release than to learn it during a weekend outage.

Repeat the short validation when RC2 or GA arrives. The goal is not to redo every investigation. It is to confirm that the artifact you will actually ship has passed the important checks.

Turn the Test Into Evidence Someone Else Can Use

An upgrade rehearsal often produces screenshots, terminal scrollback, and a general feeling that the work went well. That is not enough for a production change. The next person on the change, the on-call engineer, and the security reviewer need an artifact they can read without reconstructing the test from memory.

Keep a short rehearsal record

Record the old version, the candidate version, the operating-system image, the data-copy date, the migration method, the exact commands or automation revision, start and finish times, and the people who observed the validation. Include the expected outage window and the actual time spent in each phase.

Keep secrets, customer data, and full connection strings out of the record. Link to approved runbooks or protected logs when the evidence itself is sensitive. The record should explain the decision, not become a copy of every credential needed to execute it.

Evidence	Why it matters at GA
pg_upgrade --check output or dump/restore log	Shows known blockers were checked with the selected method
Extension inventory and compatibility notes	Prevents a late surprise from a version-bound dependency
Measured migration and validation timings	Makes the maintenance window a forecast instead of a guess
Smoke-test results using application roles	Confirms the path users take, not only a superuser connection
Backup and restore result	Proves the recovery tool still works with the candidate environment
Dashboard and alert review	Shows that on-call can observe the new cluster
Stop conditions and owner	Lets the team pause before inconsistent writes spread

This record should be brief enough to update when RC2 arrives. If it takes days to read, it will be ignored during the release window.

Compare results with a threshold, not optimism

Some difference is normal when a planner, compiler, operating-system package, or extension changes. Decide before the test what a concerning difference looks like. It may be an application error, a failed migration, a replica that cannot catch up, a backup that does not restore, a query that exceeds a service-level limit, or a cutover that exceeds the maintenance budget.

Do not create a rule that every query must have exactly the same plan or timing. That produces noise and encourages teams to ignore the report. Focus on differences that affect correctness, capacity, recovery, or the user-visible service level.

Test Data Correctness at the Boundaries

A successful server start says nothing about whether the data shapes your application relies on still behave as expected. Pick a small set of boundary checks that represent the problems a generic test database will miss.

Check encoding, collation, and text behavior

Record the locale, encoding, collation provider, and any collation versions in the current cluster. Text ordering, uniqueness behavior, and index use can depend on these choices. If the operating-system image or collation library differs in the rehearsal, record that difference rather than treating it as a harmless environment detail.

Use representative values from your application without copying personal data into an uncontrolled environment. Test the queries where ordering, case folding, full-text search, or uniqueness has business meaning. A product catalog, user name, search result, or deduplication key can expose a difference that a simple SELECT 1 cannot.

Check sequences and write paths

Major upgrades can expose assumptions around generated identifiers, background workers, and migration ordering. Exercise a small create, update, and delete path with the same roles and transaction boundaries used by the application. Verify that sequences, defaults, triggers, and constraints behave as expected.

For an upgrade path that involves replication or a traffic cutover, decide which system is allowed to accept writes at each stage. Two writable copies are not a rollback strategy. They are a reconciliation problem unless the design explicitly supports multi-writer behavior.

Include operational jobs

Nightly reports, data exports, retention jobs, ETL, migration workers, and maintenance tasks are often absent from a product team's happy-path test suite. They still depend on the database version, roles, extensions, and scheduling infrastructure. Run a representative sample before declaring the rehearsal complete.

Plan the Client and Pooler Transition

The database server is only one half of the upgrade. Applications, drivers, connection poolers, proxies, and schema-migration tools decide how traffic reaches it. List the clients that can write and the mechanism that changes their destination.

Verify connection settings in the new environment

Use the application configuration that the production cutover will use, with sanitized or approved secrets. Confirm TLS settings, hostname verification, role mappings, connection limits, timeouts, and retry behavior. A local client that connects with a privileged default role tells you little about a deployment that uses a separate service account through a pooler.

If PgBouncer or another pooler sits in front of the server, test it as part of the rehearsal. Confirm pool mode, backend limits, prepared-statement behavior where relevant, and the health checks that will decide whether traffic shifts. The server may be healthy while the connection boundary is still wrong.

Stage the migration tool

Run the schema-migration tool against the rehearsal cluster using the same version and invocation expected for production. Look for changes that assume a certain server version, extension, role, or schema state. A migration that succeeds on an empty database can still lock a large table, wait on a production-sized index, or collide with a concurrent background job.

Write down which migrations are included in the cutover and which are deliberately separated. A major PostgreSQL upgrade is already a large operation. Combining it with an unrelated destructive schema change makes diagnosis and rollback harder.

Use RC1 to Improve the Human Part of the Change

The most expensive upgrade failures are often coordination failures. Someone starts a job before the write freeze, the incident channel has no database owner, a dashboard is missing a new metric label, or a decision waits for a person who is asleep. RC1 gives the team a chance to rehearse those parts while the stakes are lower.

Write a minute-by-minute handoff

For the critical window, list the operator, action, expected signal, maximum wait, and next decision. The document need not be elaborate.

18:00  Change owner confirms backup and traffic plan.
18:05  Application owner enables the write freeze.
18:10  Database owner records the final checkpoint and begins the upgrade.
18:35  Validation owner runs role, query, and health checks.
18:45  Change owner opens writes or initiates the documented return path.

The useful part is not the exact minute count. It is that each step has a person, an expected result, and a boundary after which the team stops improvising.

Practice communication without hiding risk

Prepare a short maintenance notice, an internal status format, and a final completion note. State what is being upgraded, the expected effect, the time window, and where users can report a problem. Do not promise zero risk. A calm, specific note is more credible and more useful than a vague assurance that everything will be seamless.

During the rehearsal, test the channel itself. Can the relevant application, database, platform, and support owners see the update? Can one person make the stop decision? These questions are cheap to answer before the database is in maintenance mode.

Validate Replication, Restore, and Failover as One System

A successful primary-server upgrade does not prove that the service is ready. Production databases are recovery systems as much as they are query systems. The rehearsal should show that replicas catch up, backups restore, monitoring resumes, and the team can make a safe decision during an incident.

Check the paths your normal dashboard hides

Start with the replication topology that exists in the environment you are testing. Confirm that each physical standby reconnects after the upgrade and reaches an acceptable replay delay. If you use logical replication, test publications and subscriptions too. Exercise the application path that writes through the publisher and reads through the subscriber, rather than settling for a green process status.

Record the before and after values for replication lag, archive activity, connection counts, checkpoint behavior, and the alerts that watch them. A metric that quietly changes its name, label, or expected range can turn a safe upgrade into an avoidable on-call surprise.

Restore a backup into the new version

An upgrade is not a backup test, but it is an efficient time to run one. Restore a recent, scrubbed backup into a fresh PostgreSQL 19 environment. Measure the duration, check extensions and roles, and run a small set of integrity and application smoke tests against the restored data.

That exercise answers practical questions that a package upgrade cannot: whether the backup really contains what the service needs, whether the restore runbook still works, and whether the team knows where credentials, encryption keys, and object-storage permissions are supplied. Keep the result with the rehearsal evidence, including the point-in-time covered by the backup and any manual steps.

Rehearse a deliberately boring failover

If the service has a failover process, test it after the upgrade while the workload is still controlled. Promote the intended standby or use the normal orchestrator, direct a small client workload to the new primary, and confirm that monitoring identifies the topology change correctly. Then document how you returned to the desired steady state.

The goal is not to prove that every disaster is solved. It is to make a common recovery action familiar, timed, and observable in the exact version family you plan to operate. A short rehearsal that reveals an outdated DNS step or missing permission is valuable evidence, not a failed test.

Turn the Rehearsal Into a Capacity Forecast

Capture resource behavior alongside functional results. Compare CPU, memory, disk latency, WAL volume, temporary-file activity, and connection pressure under the same representative workload before and after the upgrade. The values do not need to match exactly. They need to be understood well enough that a real change can be distinguished from normal variation.

This also creates a useful post-upgrade baseline. If an application team reports slower work the following week, operators can compare it with the rehearsal rather than reconstructing expectations from memory. Add vacuum activity, autovacuum worker usage, cache hit behavior, and the slow-query sample that matters to your service. The result is more actionable than a generic statement that the upgrade passed.

Sources and Further Reading

• PostgreSQL 19 RC1 announcement
• PostgreSQL major-version upgrade documentation
• pg_upgrade documentation
• PostgreSQL release notes
• PostgreSQL roadmap

Frequently Asked Questions

Can we skip RC1 and start testing at GA?

You can, but you lose time. RC1 is designed for feedback and compatibility testing. A rehearsal now leaves more room to fix application, extension, or process issues before the final release window.

Which result matters most from the rehearsal?

The most useful output is a credible production plan: a selected migration method, measured time, explicit validation checks, known dependencies, and a decision path if the checks fail.

Is a fresh database enough for application testing?

No. Fresh databases do not expose data-volume timing, index behavior, historic schema choices, extension state, permission edge cases, or the operational load that makes upgrades difficult.

---