> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # Trade-offs in AWS RDS PostgreSQL > Choose a PostgreSQL operating model, connection architecture and recovery procedure for your application. For an application using ordinary PostgreSQL, the important choice is often who operates the database, not how SQL is translated. Your PostgreSQL driver normally connects directly to the target engine. Cloud Adapter handles supported RDS management calls such as describing databases, taking backups and changing configuration. A service adapter includes both origin and target: **RDS PostgreSQL → Cloud SQL** and **RDS PostgreSQL → CloudNativePG** are different adapters. Cloud SQL and CloudNativePG alone are their backends. The comparisons below keep RDS PostgreSQL as the origin while choosing the target and operating model. These are separate paths. A successful RDS `DescribeDBInstances` call does not prove that your application can authenticate, use its extensions or recover a transaction after a connection breaks. ## General trade-offs Choose the target environment first, then compare the PostgreSQL services available there. A customer's requirement to stay in Microsoft Azure does not create a choice between Azure PostgreSQL and Google Cloud SQL. Where an environment has one documented backend, the useful comparison is with the application's RDS requirements and the operating choices within that backend. Open the [RDS PostgreSQL service profile](/cloud-adapter/service-catalog/aws/databases-storage/rds-postgresql) for the target environment before selecting a deployment. Check each RDS management operation separately from SQL connectivity; a reachable PostgreSQL database does not establish support for the RDS APIs your tooling uses. ### SQL compatibility and management behavior Choose the database at the logical database/deployment boundary. Then choose capacity, HA, backup policy and connection mode inside that deployment. A client cannot change its database backend for one SQL statement by attaching a tuning tag. Managed PostgreSQL options include Cloud SQL, Azure Database for PostgreSQL Flexible Server, DigitalOcean Managed PostgreSQL, OCI Database with PostgreSQL and Scaleway Managed PostgreSQL. CloudNativePG is the customer-operated Kubernetes alternative. Your customer's allowed environment constrains the menu; a Google Cloud service is not a local Azure alternative. Before comparing prices, check: * Engine major version, extension versions, collations and role privileges. * AWS-specific SQL functions. A PostgreSQL connection does not make `aws_s3.*` or `aws_lambda.invoke` native functions on another cloud. * Session features such as temporary tables, prepared statements, advisory locks and `SET` commands. * Connection count during deployments, failover and autoscaling, not only normal traffic. * Recovery of schema, roles, extension data, connection secrets and network access alongside table contents. ### Recovery and operating cost Budget HA compute, replicas, backup retention, storage growth, network transfer, connection pooling and on-call work. The application team owns schema, query plans, connection budgets and restore acceptance on every backend. A managed provider operates database infrastructure; a customer-operated deployment also needs owners for the database operator, storage and replica lifecycle. Migration requires copying schema and data, catching up writes and switching connections after verification. Preserving the old database does not make rollback safe after new writes reach the target. Tuning cannot supply an unavailable extension or preserve an uncommitted transaction after a broken connection. ## Google Cloud ### Cloud SQL for PostgreSQL The **RDS PostgreSQL → Cloud SQL adapter** uses a provider-operated PostgreSQL database with native SQL connections and mapped RDS management operations. This is a candidate for transactional SaaS applications whose versions, extensions and operational requirements fit Cloud SQL's controls. Google owns the engine infrastructure and standby; your team owns schema migrations, connection demand and the application's recovery procedure. The trade-off is service-defined extension builds, settable parameters, maintenance controls and machine shapes. Tensor9 retains logical RDS parameter groups and applies supported explicit overrides to native flags; this does not grant access to every PostgreSQL or `rds.*` setting. An application requiring an unavailable extension build must change that requirement or its deployment design. For a billing workload, record the required extension inventory, client connection budget and regional recovery objective. Exercise transaction retry after connection loss, then measure a restore with the actual application role. The [Cloud SQL profile](/cloud-adapter/service-catalog/aws/databases-storage/rds-postgresql#on-google-cloud) describes the management mappings. The Private Kubernetes adapter is discussed separately below; it is not a second Google Cloud service in this menu. ### Prove that a Cloud SQL backup is usable This probe uses Cloud SQL as a concrete recovery fixture, not a preferred backend. It deliberately restores into a separate empty test instance. It does not overwrite a running application's database. Apply the same state, access and recovery-time assertions using each candidate's supported backup procedure. Use a disposable Google Cloud project, a source Cloud SQL PostgreSQL instance named `rds-recovery-source`, and a separate empty compatible instance named `rds-recovery-restored`. Both must be test-only. The restore replaces the destination instance's data. Create a database named `tradeoff_probe` on the source. Configure PostgreSQL connection services named `tradeoff-source` and `tradeoff-restored` with the correct host, database, role and verified TLS/approved connector route. These are names in your local [PostgreSQL service file](https://www.postgresql.org/docs/current/libpq-pgservice.html), not environment variables. Store passwords through your normal protected credential mechanism, not in command arguments. The role needs permission to create a schema in this disposable database. Your Google identity needs permission to take and restore backups and inspect operations. Establish private network access before the test. Record the engine and required extension versions. Run this through the source's native SQL connection. Schema creation deliberately fails if the name already exists; inspect it rather than overwriting an earlier exercise. ```bash theme={null} psql 'service=tradeoff-source' -X -v ON_ERROR_STOP=1 <<'SQL' CREATE SCHEMA tradeoff_recovery; CREATE TABLE tradeoff_recovery.orders ( id text PRIMARY KEY, status text NOT NULL ); INSERT INTO tradeoff_recovery.orders VALUES ('restore-check-A', 'before-backup'); SELECT * FROM tradeoff_recovery.orders; SQL ``` In the Google Cloud console, select **rds-recovery-source → Backups**, create an on-demand backup, and wait for successful completion. Record its exact ID and completion time. Check the source instance name again before proceeding. A backup request being accepted is not a completed recovery point. If this is also a test of RDS API adaptation, issue the supported snapshot request through the adapter and use its explanation plus native backup state to identify the same completed recovery point. See [Understanding Behavior with Explain](/cloud-adapter/debugging/explain). ```bash theme={null} psql 'service=tradeoff-source' -X -v ON_ERROR_STOP=1 \ -c "UPDATE tradeoff_recovery.orders SET status = 'after-backup' WHERE id = 'restore-check-A';" ``` Select the completed backup and restore it to **rds-recovery-restored**, never to the source. Review the destination and overwrite warning before confirming. Start timing at the restore request and stop only when the application role can run its normal queries. Re-establish the destination's connection service if its connection details changed. Use the provider's [PostgreSQL backup restoration procedure](https://docs.cloud.google.com/sql/docs/postgres/backup-recovery/restoring). ```bash theme={null} psql 'service=tradeoff-restored' -X -v ON_ERROR_STOP=1 \ -c "SELECT id, status FROM tradeoff_recovery.orders;" psql 'service=tradeoff-source' -X -v ON_ERROR_STOP=1 \ -c "SELECT id, status FROM tradeoff_recovery.orders;" ``` Expected: the restored copy says `before-backup`; the source says `after-backup`. Now connect using the real application role and verify required schema access, extensions and a representative transaction. Record restoration time, reconnect time and any manual work separately. Wrong data, missing grants/extensions or a missed recovery budget stops acceptance. First distinguish an incorrectly chosen backup from restore or access failure. Do not relax the application's permissions to make the test pass. After retaining nonsecret evidence, delete `rds-recovery-restored` and `rds-recovery-source` through the provider console. Review deletion protection and final-backup choices explicitly. Inspect retained backups and replicas, and delete only this exercise's retained resources when permitted. Remove the two local connection-service entries and test credentials. Verify there is no continuing test compute or storage charge. ## Microsoft Azure ### Azure Database for PostgreSQL Flexible Server The **RDS PostgreSQL → PostgreSQL Flexible Server adapter** fits Azure-resident applications that want provider-operated PostgreSQL and whose required SQL, extensions and management operations fit the [Azure profile](/cloud-adapter/service-catalog/aws/databases-storage/rds-postgresql#on-azure). SQL goes directly to the database. Supported RDS management requests use the adapter, so application connectivity and management permissions need separate tests. Its strength is a managed database lifecycle inside the customer's Azure environment. The constraints are Azure's supported engine and extension versions, settable parameters, HA configuration and access model. RDS-specific helper functions and settings do not become Azure features. An application with ordinary transactions may fit even when an operations script using an AWS-only setting needs revision. For a write-heavy tenant database, compare available instance/storage configurations under sustained writes, checkpoint activity and maintenance, then test recovery with the application's connection pool. For reporting, test read-replica routing and acceptable lag separately from writer HA. Record the provider's infrastructure responsibilities and your team's responsibility for SQL grants, client retries, backup policy and recovery acceptance. ## DigitalOcean ### Managed PostgreSQL and connection pooling The **RDS PostgreSQL → DigitalOcean Managed PostgreSQL adapter** offers a managed engine, standby/read-node choices and managed PgBouncer pools. It fits applications that can use the documented native settings and recovery model. DigitalOcean's backup timeline and restore-to-new-cluster behavior differ from an RDS snapshot inventory; the [service profile](/cloud-adapter/service-catalog/aws/databases-storage/rds-postgresql#on-digitalocean) explains those differences. For many short-lived workers, compare **direct connections** with **managed PgBouncer** on the same database: | Connection choice | Strength | Constraint | Workload to evaluate | | ------------------------- | ------------------------------------------------------ | -------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Direct native connections | Preserves each client's PostgreSQL session | Every active client consumes a database connection | Long-lived clients or workloads with connection-local state | | Managed PgBouncer | Can bound native connection demand across many clients | Adds admission queueing; session behavior depends on pool mode | Bursty workers whose transactions and session features fit the selected mode | Audit prepared statements, temporary objects, advisory locks, initialization commands, long transactions and credential rotation in the exact mode you intend to use. See DigitalOcean's [pooling modes and connection-pool controls](https://docs.digitalocean.com/products/databases/postgresql/how-to/manage-connection-pools/). A pool cannot make an overloaded database execute more queries merely by accepting more clients. Test a small client cohort with each route during worker-start and deployment bursts. Record native connection count, queue time, transaction outcomes and recovery after disconnects. An endpoint change does not move data, but credential and session changes still need rollback. Managed PgBouncer is distinct from Tensor9's compatibility connection behavior, which does not imply transaction pooling or AWS RDS Proxy semantics. ## OCI ### OCI Database with PostgreSQL The **RDS PostgreSQL → OCI Database with PostgreSQL adapter** is a candidate for applications required to keep their database in OCI and able to use its managed PostgreSQL controls. It preserves the native SQL connection path while translating the documented RDS management operations. Provider-operated infrastructure reduces the database-hosting work your team performs. The important constraint is the distinction between native capabilities and their RDS mappings. OCI's native point-in-time recovery, local failover and cross-region warm standbys do not establish equivalent AWS API translations. Major-version upgrades require a new database and migration. Consult the [OCI profile](/cloud-adapter/service-catalog/aws/databases-storage/rds-postgresql#on-oci) before reusing automated recovery or upgrade scripts. A conventional transactional service can qualify by testing its SQL and using an approved native recovery runbook. A service requiring its existing RDS point-in-time-restore automation unchanged has a different acceptance criterion. Rehearse a restore and major-version migration, including roles, extensions and the application cutover. Measure recovery time using the operational route you will actually authorize. ## Scaleway ### Managed PostgreSQL or CloudNativePG Scaleway has two documented backends: **Scaleway Managed Database for PostgreSQL** and **CloudNativePG** in the Kubernetes deployment. Compare them within Scaleway rather than comparing a Scaleway database with a service in another cloud. | Backend | Strength | Constraint | Workload to evaluate | | ---------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Scaleway Managed Database for PostgreSQL | Provider-operated engine in the customer's Scaleway environment | Native credentials and backup controls replace the corresponding AWS assumptions; verify management-operation coverage separately from SQL access | Conventional SQL applications using native database access and target-managed operations | | CloudNativePG | Control over the PostgreSQL image, operator and storage lifecycle | Customer operates the database and Kubernetes resources; single-cluster mapping does not supply cross-region recovery | Extension/image-specific workloads with a staffed database/platform team | For the managed service, confirm that native credentials are acceptable: the mapping does not preserve IAM database authentication. Backup retention/window and customer-managed encryption-key requirements also need explicit review. A deployed database does not establish a runtime RDS API endpoint. See the [Scaleway managed profile](/cloud-adapter/service-catalog/aws/databases-storage/rds-postgresql#on-scaleway). For CloudNativePG, use the [operator-backed profile](/cloud-adapter/service-catalog/aws/databases-storage/rds-postgresql#on-private-kubernetes-and-scaleway), and include persistent volumes, operator upgrades, backup storage and on-call work in the comparison. Test the exact extension build on both candidates; managed service constraints and the cost of operating a custom image are separate factors. Run the same application recovery assertions on each eligible deployment before choosing. ## Private Kubernetes ### CloudNativePG The **RDS PostgreSQL → CloudNativePG adapter** gives a private deployment control of the PostgreSQL image and database lifecycle. It is useful when a specific extension build, storage arrangement or customer-controlled upgrade schedule matters and the customer can operate the database. It requires ownership of persistent volumes, replica placement, certificates, backup storage, recovery procedures and the operator itself. For an extension-heavy data-processing application, test an extension upgrade against representative data. Restore its backup into the replacement image, then verify owners, grants and extension data. Simulate a lost pod or node in the disposable environment and confirm that the application reconnects to the writable instance. A storage-full alert needs an operator who can expand the actual volume; restarting a pod does not add capacity. The [CloudNativePG profile](/cloud-adapter/service-catalog/aws/databases-storage/rds-postgresql#on-private-kubernetes-and-scaleway) describes a single-cluster deployment, not a cross-region database service. A working Kubernetes cluster alone does not satisfy database recovery requirements. Record extension compatibility, recovery time, operating ownership and full infrastructure cost before accepting this adapter. ## Next steps Next: [Tuning AWS RDS PostgreSQL](/cloud-adapter/tuning/aws-rds-postgresql).