postgres-cloud

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

1. 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.
2. 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).
3. 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.
4. On Aurora, Neon, and AlloyDB, remember the storage engine is not stock PostgreSQL — checkpoint/WAL/shared_buffers reasoning changes.
5. 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

1. Diagnosing Aurora storage or replica lag with stock PostgreSQL mental models — its WAL/checkpoint/replication internals are replaced.
2. Recommending a shared_preload_libraries extension the platform doesn't allowlist; check the provider's supported-extension list for the exact engine version.
3. Ignoring burst mechanics: EBS/gp3 IOPS, Azure burstable vCPUs, and Neon autosuspend all produce "database got slow" reports with healthy PostgreSQL counters.
4. 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.
5. 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.
6. Forgetting that major-version upgrades on managed platforms often reset/require re-validating extensions and parameter groups.
7. Promising near-zero-downtime migration without confirming logical replication prerequisites on both sides (wal_level = logical flag support, replication role availability).

Migration Method Ladder

1. Dump/restore (pg_dump/pg_restore): simplest, downtime proportional to size; always the fallback.
2. Provider snapshot/import paths: fast within the same provider family (e.g. RDS → Aurora clone, snapshot restore).
3. 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).
4. 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.