RDS MySQL

On this page

• Coverage by target cloud
• How the targets compare
  • Max adaptation
  • Infrastructure-only adaptation
• On Google Cloud
• On Azure
• On OCI
• On Private Kubernetes
• Service level agreements
  • RDS MySQL to MySQL Flexible Server
  • RDS MySQL to DigitalOcean Managed MySQL
  • RDS MySQL to Cloud SQL for MySQL
  • RDS MySQL to OCI MySQL Database (HeatWave)
  • RDS MySQL to Percona XtraDB Cluster (MySQL)
  • RDS MySQL to Scaleway Managed Database for MySQL
• Debug this service

​

Coverage by target cloud

​

How the targets compare

Each row compares a capability of RDS MySQL with its adaptation on each target. A dash means this row is not stated for that target.

​

Max adaptation

​

Runtime surface

​

Management surface

​

Limits

​

Infrastructure-only adaptation

​

Runtime surface

​

Management surface

​

Limits

​

On Google Cloud

​

How it works

Your application’s MySQL driver connects directly to Cloud SQL for MySQL. Tensor9 provisions the database from the RDS instance declaration and sets the application’s endpoint and credentials. SQL requests form the data plane. RDS management requests form the control plane: Tensor9 accepts those requests in the customer’s appliance and translates snapshots, restores, replicas, failover, and configuration changes to the Cloud SQL admin API.

An aws_db_instance (engine = mysql) compiles to a native Cloud SQL for MySQL instance; the workload keeps its driver and speaks the MySQL protocol straight to the database, no proxy in the query path.

​

Cross-region read replicas

A Cloud SQL primary replicates asynchronously to up to seven read replicas in total, within its region or across regions. A cross-region replica can be promoted to a standalone primary for migration or disaster recovery. RDS allows up to fifteen replicas, so check the required replica count before cutover. Replicas can lag behind the primary; send reads that must see a just-completed write to the primary.

Cloud SQL keeps cross-region read replicas: a primary serves in-region and cross-region read replicas (up to seven per primary), and a cross-region replica is promotable for regional failover or DR.

​

Regional-instance HA

RDS Multi-AZ maps to a Cloud SQL regional instance with a primary in one zone and a synchronous standby in another. Writes replicate to regional persistent disk in both zones before acknowledgement. This provides a recovery point objective of zero (RPO 0) for HA failover: committed writes are retained. Enterprise Plus has a 99.99% monthly-uptime SLA and reduced-downtime maintenance options. The applicable availability terms depend on the edition and configuration.

Cloud SQL HA is a regional instance: a synchronous standby in a second zone over a regional persistent disk, so failover loses no committed write; Enterprise Plus backs a 99.99% availability SLA.

​

Parameters as database flags

Settable MySQL parameters become per-instance database flags, such as max_connections and long_query_time. The reusable RDS parameter-group object has no counterpart. If several RDS instances share a parameter group, its supported values are applied to each Cloud SQL instance. Check the selected MySQL version and Cloud SQL’s allowed flag values; parameters outside that list cannot be applied.

Each MySQL parameter becomes a Cloud SQL database flag; the parameter-group object itself and any parameter outside Cloud SQL’s settable list do not cross.

​

Pooling, IAM auth, and the customer key

RDS Proxy connection pooling maps to Cloud SQL Managed Connection Pooling, which requires Enterprise Plus. RDS IAM database authentication maps to Cloud SQL IAM database authentication. A customer KMS key maps to a customer-managed encryption key (CMEK) in Cloud KMS. The customer controls access to that key in the target project.

Managed pooling maps to Cloud SQL Managed Connection Pooling (Enterprise Plus), RDS IAM auth to Cloud SQL IAM database authentication, and a KMS customer key to a CMEK in Cloud KMS.

​

Limitations

Check these differences when selecting the Cloud SQL edition, instance size, and database version. △ Where RDS for MySQL and Cloud SQL diverge

• Read replicas cap at seven per primary. Cloud SQL allows seven replicas per primary against RDS’s fifteen, in- or cross-region, so a large read fan-out is sized against seven before cutover.
• Managed pooling requires Enterprise Plus. RDS Proxy’s pooling maps to Cloud SQL Managed Connection Pooling, available only on the Enterprise Plus edition, so an instance that must pool is placed on that edition.
• Parameter groups flatten to per-instance database flags. Each MySQL parameter becomes a Cloud SQL flag; the reusable group object and any parameter outside Cloud SQL’s settable-flag list do not cross.
• The engine build and available versions are Google’s. Cloud SQL runs the MySQL versions and flags its catalog exposes, so an instance requiring a version or flag Cloud SQL does not offer is reconciled to a supported one before cutover.
• RDS-proprietary extras have no counterpart. Event subscriptions (SNS), S3 / Lambda integration SQL, and Enhanced Monitoring are RDS-specific; zero-ETL replicates to BigQuery via Datastream, not Redshift.

