Upgrade without a performance regression. The upgrade itself is usually the easy part; the risk is the week after, when plans change and statistics are missing. Baseline before, know what to compare after, and have a rollback rule.
On RDS and Aurora, a major-version upgrade or a blue/green switchover is a documented, mostly managed operation, and pg_upgrade --check catches many blockers on self-managed servers. What those tools do not tell you is how your own workload will behave on the new version: which plans change, which queries slow down until statistics are rebuilt, which extension or driver behaves differently, and how you would know within the first hour.
This review is about that part: evidence from your workload before the change, a short list of what to compare after it, and clear go/no-go and rollback criteria.
Identify extension and application dependencies that can affect the target-version path.
Capture representative workload behavior so regressions are observable rather than anecdotal.
Define critical queries, plans, latency and operational checks for the post-upgrade window.
SELECT extname, extversion FROM pg_extension;$750–900 for one cluster, depending on extension count, platform and how much baseline evidence already exists. Scope and delivery date are agreed before work starts. See pricing for the other engagement types.
To run the checks yourself first, use the PostgreSQL 14 upgrade checklist. For the most common post-upgrade slowdown, see why PostgreSQL can be slow after a major upgrade.
Important: I do not execute the production upgrade as part of this review unless separately scoped. Your team or managed-service provider owns the change window.
Start with your version, platform and extension list. The first step is scoping the smallest useful readiness review.
Prefer to talk first? Book a 20-minute triage call.