Imagine a small appointment app. You upgrade a copy of its database, the restore finishes, and the tables look right. Then the app tries to confirm an appointment and gets a permission error.

This article was prepared with AI assistance. The appointment app and rehearsal below are hypothetical.

Both observations can be true. A restored table doesn't prove that the app's database role can use it. It also doesn't prove that each customer can see only their own appointments.

On November 12, the PostgreSQL Global Development Group released PostgreSQL 14.25 and confirmed that it was the final release of version 14. If your app still runs on 14, make a plan to move to a supported major version. The plan should include a rehearsal that tests your app, not just the database tools.

Write down what the rehearsal has to prove

First confirm the version that actually serves the app. Your laptop, staging environment, and production database may all be different. Check which versions your host supports, what upgrade paths it offers, and whether your extensions are available on the target version. Don't let a coding assistant choose the target from a version number alone.

For the appointment app, I'd name three checks: a customer can see their own booking, can't see another customer's booking, and can reschedule an eligible booking. Those checks cover a read, an access boundary, and a write that matters to the business.

Restore to a separate target

Use a fresh target that cannot receive production traffic or send production email. Use synthetic data to develop the test; if a representative backup is necessary, handle it inside the approved environment with the same access controls as production. Don't upload it to an AI chat or move it to a personal machine.

PostgreSQL's SQL dump documentation explains that a single-database dump doesn't capture cluster-wide objects such as roles. Managed providers may handle those separately. Verify that the intended application role, grants, extensions, and configuration exist on the restored target. Test using the role the app actually uses, not an administrator account that can hide missing permissions.

Record the restore exit status and read its errors. For an archive restore, PostgreSQL documents an option to stop at the first SQL error. That makes a broken rehearsal easier to diagnose; it doesn't turn the absence of a restore error into proof that the application works.

Practice the switch as well as the restore

Compare counts for a few meaningful records, then run the three checks through the app with test users. Confirm that changing an appointment leaves the related records consistent. Time the whole rehearsal from starting the backup or provider workflow through the last app check. That gives you a better estimate of the maintenance window than the restore time alone.

Decide who can stop the cutover and how you'll handle writes. Switching a connection string back is simple only if the old and new databases haven't diverged. Before letting real users write to the new database, agree on when the old one stops accepting writes and what recovery means after the new one has accepted them.

The release question isn't "Did the database come back?" It's "Can the right user do the right thing, and can we recover if the answer is no?" Write down the evidence before you move traffic.

The $3 AI App Builder Starter Prompts help turn a vague upgrade request into a plan with explicit checks. The $9 AI App Builder From Zero e-book covers the broader path from scope to release. The $10 learning bundle includes both.

Bootcamp Bundle (Review Radar) is coming soon; the preview and waitlist are open, and checkout is closed.

You can also find me here:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/
Upwork: https://www.upwork.com/freelancers/marcusykim