​

Other considerations

Move data with mysqldump or Cloud SQL Database Migration Service. Validate the copied data and required engine features before switching connections. Google operates the database; the customer controls maintenance settings and access to Query Insights in their project. Query Insights uses Google’s performance tools rather than the RDS Performance Insights interface.

​

On Azure

​

How it works

Your application’s MySQL driver connects directly to Azure Database for MySQL Flexible Server. Tensor9 provisions the server from the RDS instance declaration and sets the application’s endpoint and credentials. SQL requests form the data plane. RDS management requests form the control plane: Tensor9 accepts those requests in the customer’s appliance and translates snapshots, restores, replicas, failover, and configuration changes to Azure’s management API.

An aws_db_instance (engine = mysql) compiles to a native Azure Database for MySQL Flexible Server; the workload keeps its driver and speaks the MySQL protocol straight to the database, no proxy in the query path.

​

Compute tiers and zone-redundant HA

Flexible Server has Burstable, General Purpose, and Business Critical compute tiers. The mapping selects a size for the requested CPU and memory, and a tier that supports the required database features. High availability and read replicas require General Purpose or Business Critical; Burstable supports neither. Zone-redundant HA places a synchronous standby in a second zone and uses zone-redundant storage. It provides a recovery point objective of zero (RPO 0) for HA failover and a 99.99% availability SLA, subject to the service’s terms.

Flexible Server has Burstable, General Purpose, and Business Critical tiers; zone-redundant HA is a synchronous standby in a second zone (ZRS), available on General Purpose and Business Critical, with a 99.99% availability SLA.

​

Read replicas

A Flexible Server source uses MySQL binary-log replication to maintain up to ten read replicas, within its region or across regions. Replicas require General Purpose or Business Critical. Replication is asynchronous. Send reads that must see a just-completed write to the source; replicas may not yet have received that write.

A Flexible Server source replicates asynchronously (binlog position-based) to up to ten read replicas, in the same region or another region, for read scale-out.

​

Server parameters

Settable values in an RDS parameter group map to Flexible Server parameters, including settings such as max_connections. Azure configures each server separately, so the reusable parameter-group object has no counterpart. The mapping applies supported values to each server that used the group. Azure controls the allowed values; static parameters require a restart, and some settings can be chosen only when the server is created.

Parameter values are applied separately to each Flexible Server.

​

Pooling, Entra ID auth, and the customer key

RDS IAM database authentication maps to Microsoft Entra ID authentication. A customer KMS key maps to a customer-managed key in Key Vault. Flexible Server has no managed connection pooler equivalent to RDS Proxy. If the workload needs pooling, configure an application pool or operate a separate pooler such as ProxySQL.

RDS IAM auth maps to Microsoft Entra ID authentication and a KMS customer key to a Key Vault customer-managed key; RDS Proxy’s managed pooling has no counterpart (customer-managed ProxySQL).

​

Limitations

Check these differences when selecting the Flexible Server tier, instance size, and database version. △ Where RDS for MySQL and Azure Flexible Server diverge

• The Burstable tier supports neither HA nor replicas. Zone-redundant HA and read replicas require the General Purpose or Business Critical tier, so an instance that needs either is placed off Burstable.
• No managed connection pooler. The Flexible Server has no RDS-Proxy equivalent; pooling is customer-managed ProxySQL on the customer’s own VM, an operational component to plan for.
• Read replicas cap at ten and lag asynchronously. A source serves up to ten binlog-based replicas, so a read path needing read-after-write goes to the source and a fan-out near the ceiling is sized against ten.
• Parameter groups flatten to per-server parameters. Each MySQL parameter becomes a server parameter; the reusable group object and any parameter outside the Flexible Server’s settable list do not cross.
• The engine build and available versions are Azure’s. The Flexible Server runs the MySQL major/minor versions and server plugins Azure’s catalog offers, so an instance requiring a version or plugin Azure does not expose is reconciled to a supported one before cutover.
• RDS-proprietary extras have no counterpart. Event subscriptions (SNS), S3 / Lambda integration SQL, and Enhanced Monitoring are RDS-specific; zero-ETL replicates to Microsoft Fabric, not Redshift.

