PostgreSQL upgrade readiness assessment
A fixed-price assessment for teams on older PostgreSQL major versions — plan a safe upgrade path before extended-support charges and blocked features force a rushed one.
Last updated:A PostgreSQL upgrade readiness assessment maps the safe route from an older major version to a current one: compatibility, breaking changes, the viable upgrade paths with their downtime and rollback trade-offs, and — on AWS RDS — extended-support cost exposure. Revenant Systems delivers it as a written upgrade plan with sequenced steps and a risk register, at a fixed price agreed up front.
Who is the assessment for?
The assessment fits teams on PostgreSQL 13, 14, or 15 — or older — facing the end of standard support: extended-support charges on AWS RDS, features blocked on newer versions, or an upgrade they can't afford to get wrong. It suits teams that can't tolerate extended downtime or a botched migration.
What does the assessment cover?
The assessment checks the current version, extensions, and features against the target version; identifies the breaking changes and deprecations relevant to your actual workload; and reviews application-side risks — driver versions, query-plan changes, and connection handling. For RDS estates it also weighs extended-support cost exposure against the cost of upgrading.
- Extension and feature compatibility against the target version
- Breaking changes and deprecations for your workload
- Application-side risks: drivers, query plans, connections
- RDS extended-support exposure vs upgrade cost
Which upgrade paths are considered?
Four paths are assessed against your constraints: in-place upgrade, dump and restore, Blue/Green deployment, and a logical-replication-based cutover. Each viable option comes with realistic downtime expectations and a rollback strategy, so the recommendation is a choice you can defend — not a leap of faith.
| Path | Typical downtime | Rollback |
|---|---|---|
| In-place upgrade (pg_upgrade) | A planned window, usually minutes | Restore from snapshot or backup |
| Dump and restore | Hours — grows with data size | Original instance left untouched |
| Blue/Green deployment | Minutes at cutover | Switch back to the original environment |
| Logical-replication cutover | Near zero at cutover | Fall back to the still-running source |
Why act before end of standard support?
Because staying put has a hard cost. When a major version leaves standard support, AWS RDS moves it to extended support — billed per vCPU-hour on top of the instance price, a real and growing line item — while self-hosted estates stop receiving security patches. Planning the upgrade early keeps the timing, and the downtime window, yours to choose.
Cost pressure on AWS is familiar ground: in a previous role the founder led a cloud-spend redesign that cut a platform's AWS infrastructure costs by around 60% while its traffic doubled.
What you receive
- A written upgrade plan: recommended path, sequenced steps, and a realistic downtime window
- A risk register and rollback plan
- A “further investigation recommended” section for anything material outside the fixed scope
- A findings walkthrough call
How the engagement runs
- Typical turnaround: two weeks from start to report
- Fixed scope and fixed price, agreed before work starts
What we need from you
- Current version, extension list, and configuration — or read access to gather them
- Application driver and framework details
- For RDS estates: instance details and billing visibility for the extended-support exposure
- A short walkthrough with the team that owns the database
Access and client data are handled under our information security statement.
Frequently asked questions
Is the price fixed?
It is — the assessment runs to a scope and price agreed up front, and both stay put. There is no day rate to watch.
What if the assessment surfaces problems beyond the upgrade?
They go in the plan under further investigation rather than quietly widening the engagement. Each is described with enough context to judge its urgency, and can be scoped separately if you want it addressed.
Can you run the upgrade as well?
Yes. Hands-on execution of the upgrade plan is available as a separately scoped, fixed-price engagement. The assessment stands alone regardless: the plan is written so your own team can execute it, with the sequencing, risks, and rollback steps already worked out.
Each package is an audit or assessment offered on its own — the process behind it is covered in how we work.