| name | postgres-cloud |
| description | Managed PostgreSQL cloud platforms: Amazon RDS for PostgreSQL, Aurora PostgreSQL, Google Cloud SQL, AlloyDB, Azure Database for PostgreSQL Flexible Server, Supabase, Neon, migrations, cloud limits, backups, monitoring, HA, read replicas, and parameter groups. |
PostgreSQL Cloud
Map the managed service to its control-plane limits before giving operational advice. Superuser, filesystem access, extensions, replication, parameters, and backup controls differ by provider.
How To Approach A Managed-Service Request
- Identify the exact offering, not just the vendor: RDS PostgreSQL vs Aurora, Cloud SQL vs AlloyDB, Azure Single Server (retired) vs Flexible Server. Advice differs sharply between them.
- Check the boundary first: is the requested action even possible without superuser/filesystem access? Translate to the provider's mechanism (parameter group, flag, extension allowlist, admin role, support ticket).
- Combine both telemetry planes: PostgreSQL-internal views plus provider metrics (Performance Insights, Query Insights, Azure Metrics). Storage, failover, and burst behavior are only visible on the provider side.
- On Aurora, Neon, and AlloyDB, remember the storage engine is not stock PostgreSQL — checkpoint/WAL/
shared_buffers reasoning changes.
- For migrations, run
scripts/05-migration-readiness.sql and check extension compatibility before promising a method.
What Managed Roles Cannot Do
rds_superuser, cloudsqlsuperuser, azure_pg_admin, and Supabase/Neon admin roles are not superuser. Commonly blocked: filesystem access (no COPY ... TO '/path', no log tailing except via provider APIs), shared_preload_libraries changes outside the allowlist, arbitrary untrusted extensions/languages, reading other users' full queries without the provider's grant mechanism, OS-level tuning. The workaround is always provider-specific: parameter groups/flags, extension allowlists, and managed export mechanisms.
Provider Quick Map
| Offering | Engine fidelity | HA model | Watch for |
|---|
| RDS PostgreSQL | Stock PostgreSQL | Multi-AZ (standby or 2-reader cluster) | Parameter groups (static vs dynamic), EBS IOPS/burst, 35-day max PITR |
| Aurora PostgreSQL | Custom distributed storage | Writer + up to 15 readers, shared storage | No stock checkpoint/WAL reasoning; replica lag semantics differ; cluster vs instance parameter groups; I/O-based billing modes |
| Cloud SQL | Stock PostgreSQL | Regional (synchronous disk replication) | Flags, maintenance windows, IAM auth, connector-based access |
| AlloyDB | PostgreSQL-compatible, custom storage + columnar engine | Regional with read pools | Columnar engine changes analytics plans |
| Azure Flexible Server | Stock PostgreSQL | Zone-redundant HA (sync standby) | Server parameters, Entra auth, storage autogrow, burstable tiers |
| Supabase | Stock PostgreSQL + platform schemas | Provider-managed | RLS-first security model, auth/storage schemas, Supavisor pooler, platform API keys |
| Neon | PostgreSQL on separated compute/storage | Serverless, branching | Cold starts, autosuspend, branch storage lineage, no superuser, pooled vs direct connection strings |
Common Pitfalls
- Diagnosing Aurora storage or replica lag with stock PostgreSQL mental models — its WAL/checkpoint/replication internals are replaced.
- Recommending a
shared_preload_libraries extension the platform doesn't allowlist; check the provider's supported-extension list for the exact engine version.
- Ignoring burst mechanics: EBS/gp3 IOPS, Azure burstable vCPUs, and Neon autosuspend all produce "database got slow" reports with healthy PostgreSQL counters.
- Treating provider automated backups as an archive: retention caps (typically ≤35 days) and no cross-account/cross-provider portability without logical exports or snapshot copies.
- Sizing connections without the platform pooler in mind (RDS Proxy, Supavisor, Neon pooler, PgBouncer sidecars) — or using a transaction-mode pooler while relying on session state.
- Forgetting that major-version upgrades on managed platforms often reset/require re-validating extensions and parameter groups.
- Promising near-zero-downtime migration without confirming logical replication prerequisites on both sides (
wal_level = logical flag support, replication role availability).
Migration Method Ladder
- Dump/restore (
pg_dump/pg_restore): simplest, downtime proportional to size; always the fallback.
- Provider snapshot/import paths: fast within the same provider family (e.g. RDS → Aurora clone, snapshot restore).
- Logical replication / CDC (native pub/sub, AWS DMS, Datastream, Azure DMS): near-zero downtime; requires logical
wal_level, replica identities, and a sequence-sync + cutover plan (see postgres-ha-replication for mechanics).
- Validate after any method: row counts, sequences, extension versions, collation (glibc/ICU version changes corrupt index order — reindex text indexes after crossing OS/collation boundaries), and a timed test cutover.
References
references/managed-postgres.md - per-provider constraints, telemetry, HA/backup models, and migration notes.../postgres/references/best-practices.md - imported domain-expert managed-relevant backup, tuning, auth, and vacuum guidance.../postgres/references/versions/ - version-specific compatibility checks during migrations.
Scripts
scripts/01-cloud-posture.sql - portable service and extension posture.scripts/02-managed-settings.sql - settings usually managed by cloud providers.scripts/03-extension-compatibility.sql - installed and available extensions with schemas and versions.scripts/04-managed-limits.sql - connection, worker, replication, WAL, and timeout settings.scripts/05-migration-readiness.sql - database objects that commonly affect cloud migrations.
Cross-Skill Routing
- Query-level diagnosis on managed instances still goes to
postgres-monitoring (plus provider telemetry).
- Logical replication mechanics for migration cutovers go to
postgres-ha-replication.
- Parameter meaning and sizing go to
postgres-infrastructure; this skill covers whether/how the provider exposes them.
- IAM/Entra database authentication and TLS enforcement go to
postgres-security.
- Backup/restore fundamentals and PITR reasoning go to
postgres-operations.
