Queries reach the database directly; only the management calls are translated.
#### Database connections RDS for PostgreSQL and Cloud SQL run PostgreSQL. Your SQL, drivers, object-relational mappers (ORMs), prepared statements, data types, and transaction semantics remain unchanged. Your application connects directly to the database. RDS adds SQL helper functions for importing and exporting through S3 and invoking Lambda from a query. These AWS-specific 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 instance, take a snapshot, restore to a point in time, add or promote a read replica, trigger a failover, stop and start, change the instance class or a parameter. The adapter accepts RDS requests, returns RDS response formats, and performs the supported operations on Cloud SQL: on-demand backups and restores, point-in-time restore, read replicas in-region and cross-region, manual failover, stop / start, and machine-type, storage, and database-flag updates. With Max, your tooling uses CreateDBInstance and DeleteDBInstance through the RDS adapter to create and remove a database on Cloud SQL. Tensor9 retains durable logical database state and reconciles it with the managed service: accepted requests are recorded, then the target resources are created or removed asynchronously. Use DescribeDBInstances to follow status and obtain the database endpoint. Your application's SQL connection goes directly to the database. With the Infrastructure-only alternative, Tensor9 compiles the declared database 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 RDS and Cloud SQL stay different * **Deletion is asynchronous and skips a final snapshot.** DeleteDBInstance requires SkipFinalSnapshot=true and does not retain automated backups. Deletion protection must be disabled. The database remains in the deleting state until its native resources are gone; a failed teardown reports failure rather than successful removal. * **Subnet groups place the private endpoint.** An explicit DB subnet group retains adapted subnets from one VPC spanning at least two availability zones. Tensor9 selects a subnet deterministically and places the private connection endpoint there; Google manages the database compute in its own service network. The selected subnet must match the configured Google Cloud project, region, network and IPv4 range. Readiness requires an accepted private connection and, for public access, the public address. Public access with an explicit group also requires pre-existing private services access on that VPC and the configured client allowlist. Tensor9 does not create shared private services access, translate AWS security groups, or provide AWS split-horizon DNS. Without an explicit group, the configured network applies; Tensor9 does not create an AWS default subnet group. * **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. Default groups are read-only. Changes marked pending-reboot wait for RebootDBInstance; immediate changes that require a restart are rejected. An attached group cannot be deleted or replaced, and source formulas are not supported. * **RDS-specific settings have no counterpart.** The CA certificate, Enhanced Monitoring, processor features, and Kerberos / AD domain join are RDS-specific. #### Other considerations **Migration.** Move existing data with a logical dump and restore, or use logical replication to reduce the cutover pause. Check the selected PostgreSQL version and required extensions, then switch application connections after validating the copied data. **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 integration SQL: aws\_s3.\*, aws\_lambda.invoke, rds\_tools | SQL functions | Out of scope | Full surface | RDS extension functions with no counterpart on vanilla PostgreSQL; a query calling them fails | | pgwire protocol (application SQL) | Wire protocol | Supported | Common | same PostgreSQL engine; 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 does not proxy or translate these queries. 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 Azure Database for PostgreSQL Flexible Server runs the same PostgreSQL engine as RDS. SQL, drivers, object-relational mappers (ORMs), prepared statements, data types, and transaction semantics remain unchanged. Your application connects directly to the server. RDS adds SQL helper functions for importing and exporting through S3 and invoking Lambda from a query. These AWS-specific 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 instance, take a snapshot, restore to a point in time, add or promote a read replica, trigger a failover, stop and start, change the instance class or a parameter. The adapter accepts RDS requests, returns RDS response formats, and performs the supported operations on the Flexible Server: on-demand backups and restores, point-in-time restore, read replicas in-region and cross-region, manual failover, stop / start, and compute, storage, and server-parameter updates. With Max, your tooling uses CreateDBInstance and DeleteDBInstance through the RDS adapter to create and remove a database on Azure PostgreSQL Flexible Server. Tensor9 retains durable logical database state and reconciles it with the managed service: accepted requests are recorded, then the target resources are created or removed asynchronously. Use DescribeDBInstances to follow status and obtain the database endpoint. Your application's SQL connection goes directly to the database. With the Infrastructure-only alternative, Tensor9 compiles the declared database 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 RDS and PostgreSQL Flexible Server stay different * **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. * **RDS-specific settings have no counterpart.** The CA certificate, Enhanced Monitoring, processor features, and Kerberos / AD domain join are RDS-specific. #### Other considerations **Migration.** Move existing data with a logical dump and restore, or use logical replication to reduce the cutover pause. Check the selected PostgreSQL version and required extensions, then switch application connections after validating the copied data. **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 integration SQL: aws\_s3.\*, aws\_lambda.invoke, rds\_tools | SQL functions | Out of scope | Full surface | RDS extension functions with no counterpart on vanilla PostgreSQL; a query calling them fails | | pgwire protocol (application SQL) | Wire protocol | Supported | Common | same PostgreSQL engine; 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 does not proxy or translate these queries. 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 OCI Database with PostgreSQL runs the same engine as RDS for PostgreSQL. SQL, drivers, object-relational mappers (ORMs), prepared statements, data types, and transaction semantics remain unchanged. Your application connects directly to the database. RDS adds SQL helper functions for importing and exporting through S3 and invoking Lambda from a query. These AWS-specific 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, returns RDS response formats, and performs the supported operations on OCI where a counterpart exists: on-demand backups and restore-from-backup, in-region read replicas, stop / start, and compute, storage, and configuration updates. The documented adapter mapping does not promise translation of every native OCI capability into RDS semantics; the limitations below distinguish those boundaries. Each unsupported operation returns an error. With Max, your tooling uses CreateDBInstance and DeleteDBInstance through the RDS adapter to create and remove a database on OCI PostgreSQL. Tensor9 retains durable logical database state and reconciles it with the managed service: accepted requests are recorded, then the target resources are created or removed asynchronously. Use DescribeDBInstances to follow status and obtain the database endpoint. Your application's SQL connection goes directly to the database. With the Infrastructure-only alternative, Tensor9 compiles the declared database 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 RDS 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 the AWS replica 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 AWS cross-region replica semantics. * **No in-place major-version upgrade.** Major PostgreSQL upgrades on OCI are create-new-and-migrate. * **The shared RDS gaps apply here too.** Event subscriptions, rds.\* parameters, and RDS-specific settings (the CA certificate, Enhanced Monitoring, Kerberos / AD) have no counterpart, as on every target. #### Other considerations **Migration.** Move existing data with a logical dump and restore, or use logical replication to reduce the cutover pause. Check the selected PostgreSQL version and required extensions, then switch application connections after validating the copied data. **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 integration SQL: aws\_s3.\*, aws\_lambda.invoke, rds\_tools | SQL functions | Out of scope | Full surface | RDS extension functions with no counterpart on vanilla PostgreSQL; a query calling them fails | | pgwire protocol (application SQL) | Wire protocol | Supported | Common | same PostgreSQL engine; 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 does not proxy or translate these queries. 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 CloudNativePG runs PostgreSQL as a replicated cluster on Kubernetes. Your SQL, drivers, object-relational mappers (ORMs), prepared statements, data types, and transaction semantics remain unchanged. Your application connects directly to the cluster. RDS adds SQL helper functions for importing and exporting through S3 and invoking Lambda from a query. These AWS-specific 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, returns RDS response formats, and performs the supported operations through CloudNativePG's Kubernetes resources: backups and restores onto its backup and recovery objects, point-in-time restore onto its native PITR, read replicas onto the cluster's instance count, manual failover onto replica promotion, stop / start onto hibernating and resuming the cluster while retaining its storage, 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. When your product is deployed into the customer environment, Tensor9 compiles the database your stack already declares into the equivalent CloudNativePG resources and sets the endpoint and credentials in 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 RDS and CloudNativePG stay different * **No cross-region read scale-out.** The appliance runs a single CloudNativePG cluster; a second region would need a second appliance. * **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 and rds.\* parameters are not supported on the target. * **RDS-specific settings have no counterpart.** The CA certificate, Enhanced Monitoring, processor features, and Kerberos / AD domain join are RDS-specific. #### Other considerations **Migration.** Move existing data with a logical dump and restore, or use logical replication to reduce the cutover pause. Check the selected PostgreSQL version and required extensions, then switch application connections after validating the copied data. **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).