A small list of things to do before you migrate to Postgres 17.

Most Postgres 17 upgrades go fine. The ones that do not tend to fail in the same handful of ways, and all of them are visible before you cut over if you look. This is the list we run before touching a production cluster.

Capture the plans you depend on

The planner changes between majors. A query that was index-only yesterday can choose a sequential scan tomorrow. Before the upgrade, snapshot the plans for your ten slowest queries so you have something to diff against.

-- run on the old version, save the output
EXPLAIN (FORMAT JSON, BUFFERS)
SELECT id, total
FROM orders
WHERE customer_id = $1
ORDER BY created_at DESC
LIMIT 50;

After the upgrade, run the same statements and compare. A plan that flipped from Index Scan to Seq Scan is the single most common upgrade regression, and the cheapest to catch this way.

The rest of the list

• Re-run ANALYZE on every large table immediately after the upgrade; stale statistics cause most of the rest of the plan regressions.
• Check that every extension you use has a 17-compatible version before you start, not during.
• Confirm your replication slots drained before the cutover, or you will lose data, quietly.
• Diff pg_settings between old and new; defaults move between majors more often than the release notes suggest.
• Keep the old primary readable for a day. The cheapest rollback is the one you did not destroy.

None of this is clever. All of it is the difference between a boring Tuesday and a long one.