Supported environments
- Azure
- DigitalOcean
- Google Cloud
- OCI
- Private Kubernetes
- Scaleway
How the targets compare
Each row compares a capability of Aurora PostgreSQL with its adaptation on each target. A dash means this profile does not state the capability for that target.Cloud Adapter
Runtime surface
Management surface
Limits
On Azure
PostgreSQL Flexible Server
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 Cloud Adapter deployment 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 DigitalOcean
PostgreSQL
Database and management requests
Your application connects to DigitalOcean Managed PostgreSQL with its native database driver. Tensor9 provisions the target from the AWS database declaration and supplies the target connection settings. RDS management calls go through the adapter in the customer’s Cloud Adapter deployment. It retains the AWS database identity, translates supported operations to DigitalOcean, and reports the target’s status and endpoints. Aurora’s shared storage, Serverless v2 scaling, fast clones, and reader-promotion ranking have no direct equivalent. The adapter maps the cluster to a primary database and separate read-only nodes. Applications using the Aurora Data API send those requests through an HTTP-to-SQL adapter; direct PostgreSQL clients connect to the database.
Queries reach the database directly; only the management calls are translated.
Backups and recovery
DigitalOcean takes daily backups and provides point-in-time recovery for the last seven days. Restore creates a new primary; standby and read-only nodes must be added again. This does not reproduce independently retained RDS snapshots or a custom AWS backup schedule. Verify the recovered data before switching applications to the new endpoint. Keep a separate export if the workload requires retention beyond the provider’s backup window.Standby nodes and read replicas
Standby nodes provide automatic recovery within the database’s region. Read-only nodes are separate resources with their own endpoints and can be placed in another region. Promoting a read-only node creates an independent primary cluster and ends its replication from the original. Account for replication lag before moving writes. This differs from forcing failover to a standby or performing an Aurora Global Database switchover.Settings, access, and pooling
The target plan sets the available database version, capacity, and standby options. Supported engine settings map to DigitalOcean’s database configuration; the reusable RDS parameter-group object has no native equivalent. Check the supported PostgreSQL version and extensions. DigitalOcean offers PgBouncer connection pools, whose transaction and session behavior should be checked against the application’s RDS Proxy use. Connections use DigitalOcean database users, TLS, and trusted-source rules. An AWS role token or customer KMS key is not interchangeable with those database credentials or DigitalOcean-managed encryption keys.Moving data and operating the database
Copy existing data using the engine’s dump and restore tools or a supported online migration workflow. Check schema, users, required extensions or plugins, and application queries before switching connection settings. DigitalOcean operates the database service. The customer controls the plan, access rules, application cutover, and permissions for target monitoring. RDS event subscriptions and Performance Insights do not become the same AWS services on DigitalOcean.On Google Cloud
Cloud SQL for PostgreSQL
How it works
Your application’s PostgreSQL driver connects directly to Cloud SQL for 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 Cloud Adapter deployment 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. 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 OCI
OCI Database with PostgreSQL
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 Cloud Adapter deployment 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 and Scaleway
PostgreSQL (CloudNativePG)
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 Cloud Adapter deployment 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 target 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 Cloud Adapter deployment runs a single CloudNativePG cluster; cross-region readers or a standby region would need a second Cloud Adapter deployment.
- 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.On Scaleway
Scaleway Managed Database for PostgreSQL
Service level agreements
Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider’s own SLA. Each origin-to-target pair has its own terms or an explicit pending status. See the SLA tables, measurement rules, and scaling conditions.Aurora PostgreSQL to PostgreSQL Flexible Server
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Forazure::1.0.0::postgresql::flexible, these rows apply to the RDS/Aurora API adapter, not to native PostgreSQL or MySQL connections. Application SQL commonly goes directly to the target database and therefore has no adapter translation latency to guarantee. The RDS control runtime retains logical intent, exposes status and reconciles target resources. The selected profile defines which directed operations and request options are covered.
How the latency targets were chosen
Bounded database status responses: 20 ms monthly p99.DescribeDBClusterSnapshots, DescribeDBClusters. The control adapter reads its durable database records and checks native status; reading the adapter’s stored request history and current resource records counts as fabric work.
Database lifecycle request acceptance: 30 ms monthly p99. CreateDBClusterSnapshot, CreateDBInstance, CreateGlobalCluster, DescribeDBClusters, FailoverDBCluster, FailoverGlobalCluster, ModifyDBCluster, ModifyDBInstance, RestoreDBClusterFromSnapshot, RestoreDBClusterToPointInTime, StartDBCluster, StopDBCluster, SwitchoverGlobalCluster. The RDS adapter durably records the requested change before its background workers update target resources. Waiting for those adapter records and coordination still counts as fabric time, not database query time.
Bounded database parameter requests: 20 ms monthly p99. DescribeDBParameters, ModifyDBClusterParameterGroup, ModifyDBParameterGroup. Parameter validation and logical-group persistence precede mapping to target flags; provider restart timing is distinct from adapter request handling.
Bounded Data API translation: 5 ms monthly p99. BatchExecuteStatement, BeginTransaction, CommitTransaction, ExecuteStatement, RollbackTransaction. Data API requests require JSON/parameter decoding, native SQL dispatch and result conversion; they are distinct from application connections that speak SQL directly.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Control-plane load is measured in logical resources, status polling and concurrent changes, not application SQL QPS. Aggressive Describe loops can exhaust adapter/log capacity even when database query load is small. Tensor9 scales the API and reconciliation workers within agreed resource and polling limits; the customer selects database compute, storage, connections and HA. Native database provisioning or failover speed cannot be improved merely by scaling control-plane replicas. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA.Example and diagnosis
Modifyorders-db to change an allowed parameter and poll its status at an agreed interval. The request-acceptance row covers adapter validation and durable intent; a database restart can take longer without breaching that row. Separately measure an application’s SELECT directly against the target endpoint: that SQL latency is not the RDS adapter’s 20 or 30 ms control budget.
Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
Aurora PostgreSQL to PostgreSQL (CloudNativePG)
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Forcloudnative::1.0.0::postgresql, these rows apply to the RDS/Aurora API adapter, not to native PostgreSQL or MySQL connections. Application SQL commonly goes directly to the target database and therefore has no adapter translation latency to guarantee. The RDS control runtime retains logical intent, exposes status and reconciles target resources. The selected profile defines which directed operations and request options are covered.
How the latency targets were chosen
Bounded database status responses: 20 ms monthly p99.DescribeDBClusterSnapshots, DescribeDBClusters. The control adapter reads its durable database records and checks native status; reading the adapter’s stored request history and current resource records counts as fabric work.
Database lifecycle request acceptance: 30 ms monthly p99. CreateDBClusterSnapshot, CreateDBInstance, DescribeDBClusters, FailoverDBCluster, ModifyDBCluster, ModifyDBInstance, RestoreDBClusterFromSnapshot, RestoreDBClusterToPointInTime, StartDBCluster, StopDBCluster. The RDS adapter durably records the requested change before its background workers update target resources. Waiting for those adapter records and coordination still counts as fabric time, not database query time.
Bounded database parameter requests: 20 ms monthly p99. DescribeDBParameters, ModifyDBClusterParameterGroup, ModifyDBParameterGroup. Parameter validation and logical-group persistence precede mapping to target flags; provider restart timing is distinct from adapter request handling.
Bounded Data API translation: 5 ms monthly p99. BatchExecuteStatement, BeginTransaction, CommitTransaction, ExecuteStatement, RollbackTransaction. Data API requests require JSON/parameter decoding, native SQL dispatch and result conversion; they are distinct from application connections that speak SQL directly.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Control-plane load is measured in logical resources, status polling and concurrent changes, not application SQL QPS. Aggressive Describe loops can exhaust adapter/log capacity even when database query load is small. Tensor9 scales the API and reconciliation workers within agreed resource and polling limits; the customer selects database compute, storage, connections and HA. Native database provisioning or failover speed cannot be improved merely by scaling control-plane replicas. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA.Example and diagnosis
Modifyorders-db to change an allowed parameter and poll its status at an agreed interval. The request-acceptance row covers adapter validation and durable intent; a database restart can take longer without breaching that row. Separately measure an application’s SELECT directly against the target endpoint: that SQL latency is not the RDS adapter’s 20 or 30 ms control budget.
Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
Aurora PostgreSQL to PostgreSQL
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Fordigitalocean::1.0.0::database::postgresql, these rows apply to the RDS/Aurora API adapter, not to native PostgreSQL or MySQL connections. Application SQL commonly goes directly to the target database and therefore has no adapter translation latency to guarantee. The RDS control runtime retains logical intent, exposes status and reconciles target resources. The selected profile defines which directed operations and request options are covered.
How the latency targets were chosen
Bounded database status responses: 20 ms monthly p99.DescribeDBClusters. The control adapter reads its durable database records and checks native status; reading the adapter’s stored request history and current resource records counts as fabric work.
Database lifecycle request acceptance: 30 ms monthly p99. CreateDBCluster, CreateDBClusterSnapshot, CreateDBInstance, CreateGlobalCluster, DeleteDBCluster, DescribeDBClusters, FailoverDBCluster, FailoverGlobalCluster, ModifyDBCluster, RestoreDBClusterFromSnapshot, RestoreDBClusterToPointInTime, SwitchoverGlobalCluster. The RDS adapter durably records the requested change before its background workers update target resources. Waiting for those adapter records and coordination still counts as fabric time, not database query time.
Bounded database parameter requests: 20 ms monthly p99. DescribeDBParameters, ModifyDBClusterParameterGroup, ModifyDBParameterGroup. Parameter validation and logical-group persistence precede mapping to target flags; provider restart timing is distinct from adapter request handling.
Bounded Data API translation: 5 ms monthly p99. BatchExecuteStatement, BeginTransaction, CommitTransaction, ExecuteStatement, RollbackTransaction. Data API requests require JSON/parameter decoding, native SQL dispatch and result conversion; they are distinct from application connections that speak SQL directly.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Control-plane load is measured in logical resources, status polling and concurrent changes, not application SQL QPS. Aggressive Describe loops can exhaust adapter/log capacity even when database query load is small. Tensor9 scales the API and reconciliation workers within agreed resource and polling limits; the customer selects database compute, storage, connections and HA. Native database provisioning or failover speed cannot be improved merely by scaling control-plane replicas. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA.Example and diagnosis
Modifyorders-db to change an allowed parameter and poll its status at an agreed interval. The request-acceptance row covers adapter validation and durable intent; a database restart can take longer without breaching that row. Separately measure an application’s SELECT directly against the target endpoint: that SQL latency is not the RDS adapter’s 20 or 30 ms control budget.
Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
Aurora PostgreSQL to AlloyDB for PostgreSQL (Aurora management adapter)
Deployment availability. The Aurora PostgreSQL-to-AlloyDB management backend is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter and operations are deployed and named in a signed agreement. Application PostgreSQL connections use AlloyDB directly and have no adapter SQL-latency target here.
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
The Aurora PostgreSQL management adapter validates cluster and member requests, retains AWS-shaped identities and reconciles AlloyDB resources. These estimates describe adapter handling once the declared exact target is deployed. Applications speak PostgreSQL directly to AlloyDB; SQL execution, backup work and native readiness are not hidden within a 20 or 30 ms management-request budget.How the latency targets were chosen
Bounded cluster and member status: 20 ms monthly p99.DescribeDBClusters, DescribeDBInstances. Includes durable control-state read, native-status lookup and AWS response mapping.
Cluster and member lifecycle admission: 30 ms monthly p99. CreateDBCluster, CreateDBInstance, DeleteDBCluster, DeleteDBInstance, ModifyDBCluster, ModifyDBInstance. Includes bounded Aurora request validation, logical identity allocation, durable commit and reconciliation scheduling.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Independent clusters reconcile concurrently while writes to one cluster and its members follow generation order. Qualification fixes clusters, members per cluster, returned status records, settings bytes, polling rate and concurrent changes. Native AlloyDB quota and compute capacity are separate from adapter handler capacity. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A successful lifecycle call means complete desired state is durable, not that AlloyDB is ready. The adapter preserves the Aurora cluster/member relationship and writer-versus-reader identities, refuses unsupported Aurora settings, and never reports a foreign database as adapter-managed. Status reflects observed target readiness rather than an optimistic synthetic success.Example and diagnosis
After this adapter is deployed, CreateDBCluster for one bounded PostgreSQL cluster records an AWS-shaped cluster identity within the 30 ms p99 target. AlloyDB provisioning continues separately. DescribeDBClusters reads the same identity and honest observed status within the 20 ms target; an application’s SELECT uses its direct PostgreSQL connection and neither number applies to it. Usetensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
Aurora PostgreSQL to Cloud SQL for PostgreSQL
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Forgoogle::1.0.0::cloudsql::postgresql, these rows apply to the RDS/Aurora API adapter, not to native PostgreSQL or MySQL connections. Application SQL commonly goes directly to the target database and therefore has no adapter translation latency to guarantee. The RDS control runtime retains logical intent, exposes status and reconciles target resources. The selected profile defines which directed operations and request options are covered.
How the latency targets were chosen
Bounded database status responses: 20 ms monthly p99.DescribeDBClusterSnapshots, DescribeDBClusters. The control adapter reads its durable database records and checks native status; reading the adapter’s stored request history and current resource records counts as fabric work.
Database lifecycle request acceptance: 30 ms monthly p99. CreateDBClusterSnapshot, CreateDBInstance, CreateGlobalCluster, DescribeDBClusters, FailoverDBCluster, FailoverGlobalCluster, ModifyDBCluster, ModifyDBInstance, RestoreDBClusterFromSnapshot, RestoreDBClusterToPointInTime, StartDBCluster, StopDBCluster, SwitchoverGlobalCluster. The RDS adapter durably records the requested change before its background workers update target resources. Waiting for those adapter records and coordination still counts as fabric time, not database query time.
Bounded database parameter requests: 20 ms monthly p99. DescribeDBParameters, ModifyDBClusterParameterGroup, ModifyDBParameterGroup. Parameter validation and logical-group persistence precede mapping to target flags; provider restart timing is distinct from adapter request handling.
Bounded Data API translation: 5 ms monthly p99. BatchExecuteStatement, BeginTransaction, CommitTransaction, ExecuteStatement, RollbackTransaction. Data API requests require JSON/parameter decoding, native SQL dispatch and result conversion; they are distinct from application connections that speak SQL directly.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Control-plane load is measured in logical resources, status polling and concurrent changes, not application SQL QPS. Aggressive Describe loops can exhaust adapter/log capacity even when database query load is small. Tensor9 scales the API and reconciliation workers within agreed resource and polling limits; the customer selects database compute, storage, connections and HA. Native database provisioning or failover speed cannot be improved merely by scaling control-plane replicas. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA.Example and diagnosis
Modifyorders-db to change an allowed parameter and poll its status at an agreed interval. The request-acceptance row covers adapter validation and durable intent; a database restart can take longer without breaching that row. Separately measure an application’s SELECT directly against the target endpoint: that SQL latency is not the RDS adapter’s 20 or 30 ms control budget.
Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
Aurora PostgreSQL to OCI Database with PostgreSQL
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Foroci::1.0.0::psql, these rows apply to the RDS/Aurora API adapter, not to native PostgreSQL or MySQL connections. Application SQL commonly goes directly to the target database and therefore has no adapter translation latency to guarantee. The RDS control runtime retains logical intent, exposes status and reconciles target resources. The selected profile defines which directed operations and request options are covered.
How the latency targets were chosen
Bounded database status responses: 20 ms monthly p99.DescribeDBClusterSnapshots, DescribeDBClusters. The control adapter reads its durable database records and checks native status; reading the adapter’s stored request history and current resource records counts as fabric work.
Database lifecycle request acceptance: 30 ms monthly p99. CreateDBClusterSnapshot, CreateDBInstance, DescribeDBClusters, ModifyDBCluster, ModifyDBInstance, RestoreDBClusterFromSnapshot, StartDBCluster, StopDBCluster. The RDS adapter durably records the requested change before its background workers update target resources. Waiting for those adapter records and coordination still counts as fabric time, not database query time.
Bounded database parameter requests: 20 ms monthly p99. DescribeDBParameters, ModifyDBClusterParameterGroup, ModifyDBParameterGroup. Parameter validation and logical-group persistence precede mapping to target flags; provider restart timing is distinct from adapter request handling.
Bounded Data API translation: 5 ms monthly p99. BatchExecuteStatement, BeginTransaction, CommitTransaction, ExecuteStatement, RollbackTransaction. Data API requests require JSON/parameter decoding, native SQL dispatch and result conversion; they are distinct from application connections that speak SQL directly.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Control-plane load is measured in logical resources, status polling and concurrent changes, not application SQL QPS. Aggressive Describe loops can exhaust adapter/log capacity even when database query load is small. Tensor9 scales the API and reconciliation workers within agreed resource and polling limits; the customer selects database compute, storage, connections and HA. Native database provisioning or failover speed cannot be improved merely by scaling control-plane replicas. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database’s configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA.Example and diagnosis
Modifyorders-db to change an allowed parameter and poll its status at an agreed interval. The request-acceptance row covers adapter validation and durable intent; a database restart can take longer without breaching that row. Separately measure an application’s SELECT directly against the target endpoint: that SQL latency is not the RDS adapter’s 20 or 30 ms control budget.
Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
Aurora PostgreSQL to Scaleway Managed Database for PostgreSQL
SLA status: Not applicable This mapping provisions a native database. SQL clients connect directly to it; this directed mapping does not expose an RDS management adapter endpoint. Database availability and query latency are covered by the database provider, not a Tensor9 request-processing SLA.Install and run
The documentation and SLAs are public. Downloading and running the Cloud Adapter binary requires an entitled customer account. SetT9_API_KEY as described in Install and Authenticate, then list the adapters your account may use with this origin: