Queries reach the database directly; only the management calls are translated.
#### Database connections Aurora uses an AWS-specific storage layer but exposes the PostgreSQL wire protocol to your application. Cloud SQL for PostgreSQL supports that protocol. Your SQL, drivers, object-relational mappers (ORMs), prepared statements, data types, and transaction semantics remain unchanged; the target replaces Aurora's storage layer. AWS and Aurora add SQL functions for moving data through S3, invoking Lambda, and machine learning. These functions have no equivalent on the target. Queries that call them return an error. #### Database management At runtime your application and operational tooling keep making the same RDS calls they make today: describe the cluster, take a snapshot, restore to a point in time, add a reader, trigger a failover, stop and start, change the instance class or a parameter. For the supported operations, the adapter accepts RDS requests and uses the RDS response format, translating the operation to Cloud SQL: on-demand backups and restores, point-in-time restore, read replicas, manual failover, stop / start, and machine-type, storage, and database-flag updates. The adapter also serves the Aurora Data API (SQL over HTTPS, transactions included), executing each statement over a native connection to the backend database. Aurora's global database is served by the adapter as well: Cloud SQL has no global-cluster object, so the adapter keeps the cluster container itself and maps its members and role changes onto Cloud SQL's cross-region read replicas, with planned switchover and unplanned failover translating to the target's managed promote. With Max, your tooling uses CreateDBCluster and CreateDBInstance through the RDS adapter to create a logical Aurora cluster and its members on Cloud SQL. Tensor9 retains durable logical cluster and member state and reconciles it with the target resources: accepted requests are recorded, then native resources are created or removed asynchronously. DescribeDBClusters and DescribeDBInstances report status and endpoints. DeleteDBInstance removes members; DeleteDBCluster removes the cluster after its members are gone. Your application's SQL connection goes directly to the database. With the Infrastructure-only alternative, Tensor9 compiles the declared cluster infrastructure into native Cloud SQL resources. You manage those resources through the target's own tools; serving runtime RDS API requests requires Max.
Tensor9 translates RDS management requests to the target API and returns RDS responses.
#### Limitations △ Where Aurora and Cloud SQL stay different * **Aurora-specific settings have no counterpart.** Failover priority / promotion tiers, Serverless v2 autoscaling, global write forwarding, and I/O-Optimized storage are Aurora-specific. * **Event subscriptions are not served.** RDS event notifications publish to SNS; Cloud Monitoring is a different model with no direct counterpart. * **Parameter groups retain their logical identity.** Tensor9 retains named parameter groups and their overrides. Supported explicit PostgreSQL parameters become Cloud SQL database flags; the group object itself stays with Tensor9 rather than becoming a native object on Cloud SQL. The group family and PostgreSQL version must match, and target limits on allowed values and restart requirements still apply. RDS-specific parameters and settings outside the target's settable list are rejected. #### Other considerations **Migration.** Moving the data itself is a one-time step, covered by this page's migration note: logical dump / restore, or logical replication for a low-downtime cutover. This page describes steady state after cutover. **Operations.** The customer owns the Cloud SQL service in their Google Cloud: maintenance windows, quotas, and pricing are Google's. **Features and capacity.** The comparison table on this page lists database features and high-availability differences. Check the target service's pricing and capacity limits when sizing the deployment. ## On Azure | Operation | Area | Support | Depth | Notes | | ------------------------------------------------------------------------------------------------------------------------------------ | ------------- | ------------ | ------------ | -------------------------------------------------------------------------------------------------------- | | AWS/Aurora-proprietary SQL: aws\_s3.*, aws\_lambda.invoke, Aurora ML (aws\_sagemaker / aws\_comprehend), aurora\_* / apg\_plan\_mgmt | SQL functions | Out of scope | Full surface | AWS and Aurora extension functions with no counterpart on vanilla PostgreSQL; a query calling them fails | | pgwire protocol (application SQL) | Wire protocol | Supported | Common | wire-compatible PostgreSQL; application SQL is unchanged | #### How it works Your application's PostgreSQL driver connects directly to Azure Database for PostgreSQL Flexible Server. These database requests are the **data plane**. The driver and PostgreSQL wire protocol stay unchanged, and Tensor9 adds no proxy, translation, or latency to the query path. Management requests, such as snapshots, restore, replicas, failover, and configuration changes, form the **control plane**. Tensor9 serves the RDS API in the customer's appliance and translates those requests to the target's management API. The sections below describe which operations have equivalents and which return errors.
Queries reach the database directly; only the management calls are translated.
#### Database connections Aurora uses an AWS-specific storage layer but exposes the PostgreSQL wire protocol to your application. Azure Database for PostgreSQL Flexible Server supports that protocol. Your SQL, drivers, object-relational mappers (ORMs), prepared statements, data types, and transaction semantics remain unchanged; the target replaces Aurora's storage layer. AWS and Aurora add SQL functions for moving data through S3, invoking Lambda, and machine learning. These functions have no equivalent on the target. Queries that call them return an error. #### Database management At runtime your application and operational tooling keep making the same RDS calls they make today: describe the cluster, take a snapshot, restore to a point in time, add a reader, trigger a failover, stop and start, change the instance class or a parameter. For the supported operations, the adapter accepts RDS requests and uses the RDS response format, translating the operation to the Flexible Server: on-demand backups and restores, point-in-time restore, read replicas, manual failover, stop / start, and compute, storage, and server-parameter updates. The adapter also serves the Aurora Data API (SQL over HTTPS, transactions included), executing each statement over a native connection to the backend database. Aurora's global database is served by the adapter as well: the Flexible Server has no global-cluster object, so the adapter keeps the cluster container itself and maps its members and role changes onto cross-region read replicas, with planned switchover and unplanned failover translating to the target's managed replica promotion operation. With Max, your tooling uses CreateDBCluster and CreateDBInstance through the RDS adapter to create a logical Aurora cluster and its members on Azure PostgreSQL Flexible Server. Tensor9 retains durable logical cluster and member state and reconciles it with the target resources: accepted requests are recorded, then native resources are created or removed asynchronously. DescribeDBClusters and DescribeDBInstances report status and endpoints. DeleteDBInstance removes members; DeleteDBCluster removes the cluster after its members are gone. Your application's SQL connection goes directly to the database. With the Infrastructure-only alternative, Tensor9 compiles the declared cluster infrastructure into native Azure PostgreSQL Flexible Server resources. You manage those resources through the target's own tools; serving runtime RDS API requests requires Max.
Tensor9 translates RDS management requests to the target API and returns RDS responses.
#### Limitations △ Where Aurora and PostgreSQL Flexible Server stay different * **Aurora-specific settings have no counterpart.** Failover priority / promotion tiers, Serverless v2 autoscaling, global write forwarding, and I/O-Optimized storage are Aurora-specific. * **Event subscriptions are not served.** RDS event notifications publish to SNS; Azure Monitor is a different model with no direct counterpart. * **Parameter groups retain their logical identity.** Tensor9 retains named parameter groups and their overrides. Supported explicit PostgreSQL parameters become Azure server parameters; the group object itself stays with Tensor9 rather than becoming a native object on the Flexible Server. The group family and PostgreSQL version must match, and target limits on allowed values and restart requirements still apply. RDS-specific parameters and settings outside the target's settable list are rejected. #### Other considerations **Migration.** Moving the data itself is a one-time step, covered by this page's migration note: logical dump / restore, or logical replication for a low-downtime cutover. This page describes steady state after cutover. **Operations.** The customer owns the Flexible Server in their Azure subscription: maintenance windows, quotas, and pricing are Microsoft's. **Features and capacity.** The comparison table on this page lists database features and high-availability differences. Check the target service's pricing and capacity limits when sizing the deployment. ## On OCI | Operation | Area | Support | Depth | Notes | | ------------------------------------------------------------------------------------------------------------------------------------ | ------------- | ------------ | ------------ | -------------------------------------------------------------------------------------------------------- | | AWS/Aurora-proprietary SQL: aws\_s3.*, aws\_lambda.invoke, Aurora ML (aws\_sagemaker / aws\_comprehend), aurora\_* / apg\_plan\_mgmt | SQL functions | Out of scope | Full surface | AWS and Aurora extension functions with no counterpart on vanilla PostgreSQL; a query calling them fails | | pgwire protocol (application SQL) | Wire protocol | Supported | Common | wire-compatible PostgreSQL; application SQL is unchanged | #### How it works Your application's PostgreSQL driver connects directly to OCI Database with PostgreSQL. These database requests are the **data plane**. The driver and PostgreSQL wire protocol stay unchanged, and Tensor9 adds no proxy, translation, or latency to the query path. Management requests, such as snapshots, restore, replicas, failover, and configuration changes, form the **control plane**. Tensor9 serves the RDS API in the customer's appliance and translates those requests to the target's management API. The sections below describe which operations have equivalents and which return errors.
Queries reach the database directly; only the management calls are translated.
#### Database connections Aurora uses an AWS-specific storage layer but exposes the PostgreSQL wire protocol to your application. OCI Database with PostgreSQL supports that protocol. Your SQL, drivers, object-relational mappers (ORMs), prepared statements, data types, and transaction semantics remain unchanged; the target replaces Aurora's storage layer. AWS and Aurora add SQL functions for moving data through S3, invoking Lambda, and machine learning. These functions have no equivalent on the target. Queries that call them return an error. #### Database management At runtime your application and operational tooling keep making the same RDS calls they make today. The adapter accepts RDS requests and uses the RDS response format for the supported operations, translating them to OCI: on-demand backups and restore-from-backup, in-region readers, stop / start, and compute, storage, and configuration updates. The documented adapter mapping does not promise translation of every native OCI capability into Aurora semantics; the limitations below distinguish those boundaries. Each unsupported operation returns an error. The adapter also serves the Aurora Data API (SQL over HTTPS, transactions included), executing each statement over a native connection to the backend database. With Max, your tooling uses CreateDBCluster and CreateDBInstance through the RDS adapter to create a logical Aurora cluster and its members on OCI PostgreSQL. Tensor9 retains durable logical cluster and member state and reconciles it with the target resources: accepted requests are recorded, then native resources are created or removed asynchronously. DescribeDBClusters and DescribeDBInstances report status and endpoints. DeleteDBInstance removes members; DeleteDBCluster removes the cluster after its members are gone. Your application's SQL connection goes directly to the database. With the Infrastructure-only alternative, Tensor9 compiles the declared cluster infrastructure into native OCI PostgreSQL resources. You manage those resources through the target's own tools; serving runtime RDS API requests requires Max.
Tensor9 translates RDS management requests to the target API and returns RDS responses.
#### Limitations △ Where Aurora and OCI PostgreSQL stay different * **Parameter groups retain their logical identity.** Tensor9 retains named parameter groups and their overrides. Supported explicit PostgreSQL parameters become OCI PostgreSQL settings; the group object itself stays with Tensor9 rather than becoming a native object on OCI PostgreSQL. The group family and PostgreSQL version must match, and target limits on allowed values and restart requirements still apply. RDS-specific parameters and settings outside the target's settable list are rejected. * **Native point-in-time recovery needs a configured policy.** OCI retains WAL and periodic backups under a point-in-time recovery policy. Recovery creates a new database system at a timestamp within the active recovery window. The documented adapter mapping does not promise AWS point-in-time restore translation. * **Native local failover is separate from AWS failover translation.** OCI exposes FailoverDbSystem for user-initiated failover to an existing local replica. The documented adapter mapping does not promise translation of the AWS failover operation. * **Native cross-region standbys do not establish an Aurora global database mapping.** OCI supports readable warm standby systems in up to three disaster recovery regions. Replication is asynchronous and can lag; promotion and switchover are manual, with no automatic cross-region failover. Restore is not supported for either the primary or warm standby while configured for this replication. The documented adapter mapping does not promise Aurora global-cluster operations, global-reader routing, or automated promotion. * **No in-place major-version upgrade.** Major PostgreSQL upgrades on OCI are create-new-and-migrate. * **Aurora-specific settings and the shared RDS gaps apply too.** Failover priority tiers, Serverless v2, global write forwarding, I/O-Optimized storage and event subscriptions have no counterpart. #### Other considerations **Migration.** Moving the data itself is a one-time step, covered by this page's migration note: logical dump / restore, or logical replication for a low-downtime cutover. This page describes steady state after cutover. **Operations.** The customer owns the database service in their OCI tenancy: maintenance windows, quotas, and pricing are Oracle's. **Features and capacity.** The comparison table on this page lists database features and high-availability differences. Check the target service's pricing and capacity limits when sizing the deployment. ## On Private Kubernetes | Operation | Area | Support | Depth | Notes | | ------------------------------------------------------------------------------------------------------------------------------------ | ------------- | ------------ | ------------ | -------------------------------------------------------------------------------------------------------- | | AWS/Aurora-proprietary SQL: aws\_s3.*, aws\_lambda.invoke, Aurora ML (aws\_sagemaker / aws\_comprehend), aurora\_* / apg\_plan\_mgmt | SQL functions | Out of scope | Full surface | AWS and Aurora extension functions with no counterpart on vanilla PostgreSQL; a query calling them fails | | pgwire protocol (application SQL) | Wire protocol | Supported | Common | wire-compatible PostgreSQL; application SQL is unchanged | #### How it works Your application's PostgreSQL driver connects directly to CloudNativePG. These database requests are the **data plane**. The driver and PostgreSQL wire protocol stay unchanged, and Tensor9 adds no proxy, translation, or latency to the query path. Management requests, such as snapshots, restore, replicas, failover, and configuration changes, form the **control plane**. Tensor9 serves the RDS API in the customer's appliance and translates those requests to the target's management API. The sections below describe which operations have equivalents and which return errors.
Queries reach the database directly; only the management calls are translated.
#### Database connections Aurora uses an AWS-specific storage layer but exposes the PostgreSQL wire protocol to your application. CloudNativePG supports that protocol. Your SQL, drivers, object-relational mappers (ORMs), prepared statements, data types, and transaction semantics remain unchanged; the target replaces Aurora's storage layer. AWS and Aurora add SQL functions for moving data through S3, invoking Lambda, and machine learning. These functions have no equivalent on the target. Queries that call them return an error. #### Database management At runtime your application and operational tooling keep making the same RDS calls they make today. The adapter accepts RDS requests and uses the RDS response format for the supported operations, translating them to CloudNativePG's Kubernetes resources: backups and restores onto its backup and recovery objects, point-in-time restore onto its native PITR, readers onto the cluster's instance count, manual failover onto replica promotion, stop / start onto scaling the cluster down and up, and parameter changes onto the cluster's PostgreSQL configuration. Managed connection pooling (the role RDS Proxy plays) is served by CloudNativePG's built-in pooler. The adapter also serves the Aurora Data API (SQL over HTTPS, transactions included), executing each statement over a native connection to the backend database. When your product is deployed into the customer environment, Tensor9 compiles the cluster your stack already declares into the equivalent CloudNativePG resources and sets the endpoint and credentials into your application's configuration. The control-plane adapter then covers the management calls your running system makes.
Tensor9 translates RDS management requests to the target API and returns RDS responses.
#### Limitations △ Where Aurora and CloudNativePG stay different * **No global database.** The appliance runs a single CloudNativePG cluster; cross-region readers or a standby region would need a second appliance. * **Aurora-specific settings have no counterpart.** Failover priority / promotion tiers, Serverless v2 autoscaling, global write forwarding, and I/O-Optimized storage are Aurora-specific. * **Events are Kubernetes-native.** RDS event notifications publish to SNS; here the equivalents are Kubernetes events and Prometheus alerts, a different model. * **Parameter groups become individual settings.** Each PostgreSQL parameter translates to the cluster's configuration; the group object itself does not cross. #### Other considerations **Migration.** Moving the data itself is a one-time step, covered by this page's migration note: logical dump / restore, or logical replication for a low-downtime cutover. This page describes steady state after cutover. **Operations.** CloudNativePG is self-operated: after cutover the customer's team runs the cluster (backups, upgrades, failover drills), with no cloud database vendor behind it. **Features and capacity.** The comparison table on this page lists database features and high-availability differences. Check the target service's pricing and capacity limits when sizing the deployment. [Service Catalog](/service-adapters/catalog).