​

Other considerations

Move data with mysqldump or Azure Database Migration Service. Validate the copied data and required engine features before switching connections. Microsoft operates the database. The customer controls maintenance settings and access to Azure’s Query Performance Insight; it uses Azure’s performance tools rather than the RDS Performance Insights interface.

​

On OCI

​

How it works

Your application’s MySQL driver connects directly to an OCI MySQL HeatWave DB system. Tensor9 provisions it from the RDS instance declaration and sets the application’s endpoint and credentials. SQL requests form the data plane. RDS management requests form the control plane: Tensor9 accepts those requests in the customer’s appliance and translates snapshots, restores, replicas, failover, and configuration changes to OCI’s management API.

An aws_db_instance (engine = mysql) compiles to a native OCI MySQL HeatWave DB system; the workload keeps its driver and speaks the MySQL protocol straight to the database, no proxy in the query path.

​

Optional analytics with HeatWave

The DB system runs MySQL for transactional queries. An optional HeatWave cluster adds in-memory analytics nodes and loads table data into its analytics engine. Applications can use those tables for analytics without maintaining a separate extraction and loading pipeline. The analytics cluster is optional. An RDS migration can use the MySQL DB system without enabling it. Check the selected MySQL version and supported plugins for the workload.

A HeatWave cluster loads MySQL table data into its analytics engine.

​

Read replicas and cross-region replication

An OCI MySQL DB system supports up to eighteen read replicas in its own region, distributed across availability and fault domains. Each replica has an endpoint. OCI’s managed read-replica resource does not span regions. Cross-region replication instead uses a separate DB system and an asynchronous replication channel. That database can serve reads, but requires separate configuration and can lag behind the source. A cross-region backup copy supports restore, not live reads.

Managed read replicas stay in-region; a cross-region replication channel targets a separate DB system.

​

Group Replication HA

OCI MySQL high availability uses a three-node Group Replication group across availability or fault domains. A majority must acknowledge transaction changes before commit. The service provides a recovery point objective of zero (RPO 0) for automatic HA failover, retaining committed writes. Oracle operates the HA group. Its 99.99% monthly-uptime SLA applies under the service’s availability terms.

OCI MySQL HeatWave HA is a three-node Group Replication quorum (Paxos) across availability or fault domains; a quorum acknowledges each commit, so failover loses no committed write, with a 99.99% SLA.

​

Parameters, native auth, and the customer key

Settable MySQL parameters map to OCI configuration variables. The reusable RDS parameter-group object and parameters outside OCI’s allowed list have no counterpart. A customer KMS key maps to a customer-managed key in OCI Vault. OCI MySQL uses native MySQL accounts rather than RDS IAM database authentication. A workload using RDS IAM authentication needs target database credentials.

MySQL parameters map to OCI MySQL configuration variables and a KMS customer key to an OCI Vault customer-managed key; RDS IAM database auth has no counterpart (native MySQL accounts).

​

Limitations

Check these differences when sizing the DB system and planning authentication, connection pooling, and recovery. △ Where RDS for MySQL and OCI MySQL HeatWave diverge

• Cross-region replication needs a separate DB system. Managed read replicas stay in-region (up to eighteen). A replication channel can maintain a readable database in another region, but it needs separate configuration and can lag behind the source.
• No cloud-IAM database authentication. OCI MySQL authenticates with native MySQL accounts, so a workload on RDS IAM database auth moves that path to native credentials.
• No managed connection pooler. The DB system has no RDS-Proxy equivalent; connection pooling is a component to run in front of it.
• Parameters flatten to configuration variables. Each settable MySQL parameter becomes a configuration value; the group object and any parameter outside OCI’s settable list do not cross.
• The engine build and available versions are Oracle’s. The DB system runs the MySQL versions OCI offers, so an instance requiring a version OCI does not publish is reconciled to a supported one before cutover.
• RDS-proprietary extras have no counterpart. S3 / Lambda integration SQL and Enhanced Monitoring are RDS-specific, and zero-ETL has no Redshift counterpart.

​

Other considerations

Move data with MySQL Shell dump utilities or a HeatWave inbound replication channel. Validate the copied data before switching connections. Oracle operates the database; the customer controls maintenance and access to OCI’s performance tools. These tools use OCI’s interface rather than RDS Performance Insights. Configure a separate pooler if needed: an OCI load balancer routes connections but does not pool them.

