How do I upgrade managed Postgres without breaking extensions?
Plan Postgres 17/18 upgrades on managed platforms when production depends on extensions such as pgvector, PostGIS, Timescale, or logical replication features with provider-specific rollout timing and breakage risk.
Blockers
- PostgreSQL 18 upgrades require PostGIS 3.6.0 first.
- Cloud SQL says pgvector 0.8.1 requires maintenance version R20251004.01_19.
- Logical replication requires cloudsql.logical_decoding to be enabled.
- pglogical requires cloudsql.enable_pglogical=on.
- On Amazon RDS, postgis_topology is N/A for PostgreSQL 18.
- Azure says timescaledb is unsupported when using the in-place major-version-upgrade feature.
- Cloud SQL says pg_ivm must be removed before a major upgrade.
- Cloud SQL says pg_squeeze must be upgraded to the target-compatible version before a major upgrade.
Who this is for
- low-ops
- enterprise
- high-scale
- real-time
- compliance
- small-team
Candidates
Amazon RDS for PostgreSQL
Best when you are already standardized on AWS and your required extensions are in the current RDS matrix. As of 2026-03-15, Amazon RDS documents PostgreSQL 18 and 17 support, says major upgrades are manual rather than automatic, upgrades read replicas with the primary for Single-AZ and Multi-AZ DB instance deployments, and warns that most PostgreSQL extensions are not upgraded during the engine upgrade.
When to choose
Best for enterprise + low-ops or compliance + high-scale teams that want a managed in-place upgrade path and can tolerate a maintenance window or use RDS Blue/Green with its PostgreSQL-specific logical replication limits. Choose this when your production extension set is already verified in the RDS extension table, and when you can explicitly rehearse slot cleanup, extension upgrades, and replica behavior before touching production.
Tradeoffs
RDS has a broad official extension matrix for PostgreSQL 17 and 18, including `pgvector`, `pglogical`, and `PostGIS`, and AWS documents both direct major-version upgrade and Blue/Green patterns. The tradeoff is that the engine upgrade and the extension upgrade are separate concerns, and Blue/Green major upgrades inherit logical replication limits such as single-threaded apply on the green side.
Cautions
Check extension-by-extension compatibility, not just engine availability. AWS says logical replication slots can still block or fail upgrades in some cases, but on source version 17 and later logical replication slots on non-read-replicas can be retained through upgrades; most extensions are not upgraded automatically. The current RDS extension table also shows a real PG18 compatibility edge: `postgis_topology` is `N/A` for PostgreSQL 18 even though `PostGIS` 3.6.1, `pglogical` 2.4.6, and `pgvector` 0.8.1 are supported. If you use Blue/Green for major upgrades, AWS documents additional limits including no replication of unlogged tables, DDL-sensitive partition management, `pg_partman` needing to be disabled, and `pg_cron` needing to remain disabled on green databases.
Sources
- docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.MajorVersion.html
- docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.html
- docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html
- docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html
- docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-considerations.html
Google Cloud SQL for PostgreSQL
Best when you want a managed precheck-driven upgrade workflow with explicit extension and dependency blockers. As of 2026-03-15, Cloud SQL lists PostgreSQL 18 as the default major version and 18.1 as the default minor version, says new major versions are supported within 90 days of community GA, uses `pg_upgrade` for in-place upgrades, and offers three years of extended support after community end of life.
When to choose
Best for low-ops + compliance or high-scale + real-time teams that want strong official prechecks, automatic minor-version rollout during maintenance, and the option to include cross-region or cascading replicas in a major upgrade through `gcloud` or the Admin API. Choose this when your main risk is upgrade blocker detection rather than custom platform behavior, and when your team is comfortable using CLI or API workflows for replica-inclusive upgrades.
Tradeoffs
Cloud SQL documents many upgrade blockers directly in the major-version-upgrade flow, including event-trigger ownership, deprecated flags, extension ownership, and extension-specific version requirements. It also supports logical decoding and `pglogical`, but some operations are more opinionated than on self-managed PostgreSQL, and replica-inclusive major upgrades are not available through the console or Terraform.
Cautions
Treat extension state and maintenance version as separate checks. Cloud SQL's extension page still documents `pgvector` 0.8.0 for PostgreSQL 13 and later, while the official release notes say the rollout to `pgvector` 0.8.1 completed on November 19, 2025 and requires maintenance version `R20251004.01_19`; verify the instance maintenance version before assuming the newer extension build. Cloud SQL also documents hard upgrade prerequisites for some extensions: PostgreSQL 18 upgrades require `PostGIS` 3.6.0 first, `pg_squeeze` must be upgraded to the target-compatible version, and `pg_ivm` must be removed before a major upgrade. For logical replication, `cloudsql.logical_decoding` must be enabled, and `pglogical` requires `cloudsql.enable_pglogical=on`.
Sources
- docs.cloud.google.com/sql/docs/postgres/db-versions
- docs.cloud.google.com/sql/docs/postgres/upgrade-major-db-version-inplace
- docs.cloud.google.com/sql/docs/postgres/extensions
- docs.cloud.google.com/sql/docs/postgres/replication/configure-logical-replication
- docs.cloud.google.com/sql/docs/postgres/release-notes
Azure Database for PostgreSQL Flexible Server
Best when you want a built-in in-place major-version-upgrade feature but need to watch region rollout and extension exceptions carefully. As of 2026-03-15, Azure documents PostgreSQL 18 support, says in-place upgrades use `pg_upgrade`, automatically move the server to the latest supported minor version during upgrade, and notes that MVU to PostgreSQL 18 is being enabled in phases by region.
When to choose
Best for enterprise + low-ops or small-team + compliance teams already on Azure that want one-click in-place upgrades, automatic minor servicing, and an official extension catalog with current per-version extension numbers. Choose this when your required extensions are Azure-supported and you can validate that your region, HA posture, and extension mix are compatible with Azure's MVU feature before scheduling production downtime.
Tradeoffs
Azure's documentation is unusually explicit about what the service does during upgrade: prechecks run first, HA is disabled and then re-enabled during the operation, and most upgrades are offline but usually complete in under 15 minutes. The tradeoff is that the extension story is split between what Azure supports on a given major version and what Azure allows through the in-place MVU feature.
Cautions
Do not assume 'supported on PG18' means 'supported for in-place upgrade to PG18.' Azure's extension catalog currently lists PostgreSQL 18 support for `vector` 0.8.1, `pglogical` 2.4.6, `PostGIS` 3.6.1, and `timescaledb` 2.24.0, and the March 2026 maintenance notes say TimescaleDB support was enabled for PostgreSQL 18. But Azure's extension-considerations page still says `anon`, `Apache AGE`, `dblink`, `orafce`, `postgres_fdw`, and `timescaledb` are unsupported when using the in-place major-version-upgrade feature. Also verify region availability for MVU to PostgreSQL 18, because Azure explicitly says rollout is phased.
Sources
- learn.microsoft.com/en-us/azure/postgresql/configure-maintain/concepts-major-version-upgrade
- learn.microsoft.com/en-us/azure/postgresql/configure-maintain/concepts-version-policy
- learn.microsoft.com/en-us/azure/postgresql/extensions/concepts-extensions-considerations
- learn.microsoft.com/en-us/azure/postgresql/extensions/concepts-extensions-versions
- learn.microsoft.com/en-us/azure/postgresql/release-notes-maintenance/2026-march
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "How do I upgrade managed Postgres without breaking extensions?"