I manage seven AWS RDS PostgreSQL instances: three in the US, three in Europe, and one in Australia. Each instance contains roughly 3,000 mostly small databases. Because PostgreSQL versions on RDS reach their upgrade deadlines relatively quickly, we currently migrate every database individually from the old instance to a newly created instance running the newer major version. This is slow, error-prone, and requires a lot of manual oversight. An in-place upgrade takes about seven hours, which is too much downtime for us. I'm considering Aurora PostgreSQL, including blue/green deployments, to make major-version upgrades easier. Has anyone operated Aurora at this scale and used it for major engine upgrades? How much downtime and operational work should we realistically expect?
1 Answer
Before building a custom export-and-import process, consider using the normal RDS major-version upgrade. Take a verified snapshot first, test the upgrade on a restored copy, and then change the engine version on the production instance so AWS performs the migration. This is the standard path and has worked reliably for many large fleets, although the actual downtime and compatibility checks still need to be planned.
I’ve used this approach for a large number of RDS upgrades without problems. The failures I’ve seen were generally application or extension compatibility issues, not the upgrade mechanism itself, so testing and a rollback plan are still important.