​

On Private Kubernetes

​

How it works

An aws_db_instance with engine = "mysql" compiles to a PerconaXtraDBCluster custom resource (pxc.percona.com/v1), which the Percona operator reconciles into a running Galera cluster on Kubernetes. The workload connects with its unchanged MySQL driver and speaks the MySQL wire protocol straight to the cluster’s HAProxy endpoint; Tensor9 adds no proxy or protocol translation to this connection. Your application sends SQL over the MySQL protocol; these requests are the data plane. Management requests, called the control plane, go through the Tensor9 adapter in the customer’s appliance. It translates RDS requests for snapshots, restore, replicas, failover, and configuration changes to the Percona operator’s Kubernetes resources.

An aws_db_instance (engine = mysql) compiles to a PerconaXtraDBCluster custom resource, a Galera cluster fronted by HAProxy, which the workload reaches over the native MySQL protocol.

​

Architecture

Percona XtraDB Cluster uses Galera to distribute transaction changes in a common order. Each node checks those changes for conflicts, a process called certification. A successful commit does not mean every other node has already applied the change; reads sent to another node may need synchronization. This differs from RDS Multi-AZ’s primary-and-standby architecture. The cluster accepts writes only while a majority of nodes are in contact. Use an odd node count, typically three. If a two-node cluster loses the connection between its nodes, neither can form a majority, so both refuse writes to prevent conflicting changes. An odd node count avoids adding a node without increasing the number of failures the cluster can tolerate.

Galera checks replicated transactions for conflicts. Three nodes can retain a majority after losing one node.

​

Instance sizing and storage

engine_version selects the Percona Server for MySQL image; allocated_storage sizes each pod’s PersistentVolumeClaim (PVC); and instance_class maps to CPU and memory requests. The selected Kubernetes StorageClass determines volume type and encryption. Each database pod must fit on a cluster node. Storage growth requires explicitly increasing the PVC size on a StorageClass that supports expansion; it does not happen automatically as usage grows.

Instance fields configure the cluster: engine_version to the image tag, allocated_storage to the PVC size, and instance_class to the pods’ CPU and memory.

​

Backups and point-in-time recovery

RDS backup settings map to the Percona operator’s backup configuration. The operator schedules full backups to S3-compatible or Azure-compatible object storage and supports on-demand backup objects. Point-in-time recovery comes with it: with PITR enabled, the operator runs a binlog-collector pod that continuously streams the cluster’s binary logs to the same object storage, and a restore replays those logs forward onto the nearest full backup to reach a chosen transaction or timestamp. Set the retention and recovery window on the operator. Backups are stored in the customer’s bucket.

The Percona operator schedules full backups and collects binary logs for point-in-time recovery.

​

Parameters, pooling, and the RDS extras

Settable MySQL parameters, such as innodb_buffer_pool_size and max_connections, map to the cluster configuration. RDS-only parameters and the reusable parameter-group object have no counterpart. HAProxy routes connections without RDS Proxy-style pooling. Configure an application pool or separate pooler if required. The cluster uses native MySQL accounts and Kubernetes monitoring; RDS IAM authentication, S3 and Lambda integration SQL, Enhanced Monitoring, and the RDS-managed CA certificate are unsupported.

MySQL parameters map to the cluster configuration. HAProxy routes connections; it does not replace RDS Proxy connection pooling. IAM auth, integration SQL, and Enhanced Monitoring have no counterpart.

​

Operating the cluster

The customer’s team operates the cluster after migration, including upgrades, backup verification, failover tests, and capacity. There is no managed database availability SLA. Additional nodes and the HAProxy read endpoint serve reads within one region; cross-region reads require a second cluster. The adapter returns RDS request and response formats for management calls and executes those calls on the Percona operator’s resources. Moving existing data and operating the cluster are separate tasks.

RDS is AWS-operated with an availability SLA; the Percona cluster is self-operated on Kubernetes with no vendor SLA, and cross-region reads need a second cluster.

​

Limitations

Check the operating requirements and RDS-specific gaps before choosing a self-managed cluster. △ Where RDS for MySQL and Percona XtraDB Cluster diverge

• No vendor availability SLA. The cluster is self-operated on Kubernetes, so unlike RDS Multi-AZ there is no cloud vendor SLA to point to; availability is a property of how the team runs the cluster.
• No cross-region read scale-out. The appliance runs one cluster, so live cross-region reads or a standby region require a second cluster and a replication link.
• A majority must remain connected. Three nodes tolerate one unavailable node; losing the majority interrupts normal database service until quorum is restored.
• Synchronous replication has a per-write cost. Write-set certification across the cluster adds coordination to every commit, so a write-heavy workload tuned for a single RDS writer validates throughput on the cluster before cutover.
• Capacity is cluster-bound. A pod fits a Kubernetes node and a PersistentVolumeClaim sizes on its StorageClass; there is no RDS instance-type catalog and no usage-triggered storage autoscaling.
• RDS-specific settings have no counterpart. IAM database authentication, S3 / Lambda integration SQL, Enhanced Monitoring, and the RDS-managed CA certificate are RDS-specific; the cluster uses native MySQL accounts and Kubernetes-native observability.

​

Other considerations

Move data with mysqldump or replication, then validate the copy before switching connections. Test backup restoration and failover as part of cutover. The customer’s team continues to operate the cluster, including upgrades, monitoring, and capacity.

​

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.

​

RDS MySQL to MySQL 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

For azure::1.0.0::mysql::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, DescribeDBInstances, DescribeDBSnapshots. 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, CreateDBInstanceReadReplica, CreateDBSnapshot, DescribeDBClusters, DescribeDBInstances, FailoverDBCluster, ModifyDBCluster, ModifyDBInstance, PromoteReadReplica, RebootDBInstance, RestoreDBClusterFromSnapshot, RestoreDBClusterToPointInTime, RestoreDBInstanceFromDBSnapshot, RestoreDBInstanceToPointInTime, StartDBInstance, StopDBInstance. 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. 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

Modify orders-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.

​

RDS MySQL to DigitalOcean Managed MySQL

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

For digitalocean::1.0.0::database::mysql, 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. DescribeDBInstances. 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. CreateDBInstance, CreateDBInstanceReadReplica, CreateDBSnapshot, DeleteDBInstance, DescribeDBInstances, ModifyDBInstance, PromoteReadReplica, RebootDBInstance, RestoreDBInstanceFromDBSnapshot, RestoreDBInstanceToPointInTime. 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. 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

Modify orders-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.

​

RDS MySQL to Cloud SQL for MySQL

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

For google::1.0.0::cloudsql::mysql, 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, DescribeDBInstances, DescribeDBSnapshots. 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, CreateDBInstanceReadReplica, CreateDBSnapshot, DescribeDBClusters, DescribeDBInstances, FailoverDBCluster, ModifyDBCluster, ModifyDBInstance, PromoteReadReplica, RebootDBInstance, RestoreDBClusterFromSnapshot, RestoreDBClusterToPointInTime, RestoreDBInstanceFromDBSnapshot, RestoreDBInstanceToPointInTime, StartDBInstance, StopDBInstance. 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. 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

Modify orders-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.

​

RDS MySQL to OCI MySQL Database (HeatWave)

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

For oci::1.0.0::mysql, 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, DescribeDBInstances, DescribeDBSnapshots. 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, CreateDBInstanceReadReplica, CreateDBSnapshot, DescribeDBClusters, DescribeDBInstances, FailoverDBCluster, ModifyDBCluster, ModifyDBInstance, PromoteReadReplica, RebootDBInstance, RestoreDBClusterFromSnapshot, RestoreDBClusterToPointInTime, RestoreDBInstanceFromDBSnapshot, RestoreDBInstanceToPointInTime, StartDBInstance, StopDBInstance. 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. 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

Modify orders-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.

​

RDS MySQL to Percona XtraDB Cluster (MySQL)

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

For percona::1.0.0::mysql, 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, DescribeDBInstances, DescribeDBSnapshots. 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, CreateDBInstanceReadReplica, CreateDBSnapshot, DescribeDBClusters, DescribeDBInstances, FailoverDBCluster, ModifyDBCluster, ModifyDBInstance, PromoteReadReplica, RebootDBInstance, RestoreDBClusterFromSnapshot, RestoreDBClusterToPointInTime, RestoreDBInstanceFromDBSnapshot, RestoreDBInstanceToPointInTime, StartDBInstance, StopDBInstance. 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. 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

Modify orders-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.

​

RDS MySQL to Scaleway Managed Database for MySQL

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.

​

Debug this service

For requests through a service adapter, use Explain and request diagnostics to investigate the selected mapping. Follow the BYOC service-adapter debugging runbook to capture and interpret the diagnostic evidence. Service Catalog.