> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # RDS MySQL > RDS MySQL APIs with Cloud Adapter. This page describes how RDS MySQL maps to services in the environment where the application runs, including backend choices, supported operations and service-specific behavior. ## Supported environments * Azure * DigitalOcean * Google Cloud * OCI * Private Kubernetes * Scaleway Check the operation and capability tables for the behavior your application depends on. A supported environment does not imply that every operation of the origin service is available. ## How the backends compare Each row compares a capability of RDS MySQL with its adaptation on each backend. A dash means this profile does not state the capability for that backend. ### Cloud Adapter #### Runtime surface | Capability | RDS MySQL | Azure | DigitalOcean | Google Cloud | OCI | Private Kubernetes and Scaleway · Percona XtraDB Cluster (MySQL) | Scaleway · Scaleway Managed Database for MySQL | | - | - | - | - | - | - | - | - | | API coverage | full | high | high | high | high | high (Native protocol and intended management comparison, subject to selected MySQL, Percona XtraDB and operator versions. Existing deployment selection defaults to 8.0 and reduces an explicit patch version to major.minor with a warning; that does not promise the requested RDS patch. Registry version 1.0.0 is not an engine version. Record the resolved image/operator and Max SIP revision, and qualify version-sensitive SQL, extensions and management behavior on that installation.) | partial | #### Management surface | Capability | RDS MySQL | Azure | DigitalOcean | Google Cloud | OCI | Private Kubernetes and Scaleway · Percona XtraDB Cluster (MySQL) | Scaleway · Scaleway Managed Database for MySQL | | - | - | - | - | - | - | - | - | | Snapshot / restore + PITR | Yes | Yes | Partial - seven-day provider backup timeline; restore creates a new cluster | Yes | Yes | Yes | Partial - Scaleway takes scheduled backups and snapshots and restores them to a new instance; RDS snapshot and restore requests are not served | | Zero-ETL integration · Redshift | Yes | Partial - replicates to Microsoft Fabric (OneLake); Redshift itself is not served | No | Partial - replicates to BigQuery (Datastream); Redshift itself is not served | No | No | No | | Read replicas · in-region | Yes | Yes | Yes - separate read-only nodes | Yes | Yes | Yes | Partial - Scaleway offers asynchronous read replicas in the same or another zone; RDS read replicas are not translated into them | | Read replicas · cross-region | Yes | Yes | Partial - read-only node in another region; promotion ends replication from the original | Yes | Partial - cross-region reads require a separate DB system and replication channel; a backup copy supports restore only | No | No - Scaleway read replicas stay within one region | | Managed connection pooling · RDS Proxy | Yes | No - no managed pooler; ProxySQL is customer-managed on your own VM | No - configure an application pool or separate pooler | Yes - Cloud SQL Managed Connection Pooling (Enterprise Plus) | No - no managed pooler; an OCI load balancer can front it but is not a pooler | No - HAProxy routes connections but does not pool them; configure an application pool or separate pooler | No | | Query performance insights · Performance Insights | Yes | Partial - backend-native performance tools; access is controlled by the customer | Partial - backend monitoring differs; customer controls access | Partial - backend-native performance tools; access is controlled by the customer | Partial - backend-native performance tools; access is controlled by the customer | Partial - backend-native performance tools; access is controlled by the customer | Partial - metrics and logs in Scaleway Cockpit; the vendor can't access the Cloud Adapter deployment's console | #### Limits | Capability | RDS MySQL | Azure | DigitalOcean | Google Cloud | OCI | Private Kubernetes and Scaleway · Percona XtraDB Cluster (MySQL) | Scaleway · Scaleway Managed Database for MySQL | | - | - | - | - | - | - | - | - | | Maximum storage | 64 TiB | 16-32 TiB | - | 64 TiB | 128 TiB | limited by persistent volume capacity | 10,000 GB | | vCPU range · smallest to largest instance | 2-384 | 1-96 | - | 1-128 | 2-256 (ECPU) | limited by Kubernetes node resources | 2-8 | | Memory range · smallest to largest instance | 1-4,096 GiB | 2-672 GiB | - | 0.6-864 GiB | 8-1,024 GiB | limited by Kubernetes node resources | 3-29 GB | | Storage autoscaling | Yes | Yes | - | Yes | Yes | No - increase the volume size explicitly; it does not grow with usage | Partial - block storage resizes on demand without downtime; it does not grow automatically | ## On Azure ### MySQL Flexible Server | Operation | Area | Support | Depth | Notes | | - | - | - | - | - | | AWS integration SQL: LOAD DATA FROM S3 / SELECT INTO OUTFILE S3, mysql.lambda\_async, mysql.rds\_\* procedures | SQL functions | Out of scope | Full surface | RDS MySQL extension procedures with no counterpart on vanilla MySQL; a query calling them fails | | MySQL client/server protocol (application SQL) | Wire protocol | Supported | Common | same MySQL engine; application SQL is unchanged | #### 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 Cloud Adapter deployment and translates snapshots, restores, replicas, failover, and configuration changes to Azure's management API. ![Before: on AWS your app talks to an RDS for MySQL instance over the MySQL protocol. After: on Azure the same app with the same driver talks over the same MySQL protocol to a native Azure Database for MySQL Flexible Server, without Tensor9 proxying database traffic.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjAwIiB2aWV3Qm94PSIwIDAgODM2IDIwMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJCZWZvcmU6IG9uIEFXUyB5b3VyIGFwcCB0YWxrcyB0byBhbiBSRFMgZm9yIE15U1FMIGluc3RhbmNlIG92ZXIgdGhlIE15U1FMIHByb3RvY29sLiBBZnRlcjogb24gQXp1cmUgdGhlIHNhbWUgYXBwIHdpdGggdGhlIHNhbWUgZHJpdmVyIHRhbGtzIG92ZXIgdGhlIHNhbWUgTXlTUUwgcHJvdG9jb2wgdG8gYSBuYXRpdmUgQXp1cmUgRGF0YWJhc2UgZm9yIE15U1FMIEZsZXhpYmxlIFNlcnZlciwgd2l0aG91dCBUZW5zb3I5IHByb3h5aW5nIGRhdGFiYXNlIHRyYWZmaWMuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojMzM0MTU1fTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImF6ZjFoIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI2LjUiIG1hcmtlckhlaWdodD0iNi41IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+PHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBzdHlsZT0iZmlsbDojOTRhM2I4Ii8+PC9tYXJrZXI+PC9kZWZzPgo8cmVjdCB4PSIxNiIgeT0iNDAiIHdpZHRoPSIzODAiIGhlaWdodD0iMTQwIiByeD0iMTQiIHN0cm9rZS13aWR0aD0iMS40IiBzdHJva2UtZGFzaGFycmF5PSI1IDUiIHN0eWxlPSJmaWxsOiNmOGZhZmM7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iMzIiIHk9IjYyIiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzk0YTNiOCI+T04gQVdTIFRPREFZPC90ZXh0Pgo8cmVjdCB4PSIzNiIgeT0iODQiIHdpZHRoPSIxNTAiIGhlaWdodD0iNTgiIHJ4PSIxMSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iMTExIiB5PSIxMTAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhIj5Zb3VyIGFwcDwvdGV4dD4KPHRleHQgeD0iMTExIiB5PSIxMjciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5NeVNRTCBkcml2ZXI8L3RleHQ+CjxsaW5lIHgxPSIxODYiIHkxPSIxMTMiIHgyPSIyMjAiIHkyPSIxMTMiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItZW5kPSJ1cmwoI2F6ZjFoKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjIwMyIgeT0iMTA1IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjguNXB4Ij5NeVNRTDwvdGV4dD4KPHJlY3QgeD0iMjIyIiB5PSI4NCIgd2lkdGg9IjE1OCIgaGVpZ2h0PSI1OCIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSIzMDEiIHk9IjEwOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMnB4Ij5SRFMgZm9yIE15U1FMPC90ZXh0Pgo8dGV4dCB4PSIzMDEiIHk9IjEyNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICMzMzQxNTUiPmF3c19kYl9pbnN0YW5jZTwvdGV4dD4KPHJlY3QgeD0iNDQwIiB5PSI0MCIgd2lkdGg9IjM4MCIgaGVpZ2h0PSIxNDAiIHJ4PSIxNCIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0cm9rZS1kYXNoYXJyYXk9IjUgNSIgc3R5bGU9ImZpbGw6I2Y4ZmFmYztzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSI0NTYiIHk9IjYyIiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzk0YTNiODsgZmlsbDojMDQ3ODU3Ij5PTiBBWlVSRTwvdGV4dD4KPHJlY3QgeD0iNDU2IiB5PSI4NCIgd2lkdGg9IjEyMCIgaGVpZ2h0PSI1OCIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSI1MTYiIHk9IjExMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMnB4Ij5Zb3VyIGFwcDwvdGV4dD4KPHRleHQgeD0iNTE2IiB5PSIxMjciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2MDAgMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+c2FtZSBkcml2ZXI8L3RleHQ+CjxsaW5lIHgxPSI1NzYiIHkxPSIxMTMiIHgyPSI2MTAiIHkyPSIxMTMiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItZW5kPSJ1cmwoI2F6ZjFoKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjU5MyIgeT0iMTA1IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjguNXB4Ij5NeVNRTDwvdGV4dD4KPHJlY3QgeD0iNjEyIiB5PSI4NCIgd2lkdGg9IjE5NCIgaGVpZ2h0PSI1OCIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI3MDkiIHk9IjEwOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTc7IGZvbnQtc2l6ZToxMXB4Ij5NeVNRTCBGbGV4aWJsZSBTZXJ2ZXI8L3RleHQ+Cjx0ZXh0IHg9IjcwOSIgeT0iMTI2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij5NeVNRTCBlbmdpbmUgwrcgbmF0aXZlPC90ZXh0Pgo8L3N2Zz4=) ![Before: on AWS your app talks to an RDS for MySQL instance over the MySQL protocol. After: on Azure the same app with the same driver talks over the same MySQL protocol to a native Azure Database for MySQL Flexible Server, without Tensor9 proxying database traffic.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjAwIiB2aWV3Qm94PSIwIDAgODM2IDIwMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJCZWZvcmU6IG9uIEFXUyB5b3VyIGFwcCB0YWxrcyB0byBhbiBSRFMgZm9yIE15U1FMIGluc3RhbmNlIG92ZXIgdGhlIE15U1FMIHByb3RvY29sLiBBZnRlcjogb24gQXp1cmUgdGhlIHNhbWUgYXBwIHdpdGggdGhlIHNhbWUgZHJpdmVyIHRhbGtzIG92ZXIgdGhlIHNhbWUgTXlTUUwgcHJvdG9jb2wgdG8gYSBuYXRpdmUgQXp1cmUgRGF0YWJhc2UgZm9yIE15U1FMIEZsZXhpYmxlIFNlcnZlciwgd2l0aG91dCBUZW5zb3I5IHByb3h5aW5nIGRhdGFiYXNlIHRyYWZmaWMuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojY2JkNWUxfTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImF6ZjFoIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI2LjUiIG1hcmtlckhlaWdodD0iNi41IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+PHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBzdHlsZT0iZmlsbDojNjQ3NDhiIi8+PC9tYXJrZXI+PC9kZWZzPgo8cmVjdCB4PSIxNiIgeT0iNDAiIHdpZHRoPSIzODAiIGhlaWdodD0iMTQwIiByeD0iMTQiIHN0cm9rZS13aWR0aD0iMS40IiBzdHJva2UtZGFzaGFycmF5PSI1IDUiIHN0eWxlPSJmaWxsOiMwZjE3MmE7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iMzIiIHk9IjYyIiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzY0NzQ4YiI+T04gQVdTIFRPREFZPC90ZXh0Pgo8cmVjdCB4PSIzNiIgeT0iODQiIHdpZHRoPSIxNTAiIGhlaWdodD0iNTgiIHJ4PSIxMSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iMTExIiB5PSIxMTAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5Ij5Zb3VyIGFwcDwvdGV4dD4KPHRleHQgeD0iMTExIiB5PSIxMjciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5NeVNRTCBkcml2ZXI8L3RleHQ+CjxsaW5lIHgxPSIxODYiIHkxPSIxMTMiIHgyPSIyMjAiIHkyPSIxMTMiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItZW5kPSJ1cmwoI2F6ZjFoKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjIwMyIgeT0iMTA1IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjguNXB4Ij5NeVNRTDwvdGV4dD4KPHJlY3QgeD0iMjIyIiB5PSI4NCIgd2lkdGg9IjE1OCIgaGVpZ2h0PSI1OCIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSIzMDEiIHk9IjEwOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMnB4Ij5SRFMgZm9yIE15U1FMPC90ZXh0Pgo8dGV4dCB4PSIzMDEiIHk9IjEyNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICNjYmQ1ZTEiPmF3c19kYl9pbnN0YW5jZTwvdGV4dD4KPHJlY3QgeD0iNDQwIiB5PSI0MCIgd2lkdGg9IjM4MCIgaGVpZ2h0PSIxNDAiIHJ4PSIxNCIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0cm9rZS1kYXNoYXJyYXk9IjUgNSIgc3R5bGU9ImZpbGw6IzBmMTcyYTtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSI0NTYiIHk9IjYyIiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzY0NzQ4YjsgZmlsbDojNmVlN2I3Ij5PTiBBWlVSRTwvdGV4dD4KPHJlY3QgeD0iNDU2IiB5PSI4NCIgd2lkdGg9IjEyMCIgaGVpZ2h0PSI1OCIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSI1MTYiIHk9IjExMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMnB4Ij5Zb3VyIGFwcDwvdGV4dD4KPHRleHQgeD0iNTE2IiB5PSIxMjciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2MDAgMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+c2FtZSBkcml2ZXI8L3RleHQ+CjxsaW5lIHgxPSI1NzYiIHkxPSIxMTMiIHgyPSI2MTAiIHkyPSIxMTMiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItZW5kPSJ1cmwoI2F6ZjFoKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjU5MyIgeT0iMTA1IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjguNXB4Ij5NeVNRTDwvdGV4dD4KPHJlY3QgeD0iNjEyIiB5PSI4NCIgd2lkdGg9IjE5NCIgaGVpZ2h0PSI1OCIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSI3MDkiIHk9IjEwOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3Yjc7IGZvbnQtc2l6ZToxMXB4Ij5NeVNRTCBGbGV4aWJsZSBTZXJ2ZXI8L3RleHQ+Cjx0ZXh0IHg9IjcwOSIgeT0iMTI2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij5NeVNRTCBlbmdpbmUgwrcgbmF0aXZlPC90ZXh0Pgo8L3N2Zz4=) Your app keeps its driver and speaks the MySQL protocol straight to the database, no proxy in between. #### 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 offers Burstable, General Purpose, and Business Critical compute tiers. Zone-redundant HA places a synchronous standby in a second availability zone over zone-redundant storage; it is available on the General Purpose and Business Critical tiers, and the Burstable tier supports neither HA nor read replicas.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjEwIiB2aWV3Qm94PSIwIDAgODM2IDIxMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJGbGV4aWJsZSBTZXJ2ZXIgb2ZmZXJzIEJ1cnN0YWJsZSwgR2VuZXJhbCBQdXJwb3NlLCBhbmQgQnVzaW5lc3MgQ3JpdGljYWwgY29tcHV0ZSB0aWVycy4gWm9uZS1yZWR1bmRhbnQgSEEgcGxhY2VzIGEgc3luY2hyb25vdXMgc3RhbmRieSBpbiBhIHNlY29uZCBhdmFpbGFiaWxpdHkgem9uZSBvdmVyIHpvbmUtcmVkdW5kYW50IHN0b3JhZ2U7IGl0IGlzIGF2YWlsYWJsZSBvbiB0aGUgR2VuZXJhbCBQdXJwb3NlIGFuZCBCdXNpbmVzcyBDcml0aWNhbCB0aWVycywgYW5kIHRoZSBCdXJzdGFibGUgdGllciBzdXBwb3J0cyBuZWl0aGVyIEhBIG5vciByZWFkIHJlcGxpY2FzLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhemYyaCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6IzA0Nzg1NyIvPjwvbWFya2VyPjwvZGVmcz4KPHRleHQgeD0iNDE4IiB5PSIyNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjgiPkNPTVBVVEUgVElFUlM8L3RleHQ+CjxyZWN0IHg9IjcwIiB5PSIzOCIgd2lkdGg9IjIxMCIgaGVpZ2h0PSI0MiIgcng9IjEwIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSIxNzUiIHk9IjY0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjExLjVweCI+QnVyc3RhYmxlPC90ZXh0Pgo8cmVjdCB4PSIzMTMiIHk9IjM4IiB3aWR0aD0iMjEwIiBoZWlnaHQ9IjQyIiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjQxOCIgeT0iNjQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXNpemU6MTEuNXB4Ij5HZW5lcmFsIFB1cnBvc2U8L3RleHQ+CjxyZWN0IHg9IjU1NiIgeT0iMzgiIHdpZHRoPSIyMTAiIGhlaWdodD0iNDIiIHJ4PSIxMCIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iNjYxIiB5PSI2NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTc7IGZvbnQtc2l6ZToxMS41cHgiPkJ1c2luZXNzIENyaXRpY2FsPC90ZXh0Pgo8dGV4dCB4PSI0MTgiIHk9IjEwNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjg7IGZpbGw6IzA0Nzg1NyI+Wk9ORS1SRURVTkRBTlQgSEE8L3RleHQ+CjxyZWN0IHg9IjkwIiB5PSIxMTYiIHdpZHRoPSIyODAiIGhlaWdodD0iNTIiIHJ4PSIxMSIgc3Ryb2tlLXdpZHRoPSIxLjYiIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iMjMwIiB5PSIxNDAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXNpemU6MTJweCI+UHJpbWFyeSDCtyB6b25lIDE8L3RleHQ+Cjx0ZXh0IHg9IjIzMCIgeT0iMTU4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij53cml0ZXI8L3RleHQ+CjxsaW5lIHgxPSIzNzAiIHkxPSIxNDIiIHgyPSI0NjIiIHkyPSIxNDIiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItZW5kPSJ1cmwoI2F6ZjJoKSIgc3R5bGU9InN0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjQxNiIgeT0iMTM0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjlweDtmaWxsOiMwNDc4NTciPnN5bmNocm9ub3VzPC90ZXh0Pgo8cmVjdCB4PSI0NjYiIHk9IjExNiIgd2lkdGg9IjI4MCIgaGVpZ2h0PSI1MiIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNiIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2E3ZjNkMCIvPgo8dGV4dCB4PSI2MDYiIHk9IjE0MCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMnB4Ij5TdGFuZGJ5IMK3IHpvbmUgMjwvdGV4dD4KPHRleHQgeD0iNjA2IiB5PSIxNTgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5zeW5jaHJvbm91cyBjb3B5IChaUlMpPC90ZXh0Pgo8cmVjdCB4PSI5MCIgeT0iMTc4IiB3aWR0aD0iNjU2IiBoZWlnaHQ9IjI2IiByeD0iOCIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0eWxlPSJmaWxsOiNmZmZiZWI7c3Ryb2tlOiNmZGU2OGEiLz4KPHRleHQgeD0iNDE4IiB5PSIxOTYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2MDAgMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2I0NTMwOSI+SEEgYW5kIHJlYWQgcmVwbGljYXMgb24gR2VuZXJhbCBQdXJwb3NlIC8gQnVzaW5lc3MgQ3JpdGljYWw7IHRoZSBCdXJzdGFibGUgdGllciBzdXBwb3J0cyBuZWl0aGVyPC90ZXh0Pgo8L3N2Zz4=) ![Flexible Server offers Burstable, General Purpose, and Business Critical compute tiers. Zone-redundant HA places a synchronous standby in a second availability zone over zone-redundant storage; it is available on the General Purpose and Business Critical tiers, and the Burstable tier supports neither HA nor read replicas.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjEwIiB2aWV3Qm94PSIwIDAgODM2IDIxMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJGbGV4aWJsZSBTZXJ2ZXIgb2ZmZXJzIEJ1cnN0YWJsZSwgR2VuZXJhbCBQdXJwb3NlLCBhbmQgQnVzaW5lc3MgQ3JpdGljYWwgY29tcHV0ZSB0aWVycy4gWm9uZS1yZWR1bmRhbnQgSEEgcGxhY2VzIGEgc3luY2hyb25vdXMgc3RhbmRieSBpbiBhIHNlY29uZCBhdmFpbGFiaWxpdHkgem9uZSBvdmVyIHpvbmUtcmVkdW5kYW50IHN0b3JhZ2U7IGl0IGlzIGF2YWlsYWJsZSBvbiB0aGUgR2VuZXJhbCBQdXJwb3NlIGFuZCBCdXNpbmVzcyBDcml0aWNhbCB0aWVycywgYW5kIHRoZSBCdXJzdGFibGUgdGllciBzdXBwb3J0cyBuZWl0aGVyIEhBIG5vciByZWFkIHJlcGxpY2FzLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhemYyaCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6IzZlZTdiNyIvPjwvbWFya2VyPjwvZGVmcz4KPHRleHQgeD0iNDE4IiB5PSIyNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGIiPkNPTVBVVEUgVElFUlM8L3RleHQ+CjxyZWN0IHg9IjcwIiB5PSIzOCIgd2lkdGg9IjIxMCIgaGVpZ2h0PSI0MiIgcng9IjEwIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSIxNzUiIHk9IjY0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjExLjVweCI+QnVyc3RhYmxlPC90ZXh0Pgo8cmVjdCB4PSIzMTMiIHk9IjM4IiB3aWR0aD0iMjEwIiBoZWlnaHQ9IjQyIiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjQxOCIgeT0iNjQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXNpemU6MTEuNXB4Ij5HZW5lcmFsIFB1cnBvc2U8L3RleHQ+CjxyZWN0IHg9IjU1NiIgeT0iMzgiIHdpZHRoPSIyMTAiIGhlaWdodD0iNDIiIHJ4PSIxMCIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iNjYxIiB5PSI2NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3Yjc7IGZvbnQtc2l6ZToxMS41cHgiPkJ1c2luZXNzIENyaXRpY2FsPC90ZXh0Pgo8dGV4dCB4PSI0MTgiIHk9IjEwNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGI7IGZpbGw6IzZlZTdiNyI+Wk9ORS1SRURVTkRBTlQgSEE8L3RleHQ+CjxyZWN0IHg9IjkwIiB5PSIxMTYiIHdpZHRoPSIyODAiIGhlaWdodD0iNTIiIHJ4PSIxMSIgc3Ryb2tlLXdpZHRoPSIxLjYiIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iMjMwIiB5PSIxNDAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXNpemU6MTJweCI+UHJpbWFyeSDCtyB6b25lIDE8L3RleHQ+Cjx0ZXh0IHg9IjIzMCIgeT0iMTU4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij53cml0ZXI8L3RleHQ+CjxsaW5lIHgxPSIzNzAiIHkxPSIxNDIiIHgyPSI0NjIiIHkyPSIxNDIiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItZW5kPSJ1cmwoI2F6ZjJoKSIgc3R5bGU9InN0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjQxNiIgeT0iMTM0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjlweDtmaWxsOiM2ZWU3YjciPnN5bmNocm9ub3VzPC90ZXh0Pgo8cmVjdCB4PSI0NjYiIHk9IjExNiIgd2lkdGg9IjI4MCIgaGVpZ2h0PSI1MiIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNiIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI2MDYiIHk9IjE0MCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMnB4Ij5TdGFuZGJ5IMK3IHpvbmUgMjwvdGV4dD4KPHRleHQgeD0iNjA2IiB5PSIxNTgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5zeW5jaHJvbm91cyBjb3B5IChaUlMpPC90ZXh0Pgo8cmVjdCB4PSI5MCIgeT0iMTc4IiB3aWR0aD0iNjU2IiBoZWlnaHQ9IjI2IiByeD0iOCIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0eWxlPSJmaWxsOiM0MjIwMDY7c3Ryb2tlOiM5MjQwMGUiLz4KPHRleHQgeD0iNDE4IiB5PSIxOTYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2MDAgMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2ZiYmYyNCI+SEEgYW5kIHJlYWQgcmVwbGljYXMgb24gR2VuZXJhbCBQdXJwb3NlIC8gQnVzaW5lc3MgQ3JpdGljYWw7IHRoZSBCdXJzdGFibGUgdGllciBzdXBwb3J0cyBuZWl0aGVyPC90ZXh0Pgo8L3N2Zz4=) Zone-redundant HA adds a synchronous standby in a second zone, on General Purpose and Business Critical only. #### 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 with binary-log position-based replication to up to ten read replicas, which can be in the same region or in another region for read scale-out.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTg4IiB2aWV3Qm94PSIwIDAgODM2IDE4OCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJBIEZsZXhpYmxlIFNlcnZlciBzb3VyY2UgcmVwbGljYXRlcyBhc3luY2hyb25vdXNseSB3aXRoIGJpbmFyeS1sb2cgcG9zaXRpb24tYmFzZWQgcmVwbGljYXRpb24gdG8gdXAgdG8gdGVuIHJlYWQgcmVwbGljYXMsIHdoaWNoIGNhbiBiZSBpbiB0aGUgc2FtZSByZWdpb24gb3IgaW4gYW5vdGhlciByZWdpb24gZm9yIHJlYWQgc2NhbGUtb3V0LiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhemYzaCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6Izk0YTNiOCIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iNDAiIHk9IjY2IiB3aWR0aD0iMjEwIiBoZWlnaHQ9IjU2IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjE0NSIgeT0iOTIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXNpemU6MTJweCI+RmxleGlibGUgU2VydmVyIHNvdXJjZTwvdGV4dD4KPHRleHQgeD0iMTQ1IiB5PSIxMDkiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPndyaXRlcjwvdGV4dD4KPGxpbmUgeDE9IjI1MCIgeTE9Ijk0IiB4Mj0iNDgyIiB5Mj0iNzAiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2F6ZjNoKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxsaW5lIHgxPSIyNTAiIHkxPSI5NCIgeDI9IjQ4MiIgeTI9IjE1MCIgc3Ryb2tlLXdpZHRoPSIxLjYiIG1hcmtlci1lbmQ9InVybCgjYXpmM2gpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iMzYwIiB5PSI2NiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZTo5cHgiPmJpbmxvZyBhc3luYzwvdGV4dD4KPHJlY3QgeD0iNDg2IiB5PSI0NCIgd2lkdGg9IjMxMCIgaGVpZ2h0PSI1MCIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSI2NDEiIHk9IjY2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjExLjVweCI+UmVhZCByZXBsaWNhcyDCtyBzYW1lIHJlZ2lvbjwvdGV4dD4KPHRleHQgeD0iNjQxIiB5PSI4MyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPmluLXJlZ2lvbiByZWFkIHNjYWxlLW91dDwvdGV4dD4KPHJlY3QgeD0iNDg2IiB5PSIxMjAiIHdpZHRoPSIzMTAiIGhlaWdodD0iNTAiIHJ4PSIxMSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iNjQxIiB5PSIxNDIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTEuNXB4Ij5SZWFkIHJlcGxpY2FzIMK3IGFub3RoZXIgcmVnaW9uPC90ZXh0Pgo8dGV4dCB4PSI2NDEiIHk9IjE1OSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPmNyb3NzLXJlZ2lvbiByZWFkIHNjYWxlLW91dDwvdGV4dD4KPHJlY3QgeD0iNDAiIHk9IjEzMiIgd2lkdGg9IjM2MCIgaGVpZ2h0PSIzMCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojYTdmM2QwIi8+Cjx0ZXh0IHg9IjIyMCIgeT0iMTUxIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij5VcCB0byB0ZW4gcmVhZCByZXBsaWNhcyBwZXIgc291cmNlPC90ZXh0Pgo8L3N2Zz4=) ![A Flexible Server source replicates asynchronously with binary-log position-based replication to up to ten read replicas, which can be in the same region or in another region for read scale-out.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTg4IiB2aWV3Qm94PSIwIDAgODM2IDE4OCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJBIEZsZXhpYmxlIFNlcnZlciBzb3VyY2UgcmVwbGljYXRlcyBhc3luY2hyb25vdXNseSB3aXRoIGJpbmFyeS1sb2cgcG9zaXRpb24tYmFzZWQgcmVwbGljYXRpb24gdG8gdXAgdG8gdGVuIHJlYWQgcmVwbGljYXMsIHdoaWNoIGNhbiBiZSBpbiB0aGUgc2FtZSByZWdpb24gb3IgaW4gYW5vdGhlciByZWdpb24gZm9yIHJlYWQgc2NhbGUtb3V0LiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhemYzaCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6IzY0NzQ4YiIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iNDAiIHk9IjY2IiB3aWR0aD0iMjEwIiBoZWlnaHQ9IjU2IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjE0NSIgeT0iOTIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXNpemU6MTJweCI+RmxleGlibGUgU2VydmVyIHNvdXJjZTwvdGV4dD4KPHRleHQgeD0iMTQ1IiB5PSIxMDkiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPndyaXRlcjwvdGV4dD4KPGxpbmUgeDE9IjI1MCIgeTE9Ijk0IiB4Mj0iNDgyIiB5Mj0iNzAiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2F6ZjNoKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxsaW5lIHgxPSIyNTAiIHkxPSI5NCIgeDI9IjQ4MiIgeTI9IjE1MCIgc3Ryb2tlLXdpZHRoPSIxLjYiIG1hcmtlci1lbmQ9InVybCgjYXpmM2gpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iMzYwIiB5PSI2NiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZTo5cHgiPmJpbmxvZyBhc3luYzwvdGV4dD4KPHJlY3QgeD0iNDg2IiB5PSI0NCIgd2lkdGg9IjMxMCIgaGVpZ2h0PSI1MCIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSI2NDEiIHk9IjY2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjExLjVweCI+UmVhZCByZXBsaWNhcyDCtyBzYW1lIHJlZ2lvbjwvdGV4dD4KPHRleHQgeD0iNjQxIiB5PSI4MyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPmluLXJlZ2lvbiByZWFkIHNjYWxlLW91dDwvdGV4dD4KPHJlY3QgeD0iNDg2IiB5PSIxMjAiIHdpZHRoPSIzMTAiIGhlaWdodD0iNTAiIHJ4PSIxMSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iNjQxIiB5PSIxNDIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTEuNXB4Ij5SZWFkIHJlcGxpY2FzIMK3IGFub3RoZXIgcmVnaW9uPC90ZXh0Pgo8dGV4dCB4PSI2NDEiIHk9IjE1OSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPmNyb3NzLXJlZ2lvbiByZWFkIHNjYWxlLW91dDwvdGV4dD4KPHJlY3QgeD0iNDAiIHk9IjEzMiIgd2lkdGg9IjM2MCIgaGVpZ2h0PSIzMCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjIyMCIgeT0iMTUxIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij5VcCB0byB0ZW4gcmVhZCByZXBsaWNhcyBwZXIgc291cmNlPC90ZXh0Pgo8L3N2Zz4=) A source replicates asynchronously to up to ten read replicas, in its region or another. #### Server parameters Azure sets MySQL parameters such as `max_connections` as Flexible Server parameters. Azure configures each server separately, so the reusable parameter-group object has no counterpart. A declared `aws_db_parameter_group` is not kept: the deployment removes it and reports a warning, so the server starts with Azure's default values. Reapply the values you need as server parameters. Later parameter changes made through the RDS API, such as `ModifyDBParameterGroup`, are translated to server parameters where they map. Azure controls the allowed values; static parameters require a restart, and some settings can be chosen only when the server is created. ![An RDS parameter group is not kept. Each Flexible Server starts with Azure's default parameter values, and you set the parameters you need on each server.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjEwIiB2aWV3Qm94PSIwIDAgODM2IDIxMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJBbiBSRFMgcGFyYW1ldGVyIGdyb3VwIGlzIG5vdCBrZXB0LiBFYWNoIEZsZXhpYmxlIFNlcnZlciBzdGFydHMgd2l0aCBBenVyZSdzIGRlZmF1bHQgcGFyYW1ldGVyIHZhbHVlcywgYW5kIHlvdSBzZXQgdGhlIHBhcmFtZXRlcnMgeW91IG5lZWQgb24gZWFjaCBzZXJ2ZXIuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojMzM0MTU1fTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImF6ZjRoIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI2LjUiIG1hcmtlckhlaWdodD0iNi41IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+PHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBzdHlsZT0iZmlsbDojOTRhM2I4Ii8+PC9tYXJrZXI+PC9kZWZzPgo8cmVjdCB4PSI0NCIgeT0iNDAiIHdpZHRoPSIzMDAiIGhlaWdodD0iMTIyIiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS40IiBzdHlsZT0iZmlsbDojZjhmYWZjO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjE5NCIgeT0iNjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTJweCI+UkRTIHBhcmFtZXRlciBncm91cDwvdGV4dD4KPHRleHQgeD0iNjAiIHk9Ijg4IiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzMzNDE1NTsgZm9udC1zaXplOjEwcHgiPm1heF9jb25uZWN0aW9uczwvdGV4dD4KPHRleHQgeD0iNjAiIHk9IjExMCIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICMzMzQxNTU7IGZvbnQtc2l6ZToxMHB4Ij5pbm5vZGJfYnVmZmVyX3Bvb2xfc2l6ZTwvdGV4dD4KPHRleHQgeD0iNjAiIHk9IjEzMiIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICMzMzQxNTU7IGZvbnQtc2l6ZToxMHB4Ij5zbG93X3F1ZXJ5X2xvZzwvdGV4dD4KPGxpbmUgeDE9IjM0OCIgeTE9IjEwMCIgeDI9IjQ4NiIgeTI9IjEwMCIgc3Ryb2tlLXdpZHRoPSIxLjgiIG1hcmtlci1lbmQ9InVybCgjYXpmNGgpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iNDE3IiB5PSI5MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjYjQ1MzA5OyBmb250LXdlaWdodDo3MDAiPm5vdCBjYXJyaWVkPC90ZXh0Pgo8cmVjdCB4PSI0OTAiIHk9IjQwIiB3aWR0aD0iMzA2IiBoZWlnaHQ9IjEyMiIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNiIgc3R5bGU9ImZpbGw6I2ZmZmJlYjtzdHJva2U6I2ZkZTY4YSIvPgo8dGV4dCB4PSI2NDMiIHk9IjYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNiNDUzMDk7IGZvbnQtc2l6ZToxMnB4Ij5GbGV4aWJsZSBTZXJ2ZXIgcGFyYW1ldGVyczwvdGV4dD4KPHRleHQgeD0iNTA2IiB5PSI5MiIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICMzMzQxNTU7IGZvbnQtc2l6ZToxMHB4Ij5zdGFydCBhdCBBenVyZSBkZWZhdWx0czs8L3RleHQ+Cjx0ZXh0IHg9IjUwNiIgeT0iMTEyIiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzMzNDE1NTsgZm9udC1zaXplOjEwcHgiPnlvdSBzZXQgdGhlbSBwZXIgc2VydmVyOzwvdGV4dD4KPHRleHQgeD0iNTA2IiB5PSIxMzIiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjMzM0MTU1OyBmb250LXNpemU6MTBweCI+bm8gc2hhcmVkIGdyb3VwIG9iamVjdDwvdGV4dD4KPHJlY3QgeD0iNDQiIHk9IjE3NCIgd2lkdGg9Ijc1MiIgaGVpZ2h0PSIzMCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS40IiBzdHlsZT0iZmlsbDojZmZmYmViO3N0cm9rZTojZmRlNjhhIi8+Cjx0ZXh0IHg9IjQyMCIgeT0iMTkzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNiNDUzMDkiPkFsbG93ZWQgdmFsdWVzIGFuZCByZXN0YXJ0IHJlcXVpcmVtZW50cyBmb2xsb3cgQXp1cmU8L3RleHQ+Cjwvc3ZnPg==) ![An RDS parameter group is not kept. Each Flexible Server starts with Azure's default parameter values, and you set the parameters you need on each server.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjEwIiB2aWV3Qm94PSIwIDAgODM2IDIxMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJBbiBSRFMgcGFyYW1ldGVyIGdyb3VwIGlzIG5vdCBrZXB0LiBFYWNoIEZsZXhpYmxlIFNlcnZlciBzdGFydHMgd2l0aCBBenVyZSdzIGRlZmF1bHQgcGFyYW1ldGVyIHZhbHVlcywgYW5kIHlvdSBzZXQgdGhlIHBhcmFtZXRlcnMgeW91IG5lZWQgb24gZWFjaCBzZXJ2ZXIuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojY2JkNWUxfTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImF6ZjRoIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI2LjUiIG1hcmtlckhlaWdodD0iNi41IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+PHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBzdHlsZT0iZmlsbDojNjQ3NDhiIi8+PC9tYXJrZXI+PC9kZWZzPgo8cmVjdCB4PSI0NCIgeT0iNDAiIHdpZHRoPSIzMDAiIGhlaWdodD0iMTIyIiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS40IiBzdHlsZT0iZmlsbDojMGYxNzJhO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjE5NCIgeT0iNjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTJweCI+UkRTIHBhcmFtZXRlciBncm91cDwvdGV4dD4KPHRleHQgeD0iNjAiIHk9Ijg4IiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogI2NiZDVlMTsgZm9udC1zaXplOjEwcHgiPm1heF9jb25uZWN0aW9uczwvdGV4dD4KPHRleHQgeD0iNjAiIHk9IjExMCIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICNjYmQ1ZTE7IGZvbnQtc2l6ZToxMHB4Ij5pbm5vZGJfYnVmZmVyX3Bvb2xfc2l6ZTwvdGV4dD4KPHRleHQgeD0iNjAiIHk9IjEzMiIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICNjYmQ1ZTE7IGZvbnQtc2l6ZToxMHB4Ij5zbG93X3F1ZXJ5X2xvZzwvdGV4dD4KPGxpbmUgeDE9IjM0OCIgeTE9IjEwMCIgeDI9IjQ4NiIgeTI9IjEwMCIgc3Ryb2tlLXdpZHRoPSIxLjgiIG1hcmtlci1lbmQ9InVybCgjYXpmNGgpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iNDE3IiB5PSI5MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZmJiZjI0OyBmb250LXdlaWdodDo3MDAiPm5vdCBjYXJyaWVkPC90ZXh0Pgo8cmVjdCB4PSI0OTAiIHk9IjQwIiB3aWR0aD0iMzA2IiBoZWlnaHQ9IjEyMiIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNiIgc3R5bGU9ImZpbGw6IzQyMjAwNjtzdHJva2U6IzkyNDAwZSIvPgo8dGV4dCB4PSI2NDMiIHk9IjYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmYmJmMjQ7IGZvbnQtc2l6ZToxMnB4Ij5GbGV4aWJsZSBTZXJ2ZXIgcGFyYW1ldGVyczwvdGV4dD4KPHRleHQgeD0iNTA2IiB5PSI5MiIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICNjYmQ1ZTE7IGZvbnQtc2l6ZToxMHB4Ij5zdGFydCBhdCBBenVyZSBkZWZhdWx0czs8L3RleHQ+Cjx0ZXh0IHg9IjUwNiIgeT0iMTEyIiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogI2NiZDVlMTsgZm9udC1zaXplOjEwcHgiPnlvdSBzZXQgdGhlbSBwZXIgc2VydmVyOzwvdGV4dD4KPHRleHQgeD0iNTA2IiB5PSIxMzIiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjY2JkNWUxOyBmb250LXNpemU6MTBweCI+bm8gc2hhcmVkIGdyb3VwIG9iamVjdDwvdGV4dD4KPHJlY3QgeD0iNDQiIHk9IjE3NCIgd2lkdGg9Ijc1MiIgaGVpZ2h0PSIzMCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS40IiBzdHlsZT0iZmlsbDojNDIyMDA2O3N0cm9rZTojOTI0MDBlIi8+Cjx0ZXh0IHg9IjQyMCIgeT0iMTkzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmYmJmMjQiPkFsbG93ZWQgdmFsdWVzIGFuZCByZXN0YXJ0IHJlcXVpcmVtZW50cyBmb2xsb3cgQXp1cmU8L3RleHQ+Cjwvc3ZnPg==) The parameter group is removed with a warning; you set parameters on each 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 database authentication maps to Microsoft Entra ID authentication and a KMS customer key maps to a customer-managed key in Key Vault. RDS Proxy's managed connection pooling has no counterpart: the Flexible Server has no managed pooler, so ProxySQL is customer-managed on the customer's own VM.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjA4IiB2aWV3Qm94PSIwIDAgODM2IDIwOCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJSRFMgSUFNIGRhdGFiYXNlIGF1dGhlbnRpY2F0aW9uIG1hcHMgdG8gTWljcm9zb2Z0IEVudHJhIElEIGF1dGhlbnRpY2F0aW9uIGFuZCBhIEtNUyBjdXN0b21lciBrZXkgbWFwcyB0byBhIGN1c3RvbWVyLW1hbmFnZWQga2V5IGluIEtleSBWYXVsdC4gUkRTIFByb3h5J3MgbWFuYWdlZCBjb25uZWN0aW9uIHBvb2xpbmcgaGFzIG5vIGNvdW50ZXJwYXJ0OiB0aGUgRmxleGlibGUgU2VydmVyIGhhcyBubyBtYW5hZ2VkIHBvb2xlciwgc28gUHJveHlTUUwgaXMgY3VzdG9tZXItbWFuYWdlZCBvbiB0aGUgY3VzdG9tZXIncyBvd24gVk0uIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojMzM0MTU1fTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImF6ZjVoIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI2LjUiIG1hcmtlckhlaWdodD0iNi41IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+PHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBzdHlsZT0iZmlsbDojOTRhM2I4Ii8+PC9tYXJrZXI+PC9kZWZzPgo8cmVjdCB4PSI0NCIgeT0iNDAiIHdpZHRoPSIzMDAiIGhlaWdodD0iNDQiIHJ4PSIxMCIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iNjAiIHk9IjY3IiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzMzNDE1NTsgZm9udC1zaXplOjEwLjVweCI+UkRTIElBTSBkYXRhYmFzZSBhdXRoPC90ZXh0Pgo8bGluZSB4MT0iMzQ4IiB5MT0iNjIiIHgyPSI0NzAiIHkyPSI2MiIgc3Ryb2tlLXdpZHRoPSIxLjgiIG1hcmtlci1lbmQ9InVybCgjYXpmNWgpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHJlY3QgeD0iNDc0IiB5PSI0MCIgd2lkdGg9IjMxOCIgaGVpZ2h0PSI0NCIgcng9IjEwIiBzdHJva2Utd2lkdGg9IjEuNiIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI0OTAiIHk9IjY3IiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXdlaWdodDo3MDAiPk1pY3Jvc29mdCBFbnRyYSBJRCBhdXRoZW50aWNhdGlvbjwvdGV4dD4KPHJlY3QgeD0iNDQiIHk9Ijk2IiB3aWR0aD0iMzAwIiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjYwIiB5PSIxMjMiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjMzM0MTU1OyBmb250LXNpemU6MTAuNXB4Ij5LTVMgY3VzdG9tZXIga2V5PC90ZXh0Pgo8bGluZSB4MT0iMzQ4IiB5MT0iMTE4IiB4Mj0iNDcwIiB5Mj0iMTE4IiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLWVuZD0idXJsKCNhemY1aCkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8cmVjdCB4PSI0NzQiIHk9Ijk2IiB3aWR0aD0iMzE4IiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS42IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjQ5MCIgeT0iMTIzIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXdlaWdodDo3MDAiPmN1c3RvbWVyLW1hbmFnZWQga2V5IChLZXkgVmF1bHQpPC90ZXh0Pgo8cmVjdCB4PSI0NCIgeT0iMTUyIiB3aWR0aD0iNzQ4IiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS40IiBzdHlsZT0iZmlsbDojZmZmYmViO3N0cm9rZTojZmRlNjhhIi8+Cjx0ZXh0IHg9IjYwIiB5PSIxNzIiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjMzM0MTU1OyBmb250LXNpemU6MTAuNXB4Ij5SRFMgUHJveHkgKHBvb2xpbmcpPC90ZXh0Pgo8dGV4dCB4PSI0MTgiIHk9IjE4OCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjYjQ1MzA5Ij5ubyBtYW5hZ2VkIHBvb2xlciBvbiB0aGUgRmxleGlibGUgU2VydmVyOyBQcm94eVNRTCBpcyBjdXN0b21lci1tYW5hZ2VkIG9uIHRoZSBjdXN0b21lcidzIFZNPC90ZXh0Pgo8L3N2Zz4=) ![RDS IAM database authentication maps to Microsoft Entra ID authentication and a KMS customer key maps to a customer-managed key in Key Vault. RDS Proxy's managed connection pooling has no counterpart: the Flexible Server has no managed pooler, so ProxySQL is customer-managed on the customer's own VM.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjA4IiB2aWV3Qm94PSIwIDAgODM2IDIwOCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJSRFMgSUFNIGRhdGFiYXNlIGF1dGhlbnRpY2F0aW9uIG1hcHMgdG8gTWljcm9zb2Z0IEVudHJhIElEIGF1dGhlbnRpY2F0aW9uIGFuZCBhIEtNUyBjdXN0b21lciBrZXkgbWFwcyB0byBhIGN1c3RvbWVyLW1hbmFnZWQga2V5IGluIEtleSBWYXVsdC4gUkRTIFByb3h5J3MgbWFuYWdlZCBjb25uZWN0aW9uIHBvb2xpbmcgaGFzIG5vIGNvdW50ZXJwYXJ0OiB0aGUgRmxleGlibGUgU2VydmVyIGhhcyBubyBtYW5hZ2VkIHBvb2xlciwgc28gUHJveHlTUUwgaXMgY3VzdG9tZXItbWFuYWdlZCBvbiB0aGUgY3VzdG9tZXIncyBvd24gVk0uIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojY2JkNWUxfTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImF6ZjVoIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI2LjUiIG1hcmtlckhlaWdodD0iNi41IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+PHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBzdHlsZT0iZmlsbDojNjQ3NDhiIi8+PC9tYXJrZXI+PC9kZWZzPgo8cmVjdCB4PSI0NCIgeT0iNDAiIHdpZHRoPSIzMDAiIGhlaWdodD0iNDQiIHJ4PSIxMCIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iNjAiIHk9IjY3IiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogI2NiZDVlMTsgZm9udC1zaXplOjEwLjVweCI+UkRTIElBTSBkYXRhYmFzZSBhdXRoPC90ZXh0Pgo8bGluZSB4MT0iMzQ4IiB5MT0iNjIiIHgyPSI0NzAiIHkyPSI2MiIgc3Ryb2tlLXdpZHRoPSIxLjgiIG1hcmtlci1lbmQ9InVybCgjYXpmNWgpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHJlY3QgeD0iNDc0IiB5PSI0MCIgd2lkdGg9IjMxOCIgaGVpZ2h0PSI0NCIgcng9IjEwIiBzdHJva2Utd2lkdGg9IjEuNiIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSI0OTAiIHk9IjY3IiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXdlaWdodDo3MDAiPk1pY3Jvc29mdCBFbnRyYSBJRCBhdXRoZW50aWNhdGlvbjwvdGV4dD4KPHJlY3QgeD0iNDQiIHk9Ijk2IiB3aWR0aD0iMzAwIiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjYwIiB5PSIxMjMiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjY2JkNWUxOyBmb250LXNpemU6MTAuNXB4Ij5LTVMgY3VzdG9tZXIga2V5PC90ZXh0Pgo8bGluZSB4MT0iMzQ4IiB5MT0iMTE4IiB4Mj0iNDcwIiB5Mj0iMTE4IiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLWVuZD0idXJsKCNhemY1aCkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8cmVjdCB4PSI0NzQiIHk9Ijk2IiB3aWR0aD0iMzE4IiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS42IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjQ5MCIgeT0iMTIzIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXdlaWdodDo3MDAiPmN1c3RvbWVyLW1hbmFnZWQga2V5IChLZXkgVmF1bHQpPC90ZXh0Pgo8cmVjdCB4PSI0NCIgeT0iMTUyIiB3aWR0aD0iNzQ4IiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS40IiBzdHlsZT0iZmlsbDojNDIyMDA2O3N0cm9rZTojOTI0MDBlIi8+Cjx0ZXh0IHg9IjYwIiB5PSIxNzIiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjY2JkNWUxOyBmb250LXNpemU6MTAuNXB4Ij5SRFMgUHJveHkgKHBvb2xpbmcpPC90ZXh0Pgo8dGV4dCB4PSI0MTgiIHk9IjE4OCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZmJiZjI0Ij5ubyBtYW5hZ2VkIHBvb2xlciBvbiB0aGUgRmxleGlibGUgU2VydmVyOyBQcm94eVNRTCBpcyBjdXN0b21lci1tYW5hZ2VkIG9uIHRoZSBjdXN0b21lcidzIFZNPC90ZXh0Pgo8L3N2Zz4=) IAM authentication maps to Entra ID and customer keys to Key Vault; there is no managed pooler. #### Limitations Where RDS for MySQL and Azure Flexible Server differ * **The Burstable tier supports neither HA nor replicas.** Zone-redundant HA and read replicas need the General Purpose or Business Critical tier, so an instance that needs either is placed on one of those. * **No managed connection pooler is available.** Flexible Server has no RDS Proxy equivalent. Use an application pool or run your own pooler, such as ProxySQL on your own VM. * **Read replicas cap at ten and lag behind the source.** Replication is asynchronous. Send reads that need a just-completed write to the source, and size a large fan-out against ten replicas. * **Declared parameter groups are dropped at deployment.** The deployment removes the group with a warning, and each server starts with Azure's defaults. Reapply the values you need; parameters outside Azure's settable list cannot be set. * **MySQL versions and plugins behave differently: Azure chooses them.** Flexible Server runs the versions and server plugins in Azure's catalog. Move an instance that needs one Azure lacks to a supported one before cutover. * **RDS-only features are not supported.** Event subscriptions (SNS), S3 and Lambda integration SQL and Enhanced Monitoring have no counterpart; zero-ETL replicates to Microsoft Fabric, not to 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. #### Example monthly charges This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include. ##### RDS MySQL · Primary allocated compute Feature: RDS MySQL. Estimated monthly service charges by Primary allocated compute. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD. ![RDS MySQL · Primary allocated compute: monthly service charges by Primary allocated compute. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/fcc0d60cc4a590700854c0157d7774a2bed5769f9f2cd768f124725bed3ec941-light.svg) ![RDS MySQL · Primary allocated compute: monthly service charges by Primary allocated compute. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/8ccbac786bc6948feae9a1e8cbc1c0f16fef287d0acb9845d82f3c9c3a19c1e1-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Primary allocated compute (vCPU-hours/month) | RDS MySQL | Target scenario | MySQL Flexible Server | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | MySQL Flexible Server (one copy) | 136.33 | 136.33 | | 0 | 0.00 | MySQL Flexible Server (two copies) | 272.66 | 272.66 | | 1,460 | 124.83 | MySQL Flexible Server (one copy) | 136.33 | 11.50 | | 1,460 | 124.83 | MySQL Flexible Server (two copies) | 272.66 | 147.83 | | 2,920 | 249.66 | MySQL Flexible Server (one copy) | 261.16 | 11.50 | | 2,920 | 249.66 | MySQL Flexible Server (two copies) | 522.32 | 272.66 | | 5,840 | 499.32 | MySQL Flexible Server (one copy) | 510.82 | 11.50 | | 5,840 | 499.32 | MySQL Flexible Server (two copies) | 1,021.64 | 522.32 | | 11,680 | 998.64 | MySQL Flexible Server (one copy) | 1,010.14 | 11.50 | | 11,680 | 998.64 | MySQL Flexible Server (two copies) | 2,020.28 | 1,021.64 | | 23,360 | 1,997.28 | MySQL Flexible Server (one copy) | 2,008.78 | 11.50 | | 23,360 | 1,997.28 | MySQL Flexible Server (two copies) | 4,017.56 | 2,020.28 | | 46,720 | 3,994.56 | MySQL Flexible Server (one copy) | 4,006.06 | 11.50 | | 46,720 | 3,994.56 | MySQL Flexible Server (two copies) | 8,012.12 | 4,017.56 | Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 vCPU-hours/month to 64 vCPU, 256 GiB memory and 100 GiB SSD at 46,720 vCPU-hours/month. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | MySQL Flexible Server (one copy) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | MySQL Flexible Server (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | MySQL Flexible Server (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | MySQL Flexible Server (one copy) | Origin list price · Database reads | 0 | USD/operations | | MySQL Flexible Server (one copy) | Origin list price · Database writes | 0 | USD/operations | | MySQL Flexible Server (one copy) | Target CPU / source CPU | 1 | multiplier | | MySQL Flexible Server (one copy) | Target RAM / source RAM | 1 | multiplier | | MySQL Flexible Server (one copy) | Target disk / source disk | 1 | multiplier | | MySQL Flexible Server (one copy) | Target price guess · read | 0 | USD/read | | MySQL Flexible Server (one copy) | Target price guess · write | 0 | USD/write | | MySQL Flexible Server (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | MySQL Flexible Server (one copy) | Target list price · GiB-month | 0.115 | USD/GiB-month | | MySQL Flexible Server (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | MySQL Flexible Server (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | MySQL Flexible Server (one copy) | Target list price · network GiB | 0.087 | USD/network GiB | | MySQL Flexible Server (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | MySQL Flexible Server (one copy) | Target list price · vCPU-hour | 0.053 | USD/vCPU-hour | | MySQL Flexible Server (one copy) | Target list price · GiB-hour | 0.008125 | USD/GiB-hour | | MySQL Flexible Server (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | MySQL Flexible Server (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | MySQL Flexible Server (one copy) | Target price guess · input token | 0 | USD/input token | | MySQL Flexible Server (one copy) | Target price guess · output token | 0 | USD/output token | | MySQL Flexible Server (one copy) | Target monthly base charge | 0 | USD/month | | MySQL Flexible Server (one copy) | Target service minimum | 8.505 | USD/month | | MySQL Flexible Server (one copy) | Minimum primary CPU | 2 | vCPU | | MySQL Flexible Server (one copy) | Minimum primary RAM | 8 | GiB | | MySQL Flexible Server (one copy) | Minimum primary disk | 100 | GiB | | MySQL Flexible Server (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | MySQL Flexible Server (one copy) | Allocated share of provisioned cost | 1 | fraction | | MySQL Flexible Server (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | MySQL Flexible Server (one copy) | Planning peak / mean work | 2 | multiplier | | MySQL Flexible Server (one copy) | Planning primary CPU utilization | 0.7 | fraction | | MySQL Flexible Server (one copy) | Resident state reserved in RAM | 0.1 | fraction | | MySQL Flexible Server (one copy) | Planning disk utilization | 0.8 | fraction | | MySQL Flexible Server (one copy) | Maintenance and log disk reserve | 20 | GiB | | MySQL Flexible Server (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | MySQL Flexible Server (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | MySQL Flexible Server (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | MySQL Flexible Server (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | MySQL Flexible Server (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | MySQL Flexible Server (two copies) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | MySQL Flexible Server (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | MySQL Flexible Server (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | MySQL Flexible Server (two copies) | Origin list price · Database reads | 0 | USD/operations | | MySQL Flexible Server (two copies) | Origin list price · Database writes | 0 | USD/operations | | MySQL Flexible Server (two copies) | Target CPU / source CPU | 1 | multiplier | | MySQL Flexible Server (two copies) | Target RAM / source RAM | 1 | multiplier | | MySQL Flexible Server (two copies) | Target disk / source disk | 1 | multiplier | | MySQL Flexible Server (two copies) | Target price guess · read | 0 | USD/read | | MySQL Flexible Server (two copies) | Target price guess · write | 0 | USD/write | | MySQL Flexible Server (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | MySQL Flexible Server (two copies) | Target list price · GiB-month | 0.115 | USD/GiB-month | | MySQL Flexible Server (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | MySQL Flexible Server (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | MySQL Flexible Server (two copies) | Target list price · network GiB | 0.087 | USD/network GiB | | MySQL Flexible Server (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | MySQL Flexible Server (two copies) | Target list price · vCPU-hour | 0.053 | USD/vCPU-hour | | MySQL Flexible Server (two copies) | Target list price · GiB-hour | 0.008125 | USD/GiB-hour | | MySQL Flexible Server (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | MySQL Flexible Server (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | MySQL Flexible Server (two copies) | Target price guess · input token | 0 | USD/input token | | MySQL Flexible Server (two copies) | Target price guess · output token | 0 | USD/output token | | MySQL Flexible Server (two copies) | Target monthly base charge | 0 | USD/month | | MySQL Flexible Server (two copies) | Target service minimum | 8.505 | USD/month | | MySQL Flexible Server (two copies) | Minimum primary CPU | 2 | vCPU | | MySQL Flexible Server (two copies) | Minimum primary RAM | 8 | GiB | | MySQL Flexible Server (two copies) | Minimum primary disk | 100 | GiB | | MySQL Flexible Server (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | MySQL Flexible Server (two copies) | Allocated share of provisioned cost | 1 | fraction | | MySQL Flexible Server (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | MySQL Flexible Server (two copies) | Planning peak / mean work | 2 | multiplier | | MySQL Flexible Server (two copies) | Planning primary CPU utilization | 0.7 | fraction | | MySQL Flexible Server (two copies) | Resident state reserved in RAM | 0.1 | fraction | | MySQL Flexible Server (two copies) | Planning disk utilization | 0.8 | fraction | | MySQL Flexible Server (two copies) | Maintenance and log disk reserve | 20 | GiB | | MySQL Flexible Server (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | MySQL Flexible Server (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | MySQL Flexible Server (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | MySQL Flexible Server (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | MySQL Flexible Server (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * CPU allocation does not imply an achieved transaction rate. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements. * Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → eastus, USD/month. * Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded. * Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied. * Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Azure Database for MySQL Flexible Server bills vCores with a fixed memory ratio per series; the vCPU and memory rates decompose the General Purpose and Memory Optimized v5 prices. High availability bills the standby's compute and storage as a second copy. The minimum is the smallest Burstable server, which does not support high availability; the smallest General Purpose server (2 vCores) costs USD 127.13 per month. Additional IOPS, backup storage and reserved capacity are not selected. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: E96ads\_v5 has 96 vCores and 672 GiB; General Purpose storage holds 20 GiB to 16 TiB ([https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-service-tiers-storage](https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-service-tiers-storage)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonRDS offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json) * Azure Retail Prices API: [https://prices.azure.com/api/retail/prices](https://prices.azure.com/api/retail/prices) Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. List prices read: 2026-10-22. Model: `plan-a14b5a17bd919ad2be9588e5e7a7809815efbb8e` / `2026-10-22.planning.2`. Curve: `workload-1`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices). ##### RDS MySQL · Stored data Feature: RDS MySQL. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD. ![RDS MySQL · Stored data: monthly service charges by Stored data. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/7bd04e3824ca8990ccf5ccac7c8a9fa50d915356e4f3c6fb7c004cfc747bc961-light.svg) ![RDS MySQL · Stored data: monthly service charges by Stored data. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/6b98b359efbf7f93cb9a1e4fc448e51ca573509c1347fdb313910f6a7f2f5f3f-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Stored data (GiB-month) | RDS MySQL | Target scenario | MySQL Flexible Server | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | MySQL Flexible Server (one copy) | 136.33 | 136.33 | | 0 | 0.00 | MySQL Flexible Server (two copies) | 272.66 | 272.66 | | 10 | 1.15 | MySQL Flexible Server (one copy) | 136.33 | 135.18 | | 10 | 1.15 | MySQL Flexible Server (two copies) | 272.66 | 271.51 | | 100 | 11.50 | MySQL Flexible Server (one copy) | 142.08 | 130.58 | | 100 | 11.50 | MySQL Flexible Server (two copies) | 284.16 | 272.66 | | 1,000 | 115.00 | MySQL Flexible Server (one copy) | 271.46 | 156.46 | | 1,000 | 115.00 | MySQL Flexible Server (two copies) | 542.91 | 427.91 | | 10,000 | 1,150.00 | MySQL Flexible Server (one copy) | 1,565.21 | 415.21 | | 10,000 | 1,150.00 | MySQL Flexible Server (two copies) | 3,130.41 | 1,980.41 | | 100,000 | 11,500.00 | MySQL Flexible Server (one copy) | Unpriced | Unavailable | | 100,000 | 11,500.00 | MySQL Flexible Server (two copies) | Unpriced | Unavailable | Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 GiB-month to 2 vCPU, 8 GiB memory and 12,525 GiB SSD at 10,000 GiB-month. From 100,000 GiB-month the workload exceeds the planning range and the target is unpriced. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | MySQL Flexible Server (one copy) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | MySQL Flexible Server (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | MySQL Flexible Server (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | MySQL Flexible Server (one copy) | Origin list price · Database reads | 0 | USD/operations | | MySQL Flexible Server (one copy) | Origin list price · Database writes | 0 | USD/operations | | MySQL Flexible Server (one copy) | Target CPU / source CPU | 1 | multiplier | | MySQL Flexible Server (one copy) | Target RAM / source RAM | 1 | multiplier | | MySQL Flexible Server (one copy) | Target disk / source disk | 1 | multiplier | | MySQL Flexible Server (one copy) | Target price guess · read | 0 | USD/read | | MySQL Flexible Server (one copy) | Target price guess · write | 0 | USD/write | | MySQL Flexible Server (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | MySQL Flexible Server (one copy) | Target list price · GiB-month | 0.115 | USD/GiB-month | | MySQL Flexible Server (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | MySQL Flexible Server (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | MySQL Flexible Server (one copy) | Target list price · network GiB | 0.087 | USD/network GiB | | MySQL Flexible Server (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | MySQL Flexible Server (one copy) | Target list price · vCPU-hour | 0.053 | USD/vCPU-hour | | MySQL Flexible Server (one copy) | Target list price · GiB-hour | 0.008125 | USD/GiB-hour | | MySQL Flexible Server (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | MySQL Flexible Server (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | MySQL Flexible Server (one copy) | Target price guess · input token | 0 | USD/input token | | MySQL Flexible Server (one copy) | Target price guess · output token | 0 | USD/output token | | MySQL Flexible Server (one copy) | Target monthly base charge | 0 | USD/month | | MySQL Flexible Server (one copy) | Target service minimum | 8.505 | USD/month | | MySQL Flexible Server (one copy) | Minimum primary CPU | 2 | vCPU | | MySQL Flexible Server (one copy) | Minimum primary RAM | 8 | GiB | | MySQL Flexible Server (one copy) | Minimum primary disk | 100 | GiB | | MySQL Flexible Server (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | MySQL Flexible Server (one copy) | Allocated share of provisioned cost | 1 | fraction | | MySQL Flexible Server (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | MySQL Flexible Server (one copy) | Planning peak / mean work | 2 | multiplier | | MySQL Flexible Server (one copy) | Planning primary CPU utilization | 0.7 | fraction | | MySQL Flexible Server (one copy) | Resident state reserved in RAM | 0.1 | fraction | | MySQL Flexible Server (one copy) | Planning disk utilization | 0.8 | fraction | | MySQL Flexible Server (one copy) | Maintenance and log disk reserve | 20 | GiB | | MySQL Flexible Server (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | MySQL Flexible Server (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | MySQL Flexible Server (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | MySQL Flexible Server (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | MySQL Flexible Server (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | MySQL Flexible Server (two copies) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | MySQL Flexible Server (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | MySQL Flexible Server (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | MySQL Flexible Server (two copies) | Origin list price · Database reads | 0 | USD/operations | | MySQL Flexible Server (two copies) | Origin list price · Database writes | 0 | USD/operations | | MySQL Flexible Server (two copies) | Target CPU / source CPU | 1 | multiplier | | MySQL Flexible Server (two copies) | Target RAM / source RAM | 1 | multiplier | | MySQL Flexible Server (two copies) | Target disk / source disk | 1 | multiplier | | MySQL Flexible Server (two copies) | Target price guess · read | 0 | USD/read | | MySQL Flexible Server (two copies) | Target price guess · write | 0 | USD/write | | MySQL Flexible Server (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | MySQL Flexible Server (two copies) | Target list price · GiB-month | 0.115 | USD/GiB-month | | MySQL Flexible Server (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | MySQL Flexible Server (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | MySQL Flexible Server (two copies) | Target list price · network GiB | 0.087 | USD/network GiB | | MySQL Flexible Server (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | MySQL Flexible Server (two copies) | Target list price · vCPU-hour | 0.053 | USD/vCPU-hour | | MySQL Flexible Server (two copies) | Target list price · GiB-hour | 0.008125 | USD/GiB-hour | | MySQL Flexible Server (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | MySQL Flexible Server (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | MySQL Flexible Server (two copies) | Target price guess · input token | 0 | USD/input token | | MySQL Flexible Server (two copies) | Target price guess · output token | 0 | USD/output token | | MySQL Flexible Server (two copies) | Target monthly base charge | 0 | USD/month | | MySQL Flexible Server (two copies) | Target service minimum | 8.505 | USD/month | | MySQL Flexible Server (two copies) | Minimum primary CPU | 2 | vCPU | | MySQL Flexible Server (two copies) | Minimum primary RAM | 8 | GiB | | MySQL Flexible Server (two copies) | Minimum primary disk | 100 | GiB | | MySQL Flexible Server (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | MySQL Flexible Server (two copies) | Allocated share of provisioned cost | 1 | fraction | | MySQL Flexible Server (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | MySQL Flexible Server (two copies) | Planning peak / mean work | 2 | multiplier | | MySQL Flexible Server (two copies) | Planning primary CPU utilization | 0.7 | fraction | | MySQL Flexible Server (two copies) | Resident state reserved in RAM | 0.1 | fraction | | MySQL Flexible Server (two copies) | Planning disk utilization | 0.8 | fraction | | MySQL Flexible Server (two copies) | Maintenance and log disk reserve | 20 | GiB | | MySQL Flexible Server (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | MySQL Flexible Server (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | MySQL Flexible Server (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | MySQL Flexible Server (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | MySQL Flexible Server (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * Request meters remain at their independently authored defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements. * Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → eastus, USD/month. * Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded. * Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied. * Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Azure Database for MySQL Flexible Server bills vCores with a fixed memory ratio per series; the vCPU and memory rates decompose the General Purpose and Memory Optimized v5 prices. High availability bills the standby's compute and storage as a second copy. The minimum is the smallest Burstable server, which does not support high availability; the smallest General Purpose server (2 vCores) costs USD 127.13 per month. Additional IOPS, backup storage and reserved capacity are not selected. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: E96ads\_v5 has 96 vCores and 672 GiB; General Purpose storage holds 20 GiB to 16 TiB ([https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-service-tiers-storage](https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-service-tiers-storage)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonRDS offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json) * Azure Retail Prices API: [https://prices.azure.com/api/retail/prices](https://prices.azure.com/api/retail/prices) Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. List prices read: 2026-10-22. Model: `plan-a14b5a17bd919ad2be9588e5e7a7809815efbb8e` / `2026-10-22.planning.2`. Curve: `workload-2`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices). ##### RDS MySQL · Database writes Feature: RDS MySQL. Estimated monthly service charges by Database writes. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD. ![RDS MySQL · Database writes: monthly service charges by Database writes. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/a19842e48be7561e6f8015cb65d8c0188916a124df3eaa968e4700ddbe4eab41-light.svg) ![RDS MySQL · Database writes: monthly service charges by Database writes. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/06093783f6f53836288cae89cd55e89c523d5677c2fd425a2c17b77448ad7100-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Database writes (per second) | RDS MySQL | Target scenario | MySQL Flexible Server | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | MySQL Flexible Server (one copy) | 136.33 | 136.33 | | 0 | 0.00 | MySQL Flexible Server (two copies) | 272.66 | 272.66 | | 1 | 0.00 | MySQL Flexible Server (one copy) | 136.33 | 136.33 | | 1 | 0.00 | MySQL Flexible Server (two copies) | 272.66 | 272.66 | | 10 | 0.00 | MySQL Flexible Server (one copy) | 136.33 | 136.33 | | 10 | 0.00 | MySQL Flexible Server (two copies) | 272.66 | 272.66 | | 100 | 0.00 | MySQL Flexible Server (one copy) | 136.33 | 136.33 | | 100 | 0.00 | MySQL Flexible Server (two copies) | 272.66 | 272.66 | | 1,000 | 0.00 | MySQL Flexible Server (one copy) | 136.33 | 136.33 | | 1,000 | 0.00 | MySQL Flexible Server (two copies) | 272.66 | 272.66 | | 10,000 | 0.00 | MySQL Flexible Server (one copy) | 136.33 | 136.33 | | 10,000 | 0.00 | MySQL Flexible Server (two copies) | 272.66 | 272.66 | Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | MySQL Flexible Server (one copy) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | MySQL Flexible Server (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | MySQL Flexible Server (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | MySQL Flexible Server (one copy) | Origin list price · Database reads | 0 | USD/operations | | MySQL Flexible Server (one copy) | Origin list price · Database writes | 0 | USD/operations | | MySQL Flexible Server (one copy) | Target CPU / source CPU | 1 | multiplier | | MySQL Flexible Server (one copy) | Target RAM / source RAM | 1 | multiplier | | MySQL Flexible Server (one copy) | Target disk / source disk | 1 | multiplier | | MySQL Flexible Server (one copy) | Target price guess · read | 0 | USD/read | | MySQL Flexible Server (one copy) | Target price guess · write | 0 | USD/write | | MySQL Flexible Server (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | MySQL Flexible Server (one copy) | Target list price · GiB-month | 0.115 | USD/GiB-month | | MySQL Flexible Server (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | MySQL Flexible Server (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | MySQL Flexible Server (one copy) | Target list price · network GiB | 0.087 | USD/network GiB | | MySQL Flexible Server (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | MySQL Flexible Server (one copy) | Target list price · vCPU-hour | 0.053 | USD/vCPU-hour | | MySQL Flexible Server (one copy) | Target list price · GiB-hour | 0.008125 | USD/GiB-hour | | MySQL Flexible Server (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | MySQL Flexible Server (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | MySQL Flexible Server (one copy) | Target price guess · input token | 0 | USD/input token | | MySQL Flexible Server (one copy) | Target price guess · output token | 0 | USD/output token | | MySQL Flexible Server (one copy) | Target monthly base charge | 0 | USD/month | | MySQL Flexible Server (one copy) | Target service minimum | 8.505 | USD/month | | MySQL Flexible Server (one copy) | Minimum primary CPU | 2 | vCPU | | MySQL Flexible Server (one copy) | Minimum primary RAM | 8 | GiB | | MySQL Flexible Server (one copy) | Minimum primary disk | 100 | GiB | | MySQL Flexible Server (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | MySQL Flexible Server (one copy) | Allocated share of provisioned cost | 1 | fraction | | MySQL Flexible Server (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | MySQL Flexible Server (one copy) | Planning peak / mean work | 2 | multiplier | | MySQL Flexible Server (one copy) | Planning primary CPU utilization | 0.7 | fraction | | MySQL Flexible Server (one copy) | Resident state reserved in RAM | 0.1 | fraction | | MySQL Flexible Server (one copy) | Planning disk utilization | 0.8 | fraction | | MySQL Flexible Server (one copy) | Maintenance and log disk reserve | 20 | GiB | | MySQL Flexible Server (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | MySQL Flexible Server (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | MySQL Flexible Server (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | MySQL Flexible Server (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | MySQL Flexible Server (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | MySQL Flexible Server (two copies) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | MySQL Flexible Server (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | MySQL Flexible Server (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | MySQL Flexible Server (two copies) | Origin list price · Database reads | 0 | USD/operations | | MySQL Flexible Server (two copies) | Origin list price · Database writes | 0 | USD/operations | | MySQL Flexible Server (two copies) | Target CPU / source CPU | 1 | multiplier | | MySQL Flexible Server (two copies) | Target RAM / source RAM | 1 | multiplier | | MySQL Flexible Server (two copies) | Target disk / source disk | 1 | multiplier | | MySQL Flexible Server (two copies) | Target price guess · read | 0 | USD/read | | MySQL Flexible Server (two copies) | Target price guess · write | 0 | USD/write | | MySQL Flexible Server (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | MySQL Flexible Server (two copies) | Target list price · GiB-month | 0.115 | USD/GiB-month | | MySQL Flexible Server (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | MySQL Flexible Server (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | MySQL Flexible Server (two copies) | Target list price · network GiB | 0.087 | USD/network GiB | | MySQL Flexible Server (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | MySQL Flexible Server (two copies) | Target list price · vCPU-hour | 0.053 | USD/vCPU-hour | | MySQL Flexible Server (two copies) | Target list price · GiB-hour | 0.008125 | USD/GiB-hour | | MySQL Flexible Server (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | MySQL Flexible Server (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | MySQL Flexible Server (two copies) | Target price guess · input token | 0 | USD/input token | | MySQL Flexible Server (two copies) | Target price guess · output token | 0 | USD/output token | | MySQL Flexible Server (two copies) | Target monthly base charge | 0 | USD/month | | MySQL Flexible Server (two copies) | Target service minimum | 8.505 | USD/month | | MySQL Flexible Server (two copies) | Minimum primary CPU | 2 | vCPU | | MySQL Flexible Server (two copies) | Minimum primary RAM | 8 | GiB | | MySQL Flexible Server (two copies) | Minimum primary disk | 100 | GiB | | MySQL Flexible Server (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | MySQL Flexible Server (two copies) | Allocated share of provisioned cost | 1 | fraction | | MySQL Flexible Server (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | MySQL Flexible Server (two copies) | Planning peak / mean work | 2 | multiplier | | MySQL Flexible Server (two copies) | Planning primary CPU utilization | 0.7 | fraction | | MySQL Flexible Server (two copies) | Resident state reserved in RAM | 0.1 | fraction | | MySQL Flexible Server (two copies) | Planning disk utilization | 0.8 | fraction | | MySQL Flexible Server (two copies) | Maintenance and log disk reserve | 20 | GiB | | MySQL Flexible Server (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | MySQL Flexible Server (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | MySQL Flexible Server (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | MySQL Flexible Server (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | MySQL Flexible Server (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * Source compute and stored data remain independent; a throughput view needs explicit workload inputs. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements. * Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → eastus, USD/month. * Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded. * Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied. * Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Azure Database for MySQL Flexible Server bills vCores with a fixed memory ratio per series; the vCPU and memory rates decompose the General Purpose and Memory Optimized v5 prices. High availability bills the standby's compute and storage as a second copy. The minimum is the smallest Burstable server, which does not support high availability; the smallest General Purpose server (2 vCores) costs USD 127.13 per month. Additional IOPS, backup storage and reserved capacity are not selected. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: E96ads\_v5 has 96 vCores and 672 GiB; General Purpose storage holds 20 GiB to 16 TiB ([https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-service-tiers-storage](https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-service-tiers-storage)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonRDS offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json) * Azure Retail Prices API: [https://prices.azure.com/api/retail/prices](https://prices.azure.com/api/retail/prices) Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. List prices read: 2026-10-22. Model: `plan-a14b5a17bd919ad2be9588e5e7a7809815efbb8e` / `2026-10-22.planning.2`. Curve: `workload-3`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices). **RDS MySQL → MySQL Flexible Server: Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: eastus. Currency: USD. | Monthly component | USD | | - | -: | | Origin: Primary compute | 0.00 | | Origin: Primary memory | 0.00 | | Origin: Primary provisioned storage | 0.00 | | Origin: Database reads | 0.00 | | Origin: Database writes | 0.00 | | Target: Provisioned primary CPU | 77.38 | | Target: Provisioned primary RAM | 47.45 | | Target: Provisioned primary disk | 11.50 | | Target: Selected billable network | 0.00 | | Target: Independent provisioned resources | 0.00 | | Target: Independent managed resources | 0.00 | | **Origin service subtotal** | **0.00** | | **Target service subtotal** | **136.33** | Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. **Scenario assumptions** | Input | Value | Unit | | - | -: | - | | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Origin list price · Primary memory | 0 | USD/GiB-hours | | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Origin list price · Database reads | 0 | USD/operations | | Origin list price · Database writes | 0 | USD/operations | | Target CPU / source CPU | 1 | multiplier | | Target RAM / source RAM | 1 | multiplier | | Target disk / source disk | 1 | multiplier | | Target price guess · read | 0 | USD/read | | Target price guess · write | 0 | USD/write | | Target price guess · provider operation | 0 | USD/provider operation | | Target list price · GiB-month | 0.115 | USD/GiB-month | | Target price guess · published GiB | 0 | USD/published GiB | | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Target list price · network GiB | 0.087 | USD/network GiB | | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Target list price · vCPU-hour | 0.053 | USD/vCPU-hour | | Target list price · GiB-hour | 0.008125 | USD/GiB-hour | | Target price guess · resource-hour | 0 | USD/resource-hour | | Target price guess · resource-month | 0 | USD/resource-month | | Target price guess · input token | 0 | USD/input token | | Target price guess · output token | 0 | USD/output token | | Target monthly base charge | 0 | USD/month | | Target service minimum | 8.505 | USD/month | | Minimum primary CPU | 2 | vCPU | | Minimum primary RAM | 8 | GiB | | Minimum primary disk | 100 | GiB | | Additional full-price standby copy | 0 | 0 or 1 | | Allocated share of provisioned cost | 1 | fraction | | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Planning peak / mean work | 2 | multiplier | | Planning primary CPU utilization | 0.7 | fraction | | Resident state reserved in RAM | 0.1 | fraction | | Planning disk utilization | 0.8 | fraction | | Maintenance and log disk reserve | 20 | GiB | | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Dependent object sink write price guess | 0.000005 | USD/write | | Primary compute | 0 | vCPU-hours | | Primary memory | 0 | GiB-hours | | Primary provisioned storage | 0 | GiB-month | | Database reads | 0 | operations | | Database writes | 0 | operations | * Translated reads: 0 operations. * Translated writes: 0 operations. * Translated resident physical data: 0 GiB-month. * Native provider operations: 0 operations. * Published payload: 0 GiB. * Delivered payload: 0 GiB. * Allocated execution CPU: 0 vCPU-hour. * Allocated execution RAM: 0 GiB-hour. * Independent resource allocation: 0 resource-hour. * Independent inventory: 0 resource-month. * Input tokens: 0 tokens. * Output tokens: 0 tokens. * Billable network: 0 GiB. * Dependent object sink retained data: 0 GiB-month. * Dependent object sink writes: 0 writes. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Azure Database for MySQL Flexible Server bills vCores with a fixed memory ratio per series; the vCPU and memory rates decompose the General Purpose and Memory Optimized v5 prices. High availability bills the standby's compute and storage as a second copy. The minimum is the smallest Burstable server, which does not support high availability; the smallest General Purpose server (2 vCores) costs USD 127.13 per month. Additional IOPS, backup storage and reserved capacity are not selected. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: E96ads\_v5 has 96 vCores and 672 GiB; General Purpose storage holds 20 GiB to 16 TiB ([https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-service-tiers-storage](https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-service-tiers-storage)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. List prices read: 2026-10-22. Model: `plan-a14b5a17bd919ad2be9588e5e7a7809815efbb8e` / `2026-10-22.planning.2`. Scenario: `planning-example`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices). ## On DigitalOcean ### DigitalOcean Managed MySQL | Operation | Area | Support | Depth | Notes | | - | - | - | - | - | | AWS integration SQL and RDS-specific procedures | SQL functions | Out of scope | Full surface | AWS-specific S3, Lambda, and RDS helper functions have no native DigitalOcean counterpart | | MySQL client protocol (application SQL) | Wire protocol | Supported | Common | connects directly to Managed MySQL; check the selected engine version and supported extensions or plugins | #### How it works Your application connects to DigitalOcean Managed MySQL with its usual MySQL driver, and its queries go directly to the database. Tensor9 creates the DigitalOcean database from your AWS database declaration and supplies its connection settings. RDS management calls go through the adapter in the customer's Cloud Adapter deployment. The adapter keeps the AWS database identity, translates supported operations to DigitalOcean's API, and reports the backend's status and endpoints. ![Database requests (MySQL protocol) connect directly to Managed MySQL. The Tensor9 service adapter translates RDS API management calls to DigitalOcean database API.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoTXlTUUwgcHJvdG9jb2wpIGNvbm5lY3QgZGlyZWN0bHkgdG8gTWFuYWdlZCBNeVNRTC4gVGhlIFRlbnNvcjkgc2VydmljZSBhZGFwdGVyIHRyYW5zbGF0ZXMgUkRTIEFQSSBtYW5hZ2VtZW50IGNhbGxzIHRvIERpZ2l0YWxPY2VhbiBkYXRhYmFzZSBBUEkuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojMzM0MTU1fTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImFoZC1tYW5hZ2VkLW15c3FsIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM5NGEzYjgiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjgiIHk9IjM0IiB3aWR0aD0iODIwIiBoZWlnaHQ9IjIwNiIgcng9IjE2IiBzdHJva2Utd2lkdGg9IjEuNCIgc3Ryb2tlLWRhc2hhcnJheT0iNSA1IiBzdHlsZT0iZmlsbDojZjhmYWZjO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjI2IiB5PSI1NCIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjg7IGZpbGw6IzA0Nzg1NyI+T04gRElHSVRBTE9DRUFOPC90ZXh0PjxzdmcgeD0iNzkyIiB5PSIzNiIgd2lkdGg9IjE2IiBoZWlnaHQ9IjE2IiB2aWV3Qm94PSIwIDAgMzIgMzIiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiIGZpbGw9Im5vbmUiPjxwYXRoIGQ9Ik0xNi4wMjE5IDI1LjgwMzZWMzJDMjYuNDg3NCAzMiAzNC42MzE2IDIxLjg4ODEgMzEuMjA2NSAxMC45MDJDMjkuNjg0MiA2LjExMjE0IDI1Ljg3ODUgMi4yNzI2OCAyMS4wODM0IDAuNzkwMTEyQzEwLjEyMzEgLTIuNjMxMTkgMCA1LjU0MTkyIDAgMTUuOTk1OUg2LjIwMzI0QzYuMjAzMjQgOS40NTc0MSAxMi43MTA5IDQuMzYzNDcgMTkuNjM3MiA2Ljg3MjQzQzIyLjE4NyA3Ljc4NDc4IDI0LjI0MjEgOS44Mzc1NiAyNS4xNTU1IDEyLjM4NDVDMjcuNjY3MiAxOS4zMDMyIDIyLjYwNTcgMjUuODAzNiAxNi4wMjE5IDI1LjgwMzZaIiBzdHlsZT0iZmlsbDojNDc1NTY5Ii8+IDxwYXRoIGQ9Ik05Ljg1NTQ3IDI1Ljg0MTdIMTYuMDIwNlYxOS42ODM0SDkuODU1NDdWMjUuODQxN1oiIHN0eWxlPSJmaWxsOiM0NzU1NjkiLz4gPHBhdGggZD0iTTkuODU0NzQgMzAuNTkzNEg1LjA5NzY2VjI1Ljg0MTdMOS44NTU0NyAyNS44NDE3TDkuODU0NzQgMzAuNTkzNFoiIHN0eWxlPSJmaWxsOiM0NzU1NjkiLz4gPHBhdGggZD0iTTEuMTA5MzggMjUuODQxN0g1LjA2NzI3VjIxLjg4ODJIMS4xMDkzOFYyNS44NDE3WiIgc3R5bGU9ImZpbGw6IzQ3NTU2OSIvPjwvc3ZnPgo8cmVjdCB4PSIyNiIgeT0iODgiIHdpZHRoPSIxMjgiIGhlaWdodD0iMTEyIiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjkwIiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTNweCI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIxNDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5NeVNRTCBkcml2ZXI8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIxNjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2MDAgMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+dW5jaGFuZ2VkPC90ZXh0Pgo8dGV4dCB4PSIyMDAiIHk9IjgyIiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzk0YTNiODsgZmlsbDojMDQ3ODU3Ij5EQVRBQkFTRSBSRVFVRVNUUyDCtyBESVJFQ1QgQ09OTkVDVElPTjwvdGV4dD4KPGxpbmUgeDE9IjE1NCIgeTE9IjEwOCIgeDI9IjYxMCIgeTI9IjEwOCIgc3Ryb2tlLXdpZHRoPSIyLjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLW1hbmFnZWQtbXlzcWwpIiBzdHlsZT0ic3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iMzgyIiB5PSIxMDAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiMwNDc4NTciPk15U1FMIHByb3RvY29sPC90ZXh0Pgo8cmVjdCB4PSI2MTQiIHk9Ijc2IiB3aWR0aD0iMTk2IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+PHN2ZyB4PSI3ODYiIHk9IjU2IiB3aWR0aD0iMjAiIGhlaWdodD0iMjAiIHZpZXdCb3g9IjAgMCAyNCAyNCIgcHJlc2VydmVBc3BlY3RSYXRpbz0ieE1pZFlNaWQgbWVldCI+PHRpdGxlPk15U1FMPC90aXRsZT48cGF0aCBkPSJNMTYuNDA1IDUuNTAxYy0uMTE1IDAtLjE5My4wMTQtLjI3NC4wMzN2LjAxM2guMDE0Yy4wNTQuMTA0LjE0Ni4xOC4yMTQuMjczLjA1NC4xMDcuMS4yMTQuMTU0LjMybC4wMTQtLjAxNWMuMDk0LS4wNjYuMTQtLjE3Mi4xNC0uMzMzLS4wNC0uMDQ3LS4wNDYtLjA5NC0uMDgtLjE0LS4wNC0uMDY3LS4xMjYtLjEtLjE4LS4xNTN6TTUuNzcgMTguNjk1aC0uOTI3YTUwLjg1NCA1MC44NTQgMCAwMC0uMjctNC40MWgtLjAwOGwtMS40MSA0LjQxSDIuNDVsLTEuNC00LjQxaC0uMDFhNzIuODkyIDcyLjg5MiAwIDAwLS4xOTUgNC40MUgwYy4wNTUtMS45NjYuMTkyLTMuODEuNDEtNS41M2gxLjE1bDEuMzM1IDQuMDY0aC4wMDhsMS4zNDctNC4wNjRoMS4wOTVjLjI0MiAyLjAxNS4zODQgMy44Ni40MjggNS41M3ptNC4wMTctNC4wOGMtLjM3OCAyLjA0NS0uODc2IDMuNTMzLTEuNDkyIDQuNDYtLjQ4Mi43MTYtMS4wMSAxLjA3My0xLjU4MyAxLjA3My0uMTUzIDAtLjM0LS4wNDYtLjU2Ni0uMTM4di0uNDk0Yy4xMS4wMTcuMjQuMDI2LjM4Ni4wMjYuMjY4IDAgLjQ4My0uMDc1LjY0Ny0uMjIyLjE5Ny0uMTguMjk1LS4zODIuMjk1LS42MDUgMC0uMTU1LS4wNzctLjQ3LS4yMy0uOTQ0TDYuMjMgMTQuNjE1aC45MWwuNzI3IDIuMzZjLjE2NC41MzYuMjMzLjkxLjIwNSAxLjEyMy40LTEuMDY0LjY3OC0yLjIyNy44MzUtMy40ODN6bTEyLjMyNSA0LjA4aC0yLjYzdi01LjUzaC44ODV2NC44NWgxLjc0NXptLTMuMzIuMTM1bC0xLjAxNi0uNWMuMDktLjA3Ni4xNzctLjE1OC4yNTUtLjI1LjQzMy0uNTA2LjY0OC0xLjI1OC42NDgtMi4yNTMgMC0xLjgzLS43MTgtMi43NDYtMi4xNTUtMi43NDYtLjcwNCAwLTEuMjU0LjIzMi0xLjY1LjY5Ny0uNDMuNTA4LS42NDYgMS4yNTYtLjY0NiAyLjI0NSAwIC45NzIuMTkgMS42ODYuNTc0IDIuMTQuMzUuNDEuODc3LjYxNSAxLjU4My42MTUuMjY0IDAgLjUwNi0uMDMzLjcyNS0uMDk4bDEuMzI1Ljc3Mi4zNi0uNjIyek0xNS41IDE3LjU4OGMtLjIyNS0uMzYtLjMzNy0uOTQtLjMzNy0xLjczNiAwLTEuMzkzLjQyNC0yLjA5IDEuMjctMi4wOS40NDMgMCAuNzcuMTY3Ljk3Ny41LjIyNC4zNjIuMzM2LjkzNi4zMzYgMS43MjMgMCAxLjQwNC0uNDI0IDIuMTA4LTEuMjcgMi4xMDgtLjQ0NSAwLS43Ny0uMTY3LS45NzgtLjV6bS0xLjY1OC0uNDI1YzAgLjQ3LS4xNzIuODU2LS41MTYgMS4xNTYtLjM0NC4zLS44MDMuNDUtMS4zODQuNDUtLjU0MyAwLTEuMDY0LS4xNzItMS41NzMtLjUxNWwuMjM3LS40NzZjLjQzOC4yMi44MzMuMzI4IDEuMTkuMzI4LjMzMiAwIC41OTMtLjA3My43ODMtLjIyYS43NTQuNzU0IDAgMDAuMy0uNjE1YzAtLjMzLS4yMy0uNjEtLjY0OC0uODQ1LS4zODgtLjIxMy0xLjE2My0uNjU3LTEuMTYzLS42NTctLjQyMi0uMzA3LS42MzItLjYzNi0uNjMyLTEuMTc3IDAtLjQ1LjE1Ny0uODEuNDctMS4wODUuMzE1LS4yNzguNzItLjQxNSAxLjIyLS40MTUuNTEyIDAgLjk4LjEzNiAxLjQuNDFsLS4yMTMuNDc2YTIuNzI2IDIuNzI2IDAgMDAtMS4wNjQtLjIzYy0uMjgzIDAtLjUwMi4wNjgtLjY1NC4yMDZhLjY4NS42ODUgMCAwMC0uMjQ4LjUyNGMwIC4zMjguMjM0LjYxLjY2Ni44NS4zOTMuMjE1IDEuMTg3LjY3IDEuMTg3LjY3LjQzMy4zMDUuNjQ4LjYzLjY0OCAxLjE2OHptOS4zODItNS44NTJjLS41MzUtLjAxNC0uOTUuMDQtMS4yOTcuMTg4LS4xLjA0LS4yNi4wNC0uMjc0LjE2Ny4wNTUuMDUzLjA2My4xNC4xMS4yMTQuMDguMTM0LjIxOC4zMTMuMzQ2LjQwNy4xNC4xMS4yOC4yMTYuNDI3LjMxLjI2LjE2LjU1NS4yNTUuODEuNDE2LjE0NS4wOTQuMjkzLjIxMy40NC4zMTMuMDczLjA1LjEyLjE0LjIxNC4xNzJ2LS4wMmMtLjA0Ni0uMDYtLjA2LS4xNDctLjEwNS0uMjE0LS4wNjctLjA2Ny0uMTM0LS4xMjctLjItLjE5M2EzLjIyMyAzLjIyMyAwIDAwLS42OTUtLjY3NWMtLjIxNC0uMTQ2LS42ODItLjM1LS43Ny0uNTk1bC0uMDEzLS4wMTRjLjE0Ni0uMDEzLjMyLS4wNjYuNDYtLjEwNi4yMjctLjA2LjQzNS0uMDQ3LjY3LS4xMDYuMTA2LS4wMjcuMjEzLS4wNi4zMi0uMDk0di0uMDZjLS4xMi0uMTItLjIxLS4yODMtLjMzNC0uMzk1YTguODY3IDguODY3IDAgMDAtMS4xMDQtLjgyM2MtLjIxLS4xMzQtLjQ3Ni0uMjItLjY5Ny0uMzM0LS4wOC0uMDQtLjIxNC0uMDYtLjI2LS4xMjctLjEyLS4xNDYtLjE5LS4zNC0uMjc1LS41MTRhMTcuNjkgMTcuNjkgMCAwMS0uNTQ3LTEuMTYzYy0uMTItLjI2Mi0uMTkzLS41MjMtLjM0LS43NjMtLjY5LTEuMTM3LTEuNDM3LTEuODI2LTIuNTg2LTIuNS0uMjQ3LS4xNC0uNTQzLS4yLS44NTYtLjI3NC0uMTY3LS4wMDgtLjMzNC0uMDItLjUtLjAyNy0uMTEtLjA0Ny0uMjE2LS4xNzQtLjMxLS4yMzUtLjM4LS4yNC0xLjM2NC0uNzYtMS42NDQtLjA3Mi0uMTguNDM0LjI2Ny44NjIuNDIyIDEuMDgyLjExNS4xNTMuMjYuMzI4LjM0LjUuMDQ3LjExNi4wNi4yMzUuMTA3LjM1Ni4xMDYuMjk0LjIwNy42MjIuMzQ3Ljg5Ny4wNzMuMTQuMTUzLjI4Ny4yNDcuNDEzLjA1NC4wNzMuMTQ2LjEwNy4xNjcuMjI3LS4wOTQuMTM2LS4xLjMzNC0uMTU0LjUtLjI0Ljc1Ny0uMTQ2IDEuNjkzLjE5NCAyLjI1LjEwNy4xNjYuMzYyLjUzNC43MDMuMzkzLjMtLjEyLjIzNC0uNS4zMi0uODM1LjAyLS4wOC4wMDctLjEzMy4wNDgtLjE4N3YuMDE1Yy4wOTQuMTg4LjE4OC4zNjcuMjc0LjU1NS4yMDYuMzI4LjU2Ni42NjguODY3Ljg5NS4xNi4xMi4yODcuMzI4LjQ4Ny40MDJ2LS4wMmgtLjAxNWMtLjA0My0uMDU4LS4xLS4wODYtLjE1NC0uMTMzYTMuNDQ1IDMuNDQ1IDAgMDEtLjM1LS40IDguNzYgOC43NiAwIDAxLS43NDctMS4yMThjLS4xMS0uMjEtLjIwMi0uNDM2LS4yOS0uNjQzLS4wNC0uMDgtLjA0LS4yLS4xMDctLjI0LS4xLjE0Ni0uMjQ3LjI3My0uMzIuNDUzLS4xMjcuMjg4LS4xNC42NDItLjE4OCAxLjAxLS4wMjcuMDA3LS4wMTQgMC0uMDI3LjAxNC0uMjE0LS4wNTItLjI4Ny0uMjc0LS4zNjctLjQ2LS4yLS40NzUtLjIzMy0xLjIzOC0uMDYtMS43ODUuMDQ3LS4xNC4yNDctLjU4Mi4xNjctLjcxNi0uMDQyLS4xMjctLjE3NC0uMi0uMjQ3LS4zMDNhMi40NzggMi40NzggMCAwMS0uMjQtLjQyN2MtLjE2LS4zNzQtLjI0LS43ODgtLjQxNC0xLjE2Mi0uMDgtLjE3My0uMjItLjM1NC0uMzM0LS41MTMtLjEyNy0uMTgtLjI2Ny0uMzA3LS4zNjgtLjUyLS4wMzMtLjA3My0uMDgtLjE5NC0uMDI3LS4yNzQuMDE0LS4wNTQuMDQyLS4wNzUuMDk0LS4wOS4wODgtLjA3Mi4zMzUuMDIyLjQyMi4wNjIuMjQ3LjEuNDU1LjE5NC42NjIuMzM0LjA5NC4wNjYuMTk1LjE5My4zMTUuMjI2aC4xNGMuMjE0LjA0Ny40NTUuMDE0LjY1NS4wNzMuMzU1LjExNC42NzUuMjguOTYyLjQ2YTUuOTUzIDUuOTUzIDAgMDEyLjA4NSAyLjI4NmMuMDguMTU0LjExNS4yOTUuMTg4LjQ1NS4xNC4zMy4zMTMuNjYzLjQ1NS45ODIuMTQuMzE1LjI3NS42MzYuNDc2Ljg5Ny4xLjE0LjUwMi4yMTMuNjgyLjI4Ni4xMzMuMDYuMzQuMTE1LjQ2LjE4OC4yMy4xNC40NTQuMy42Ny40NTQuMTEuMDc2LjQ0My4yNDMuNDYzLjM3OHoiLz48L3N2Zz4KPHRleHQgeD0iNzEyIiB5PSIxMDMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTJweCI+TWFuYWdlZCBNeVNRTDwvdGV4dD4KPHRleHQgeD0iNzEyIiB5PSIxMjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5NeVNRTCBlbmdpbmU8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iMTU4IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzk0YTNiOCI+TUFOQUdFTUVOVCBSRVFVRVNUUyDCtyBWSUEgVEVOU09SOTwvdGV4dD4KPGxpbmUgeDE9IjE1NCIgeTE9IjE5NiIgeDI9IjMwMCIgeTI9IjE5NiIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoZC1tYW5hZ2VkLW15c3FsKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjIyNyIgeT0iMTg4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YiI+UkRTIEFQSTwvdGV4dD4KPHJlY3QgeD0iMzA0IiB5PSIxNjQiIHdpZHRoPSIxODAiIGhlaWdodD0iNjYiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iMzk0IiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSIzOTQiIHk9IjIwOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+c2VydmljZSBhZGFwdGVyPC90ZXh0Pgo8bGluZSB4MT0iNDg0IiB5MT0iMTk2IiB4Mj0iNjEwIiB5Mj0iMTk2IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLW1hbmFnZWQtbXlzcWwpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHJlY3QgeD0iNjE0IiB5PSIxNjQiIHdpZHRoPSIxOTYiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iNzEyIiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTEuNXB4Ij5EaWdpdGFsT2NlYW4gZGF0YWJhc2UgQVBJPC90ZXh0Pgo8dGV4dCB4PSI3MTIiIHk9IjIxMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPnRoZSBiYWNrZW5kJ3MgbWFuYWdlbWVudCBBUEk8L3RleHQ+Cjwvc3ZnPg==) ![Database requests (MySQL protocol) connect directly to Managed MySQL. The Tensor9 service adapter translates RDS API management calls to DigitalOcean database API.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoTXlTUUwgcHJvdG9jb2wpIGNvbm5lY3QgZGlyZWN0bHkgdG8gTWFuYWdlZCBNeVNRTC4gVGhlIFRlbnNvcjkgc2VydmljZSBhZGFwdGVyIHRyYW5zbGF0ZXMgUkRTIEFQSSBtYW5hZ2VtZW50IGNhbGxzIHRvIERpZ2l0YWxPY2VhbiBkYXRhYmFzZSBBUEkuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojY2JkNWUxfTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImFoZC1tYW5hZ2VkLW15c3FsIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM2NDc0OGIiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjgiIHk9IjM0IiB3aWR0aD0iODIwIiBoZWlnaHQ9IjIwNiIgcng9IjE2IiBzdHJva2Utd2lkdGg9IjEuNCIgc3Ryb2tlLWRhc2hhcnJheT0iNSA1IiBzdHlsZT0iZmlsbDojMGYxNzJhO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjI2IiB5PSI1NCIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGI7IGZpbGw6IzZlZTdiNyI+T04gRElHSVRBTE9DRUFOPC90ZXh0PjxzdmcgeD0iNzkyIiB5PSIzNiIgd2lkdGg9IjE2IiBoZWlnaHQ9IjE2IiB2aWV3Qm94PSIwIDAgMzIgMzIiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiIGZpbGw9Im5vbmUiPjxwYXRoIGQ9Ik0xNi4wMjE5IDI1LjgwMzZWMzJDMjYuNDg3NCAzMiAzNC42MzE2IDIxLjg4ODEgMzEuMjA2NSAxMC45MDJDMjkuNjg0MiA2LjExMjE0IDI1Ljg3ODUgMi4yNzI2OCAyMS4wODM0IDAuNzkwMTEyQzEwLjEyMzEgLTIuNjMxMTkgMCA1LjU0MTkyIDAgMTUuOTk1OUg2LjIwMzI0QzYuMjAzMjQgOS40NTc0MSAxMi43MTA5IDQuMzYzNDcgMTkuNjM3MiA2Ljg3MjQzQzIyLjE4NyA3Ljc4NDc4IDI0LjI0MjEgOS44Mzc1NiAyNS4xNTU1IDEyLjM4NDVDMjcuNjY3MiAxOS4zMDMyIDIyLjYwNTcgMjUuODAzNiAxNi4wMjE5IDI1LjgwMzZaIiBzdHlsZT0iZmlsbDojY2JkNWUxIi8+IDxwYXRoIGQ9Ik05Ljg1NTQ3IDI1Ljg0MTdIMTYuMDIwNlYxOS42ODM0SDkuODU1NDdWMjUuODQxN1oiIHN0eWxlPSJmaWxsOiNjYmQ1ZTEiLz4gPHBhdGggZD0iTTkuODU0NzQgMzAuNTkzNEg1LjA5NzY2VjI1Ljg0MTdMOS44NTU0NyAyNS44NDE3TDkuODU0NzQgMzAuNTkzNFoiIHN0eWxlPSJmaWxsOiNjYmQ1ZTEiLz4gPHBhdGggZD0iTTEuMTA5MzggMjUuODQxN0g1LjA2NzI3VjIxLjg4ODJIMS4xMDkzOFYyNS44NDE3WiIgc3R5bGU9ImZpbGw6I2NiZDVlMSIvPjwvc3ZnPgo8cmVjdCB4PSIyNiIgeT0iODgiIHdpZHRoPSIxMjgiIGhlaWdodD0iMTEyIiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjkwIiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTNweCI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIxNDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5NeVNRTCBkcml2ZXI8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIxNjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2MDAgMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+dW5jaGFuZ2VkPC90ZXh0Pgo8dGV4dCB4PSIyMDAiIHk9IjgyIiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzY0NzQ4YjsgZmlsbDojNmVlN2I3Ij5EQVRBQkFTRSBSRVFVRVNUUyDCtyBESVJFQ1QgQ09OTkVDVElPTjwvdGV4dD4KPGxpbmUgeDE9IjE1NCIgeTE9IjEwOCIgeDI9IjYxMCIgeTI9IjEwOCIgc3Ryb2tlLXdpZHRoPSIyLjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLW1hbmFnZWQtbXlzcWwpIiBzdHlsZT0ic3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iMzgyIiB5PSIxMDAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiM2ZWU3YjciPk15U1FMIHByb3RvY29sPC90ZXh0Pgo8cmVjdCB4PSI2MTQiIHk9Ijc2IiB3aWR0aD0iMTk2IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+PHN2ZyB4PSI3ODYiIHk9IjU2IiB3aWR0aD0iMjAiIGhlaWdodD0iMjAiIHZpZXdCb3g9IjAgMCAyNCAyNCIgcHJlc2VydmVBc3BlY3RSYXRpbz0ieE1pZFlNaWQgbWVldCI+PHRpdGxlPk15U1FMPC90aXRsZT48cGF0aCBkPSJNMTYuNDA1IDUuNTAxYy0uMTE1IDAtLjE5My4wMTQtLjI3NC4wMzN2LjAxM2guMDE0Yy4wNTQuMTA0LjE0Ni4xOC4yMTQuMjczLjA1NC4xMDcuMS4yMTQuMTU0LjMybC4wMTQtLjAxNWMuMDk0LS4wNjYuMTQtLjE3Mi4xNC0uMzMzLS4wNC0uMDQ3LS4wNDYtLjA5NC0uMDgtLjE0LS4wNC0uMDY3LS4xMjYtLjEtLjE4LS4xNTN6TTUuNzcgMTguNjk1aC0uOTI3YTUwLjg1NCA1MC44NTQgMCAwMC0uMjctNC40MWgtLjAwOGwtMS40MSA0LjQxSDIuNDVsLTEuNC00LjQxaC0uMDFhNzIuODkyIDcyLjg5MiAwIDAwLS4xOTUgNC40MUgwYy4wNTUtMS45NjYuMTkyLTMuODEuNDEtNS41M2gxLjE1bDEuMzM1IDQuMDY0aC4wMDhsMS4zNDctNC4wNjRoMS4wOTVjLjI0MiAyLjAxNS4zODQgMy44Ni40MjggNS41M3ptNC4wMTctNC4wOGMtLjM3OCAyLjA0NS0uODc2IDMuNTMzLTEuNDkyIDQuNDYtLjQ4Mi43MTYtMS4wMSAxLjA3My0xLjU4MyAxLjA3My0uMTUzIDAtLjM0LS4wNDYtLjU2Ni0uMTM4di0uNDk0Yy4xMS4wMTcuMjQuMDI2LjM4Ni4wMjYuMjY4IDAgLjQ4My0uMDc1LjY0Ny0uMjIyLjE5Ny0uMTguMjk1LS4zODIuMjk1LS42MDUgMC0uMTU1LS4wNzctLjQ3LS4yMy0uOTQ0TDYuMjMgMTQuNjE1aC45MWwuNzI3IDIuMzZjLjE2NC41MzYuMjMzLjkxLjIwNSAxLjEyMy40LTEuMDY0LjY3OC0yLjIyNy44MzUtMy40ODN6bTEyLjMyNSA0LjA4aC0yLjYzdi01LjUzaC44ODV2NC44NWgxLjc0NXptLTMuMzIuMTM1bC0xLjAxNi0uNWMuMDktLjA3Ni4xNzctLjE1OC4yNTUtLjI1LjQzMy0uNTA2LjY0OC0xLjI1OC42NDgtMi4yNTMgMC0xLjgzLS43MTgtMi43NDYtMi4xNTUtMi43NDYtLjcwNCAwLTEuMjU0LjIzMi0xLjY1LjY5Ny0uNDMuNTA4LS42NDYgMS4yNTYtLjY0NiAyLjI0NSAwIC45NzIuMTkgMS42ODYuNTc0IDIuMTQuMzUuNDEuODc3LjYxNSAxLjU4My42MTUuMjY0IDAgLjUwNi0uMDMzLjcyNS0uMDk4bDEuMzI1Ljc3Mi4zNi0uNjIyek0xNS41IDE3LjU4OGMtLjIyNS0uMzYtLjMzNy0uOTQtLjMzNy0xLjczNiAwLTEuMzkzLjQyNC0yLjA5IDEuMjctMi4wOS40NDMgMCAuNzcuMTY3Ljk3Ny41LjIyNC4zNjIuMzM2LjkzNi4zMzYgMS43MjMgMCAxLjQwNC0uNDI0IDIuMTA4LTEuMjcgMi4xMDgtLjQ0NSAwLS43Ny0uMTY3LS45NzgtLjV6bS0xLjY1OC0uNDI1YzAgLjQ3LS4xNzIuODU2LS41MTYgMS4xNTYtLjM0NC4zLS44MDMuNDUtMS4zODQuNDUtLjU0MyAwLTEuMDY0LS4xNzItMS41NzMtLjUxNWwuMjM3LS40NzZjLjQzOC4yMi44MzMuMzI4IDEuMTkuMzI4LjMzMiAwIC41OTMtLjA3My43ODMtLjIyYS43NTQuNzU0IDAgMDAuMy0uNjE1YzAtLjMzLS4yMy0uNjEtLjY0OC0uODQ1LS4zODgtLjIxMy0xLjE2My0uNjU3LTEuMTYzLS42NTctLjQyMi0uMzA3LS42MzItLjYzNi0uNjMyLTEuMTc3IDAtLjQ1LjE1Ny0uODEuNDctMS4wODUuMzE1LS4yNzguNzItLjQxNSAxLjIyLS40MTUuNTEyIDAgLjk4LjEzNiAxLjQuNDFsLS4yMTMuNDc2YTIuNzI2IDIuNzI2IDAgMDAtMS4wNjQtLjIzYy0uMjgzIDAtLjUwMi4wNjgtLjY1NC4yMDZhLjY4NS42ODUgMCAwMC0uMjQ4LjUyNGMwIC4zMjguMjM0LjYxLjY2Ni44NS4zOTMuMjE1IDEuMTg3LjY3IDEuMTg3LjY3LjQzMy4zMDUuNjQ4LjYzLjY0OCAxLjE2OHptOS4zODItNS44NTJjLS41MzUtLjAxNC0uOTUuMDQtMS4yOTcuMTg4LS4xLjA0LS4yNi4wNC0uMjc0LjE2Ny4wNTUuMDUzLjA2My4xNC4xMS4yMTQuMDguMTM0LjIxOC4zMTMuMzQ2LjQwNy4xNC4xMS4yOC4yMTYuNDI3LjMxLjI2LjE2LjU1NS4yNTUuODEuNDE2LjE0NS4wOTQuMjkzLjIxMy40NC4zMTMuMDczLjA1LjEyLjE0LjIxNC4xNzJ2LS4wMmMtLjA0Ni0uMDYtLjA2LS4xNDctLjEwNS0uMjE0LS4wNjctLjA2Ny0uMTM0LS4xMjctLjItLjE5M2EzLjIyMyAzLjIyMyAwIDAwLS42OTUtLjY3NWMtLjIxNC0uMTQ2LS42ODItLjM1LS43Ny0uNTk1bC0uMDEzLS4wMTRjLjE0Ni0uMDEzLjMyLS4wNjYuNDYtLjEwNi4yMjctLjA2LjQzNS0uMDQ3LjY3LS4xMDYuMTA2LS4wMjcuMjEzLS4wNi4zMi0uMDk0di0uMDZjLS4xMi0uMTItLjIxLS4yODMtLjMzNC0uMzk1YTguODY3IDguODY3IDAgMDAtMS4xMDQtLjgyM2MtLjIxLS4xMzQtLjQ3Ni0uMjItLjY5Ny0uMzM0LS4wOC0uMDQtLjIxNC0uMDYtLjI2LS4xMjctLjEyLS4xNDYtLjE5LS4zNC0uMjc1LS41MTRhMTcuNjkgMTcuNjkgMCAwMS0uNTQ3LTEuMTYzYy0uMTItLjI2Mi0uMTkzLS41MjMtLjM0LS43NjMtLjY5LTEuMTM3LTEuNDM3LTEuODI2LTIuNTg2LTIuNS0uMjQ3LS4xNC0uNTQzLS4yLS44NTYtLjI3NC0uMTY3LS4wMDgtLjMzNC0uMDItLjUtLjAyNy0uMTEtLjA0Ny0uMjE2LS4xNzQtLjMxLS4yMzUtLjM4LS4yNC0xLjM2NC0uNzYtMS42NDQtLjA3Mi0uMTguNDM0LjI2Ny44NjIuNDIyIDEuMDgyLjExNS4xNTMuMjYuMzI4LjM0LjUuMDQ3LjExNi4wNi4yMzUuMTA3LjM1Ni4xMDYuMjk0LjIwNy42MjIuMzQ3Ljg5Ny4wNzMuMTQuMTUzLjI4Ny4yNDcuNDEzLjA1NC4wNzMuMTQ2LjEwNy4xNjcuMjI3LS4wOTQuMTM2LS4xLjMzNC0uMTU0LjUtLjI0Ljc1Ny0uMTQ2IDEuNjkzLjE5NCAyLjI1LjEwNy4xNjYuMzYyLjUzNC43MDMuMzkzLjMtLjEyLjIzNC0uNS4zMi0uODM1LjAyLS4wOC4wMDctLjEzMy4wNDgtLjE4N3YuMDE1Yy4wOTQuMTg4LjE4OC4zNjcuMjc0LjU1NS4yMDYuMzI4LjU2Ni42NjguODY3Ljg5NS4xNi4xMi4yODcuMzI4LjQ4Ny40MDJ2LS4wMmgtLjAxNWMtLjA0My0uMDU4LS4xLS4wODYtLjE1NC0uMTMzYTMuNDQ1IDMuNDQ1IDAgMDEtLjM1LS40IDguNzYgOC43NiAwIDAxLS43NDctMS4yMThjLS4xMS0uMjEtLjIwMi0uNDM2LS4yOS0uNjQzLS4wNC0uMDgtLjA0LS4yLS4xMDctLjI0LS4xLjE0Ni0uMjQ3LjI3My0uMzIuNDUzLS4xMjcuMjg4LS4xNC42NDItLjE4OCAxLjAxLS4wMjcuMDA3LS4wMTQgMC0uMDI3LjAxNC0uMjE0LS4wNTItLjI4Ny0uMjc0LS4zNjctLjQ2LS4yLS40NzUtLjIzMy0xLjIzOC0uMDYtMS43ODUuMDQ3LS4xNC4yNDctLjU4Mi4xNjctLjcxNi0uMDQyLS4xMjctLjE3NC0uMi0uMjQ3LS4zMDNhMi40NzggMi40NzggMCAwMS0uMjQtLjQyN2MtLjE2LS4zNzQtLjI0LS43ODgtLjQxNC0xLjE2Mi0uMDgtLjE3My0uMjItLjM1NC0uMzM0LS41MTMtLjEyNy0uMTgtLjI2Ny0uMzA3LS4zNjgtLjUyLS4wMzMtLjA3My0uMDgtLjE5NC0uMDI3LS4yNzQuMDE0LS4wNTQuMDQyLS4wNzUuMDk0LS4wOS4wODgtLjA3Mi4zMzUuMDIyLjQyMi4wNjIuMjQ3LjEuNDU1LjE5NC42NjIuMzM0LjA5NC4wNjYuMTk1LjE5My4zMTUuMjI2aC4xNGMuMjE0LjA0Ny40NTUuMDE0LjY1NS4wNzMuMzU1LjExNC42NzUuMjguOTYyLjQ2YTUuOTUzIDUuOTUzIDAgMDEyLjA4NSAyLjI4NmMuMDguMTU0LjExNS4yOTUuMTg4LjQ1NS4xNC4zMy4zMTMuNjYzLjQ1NS45ODIuMTQuMzE1LjI3NS42MzYuNDc2Ljg5Ny4xLjE0LjUwMi4yMTMuNjgyLjI4Ni4xMzMuMDYuMzQuMTE1LjQ2LjE4OC4yMy4xNC40NTQuMy42Ny40NTQuMTEuMDc2LjQ0My4yNDMuNDYzLjM3OHoiLz48L3N2Zz4KPHRleHQgeD0iNzEyIiB5PSIxMDMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTJweCI+TWFuYWdlZCBNeVNRTDwvdGV4dD4KPHRleHQgeD0iNzEyIiB5PSIxMjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5NeVNRTCBlbmdpbmU8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iMTU4IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzY0NzQ4YiI+TUFOQUdFTUVOVCBSRVFVRVNUUyDCtyBWSUEgVEVOU09SOTwvdGV4dD4KPGxpbmUgeDE9IjE1NCIgeTE9IjE5NiIgeDI9IjMwMCIgeTI9IjE5NiIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoZC1tYW5hZ2VkLW15c3FsKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjIyNyIgeT0iMTg4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiOCI+UkRTIEFQSTwvdGV4dD4KPHJlY3QgeD0iMzA0IiB5PSIxNjQiIHdpZHRoPSIxODAiIGhlaWdodD0iNjYiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iMzk0IiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSIzOTQiIHk9IjIwOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+c2VydmljZSBhZGFwdGVyPC90ZXh0Pgo8bGluZSB4MT0iNDg0IiB5MT0iMTk2IiB4Mj0iNjEwIiB5Mj0iMTk2IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLW1hbmFnZWQtbXlzcWwpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHJlY3QgeD0iNjE0IiB5PSIxNjQiIHdpZHRoPSIxOTYiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iNzEyIiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTEuNXB4Ij5EaWdpdGFsT2NlYW4gZGF0YWJhc2UgQVBJPC90ZXh0Pgo8dGV4dCB4PSI3MTIiIHk9IjIxMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPnRoZSBiYWNrZW5kJ3MgbWFuYWdlbWVudCBBUEk8L3RleHQ+Cjwvc3ZnPg==) Queries reach the database directly; only the management calls are translated. #### Backups and recovery DigitalOcean takes daily backups and offers point-in-time recovery for the last seven days. A restore creates a new primary, and you must add standby and read-only nodes again. Verify the recovered data before you switch applications to the new endpoint. If the workload needs backups kept longer than DigitalOcean's window, keep a separate export. #### Standby nodes and read replicas Standby nodes recover the database automatically within its region. Read-only nodes are separate resources with their own endpoints, and you can place them in another region. Promoting a read-only node creates an independent primary cluster and ends its replication from the original. Allow for replication lag before you move writes to it. #### Settings, access, and pooling The plan you choose sets the available database version, capacity and standby options. Supported engine settings map to DigitalOcean's database configuration. Check the supported MySQL version and plugins. DigitalOcean does not provide managed MySQL connection pooling; configure a pool in the application or a separate pooler if you need one. Connections use DigitalOcean database users, TLS and trusted-source rules. #### Limitations Where RDS and DigitalOcean Managed MySQL differ * **RDS snapshots behave differently: restores come from DigitalOcean's backup timeline.** Restores use DigitalOcean's seven-day backup timeline and create a new primary. Independently retained RDS snapshots and a custom AWS backup schedule are not reproduced. * **Promotion behaves differently: a promoted read-only node becomes a separate primary.** Promotion ends replication from the original. It is not the same as forcing failover to a standby or performing an Aurora Global Database switchover. * **Stopping and starting the database is not supported.** This mapping does not provide an RDS-style paused database. * **Parameter groups behave differently: settings apply to the database itself.** Supported engine settings map to DigitalOcean's database configuration. The reusable RDS parameter-group object has no equivalent, and DigitalOcean fixes some engine variables. * **AWS IAM database tokens and customer KMS keys are not supported.** An AWS role token or customer KMS key cannot stand in for DigitalOcean database credentials or DigitalOcean-managed encryption keys. * **Event subscriptions and Performance Insights are not supported.** They do not become the same AWS services on DigitalOcean; backend monitoring works differently. * **RDS-specific SQL helpers are not supported.** SQL helpers for AWS integrations do not exist on DigitalOcean. Use the selected engine's own SQL functions. #### Other considerations **Moving data.** Copy existing data with the engine's dump and restore tools or a supported online migration workflow. Check the schema, users, required extensions or plugins, and application queries before you switch connection settings. **Who operates what.** DigitalOcean operates the database service. The customer controls the plan, access rules, application cutover and permissions for backend monitoring. #### Example monthly charges This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include. ##### RDS MySQL · Primary allocated compute Feature: RDS MySQL. Estimated monthly service charges by Primary allocated compute. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: nyc; currency: USD. ![RDS MySQL · Primary allocated compute: monthly service charges by Primary allocated compute. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/78a5ba319f8b5a3b93be40b1a1bd235cc8d5e4321e831985604914913abcf2b0-light.svg) ![RDS MySQL · Primary allocated compute: monthly service charges by Primary allocated compute. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/ea00bd3f6a3cd5bb3b0f7cbe4d4a10318114fa047f05d91c34bbbadd5df75c5e-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Primary allocated compute (vCPU-hours/month) | RDS MySQL | Target scenario | DigitalOcean Managed MySQL | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | DigitalOcean Managed MySQL (one copy) | 141.50 | 141.50 | | 0 | 0.00 | DigitalOcean Managed MySQL (two copies) | 283.00 | 283.00 | | 1,460 | 124.83 | DigitalOcean Managed MySQL (one copy) | 141.50 | 16.67 | | 1,460 | 124.83 | DigitalOcean Managed MySQL (two copies) | 283.00 | 158.17 | | 2,920 | 249.66 | DigitalOcean Managed MySQL (one copy) | 271.50 | 21.84 | | 2,920 | 249.66 | DigitalOcean Managed MySQL (two copies) | 543.00 | 293.34 | | 5,840 | 499.32 | DigitalOcean Managed MySQL (one copy) | 531.50 | 32.18 | | 5,840 | 499.32 | DigitalOcean Managed MySQL (two copies) | 1,063.00 | 563.68 | | 11,680 | 998.64 | DigitalOcean Managed MySQL (one copy) | 1,051.50 | 52.86 | | 11,680 | 998.64 | DigitalOcean Managed MySQL (two copies) | 2,103.00 | 1,104.36 | | 23,360 | 1,997.28 | DigitalOcean Managed MySQL (one copy) | 2,091.50 | 94.22 | | 23,360 | 1,997.28 | DigitalOcean Managed MySQL (two copies) | 4,183.00 | 2,185.72 | | 46,720 | 3,994.56 | DigitalOcean Managed MySQL (one copy) | Unpriced | Unavailable | | 46,720 | 3,994.56 | DigitalOcean Managed MySQL (two copies) | Unpriced | Unavailable | Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 vCPU-hours/month to 32 vCPU, 128 GiB memory and 100 GiB SSD at 23,360 vCPU-hours/month. From 46,720 vCPU-hours/month the workload exceeds the planning range and the target is unpriced. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | DigitalOcean Managed MySQL (one copy) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | DigitalOcean Managed MySQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | DigitalOcean Managed MySQL (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | DigitalOcean Managed MySQL (one copy) | Origin list price · Database reads | 0 | USD/operations | | DigitalOcean Managed MySQL (one copy) | Origin list price · Database writes | 0 | USD/operations | | DigitalOcean Managed MySQL (one copy) | Target CPU / source CPU | 1 | multiplier | | DigitalOcean Managed MySQL (one copy) | Target RAM / source RAM | 1 | multiplier | | DigitalOcean Managed MySQL (one copy) | Target disk / source disk | 1 | multiplier | | DigitalOcean Managed MySQL (one copy) | Target price guess · read | 0 | USD/read | | DigitalOcean Managed MySQL (one copy) | Target price guess · write | 0 | USD/write | | DigitalOcean Managed MySQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | DigitalOcean Managed MySQL (one copy) | Target list price · GiB-month | 0.115 | USD/GiB-month | | DigitalOcean Managed MySQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | DigitalOcean Managed MySQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | DigitalOcean Managed MySQL (one copy) | Target price guess · network GiB | 0 | USD/network GiB | | DigitalOcean Managed MySQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | DigitalOcean Managed MySQL (one copy) | Target list price · vCPU-hour | 0.0547945 | USD/vCPU-hour | | DigitalOcean Managed MySQL (one copy) | Target list price · GiB-hour | 0.00856164 | USD/GiB-hour | | DigitalOcean Managed MySQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | DigitalOcean Managed MySQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | DigitalOcean Managed MySQL (one copy) | Target price guess · input token | 0 | USD/input token | | DigitalOcean Managed MySQL (one copy) | Target price guess · output token | 0 | USD/output token | | DigitalOcean Managed MySQL (one copy) | Target monthly base charge | 0 | USD/month | | DigitalOcean Managed MySQL (one copy) | Target service minimum | 135.75 | USD/month | | DigitalOcean Managed MySQL (one copy) | Minimum primary CPU | 2 | vCPU | | DigitalOcean Managed MySQL (one copy) | Minimum primary RAM | 8 | GiB | | DigitalOcean Managed MySQL (one copy) | Minimum primary disk | 100 | GiB | | DigitalOcean Managed MySQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | DigitalOcean Managed MySQL (one copy) | Allocated share of provisioned cost | 1 | fraction | | DigitalOcean Managed MySQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | DigitalOcean Managed MySQL (one copy) | Planning peak / mean work | 2 | multiplier | | DigitalOcean Managed MySQL (one copy) | Planning primary CPU utilization | 0.7 | fraction | | DigitalOcean Managed MySQL (one copy) | Resident state reserved in RAM | 0.1 | fraction | | DigitalOcean Managed MySQL (one copy) | Planning disk utilization | 0.8 | fraction | | DigitalOcean Managed MySQL (one copy) | Maintenance and log disk reserve | 20 | GiB | | DigitalOcean Managed MySQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | DigitalOcean Managed MySQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | DigitalOcean Managed MySQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | DigitalOcean Managed MySQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | DigitalOcean Managed MySQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | DigitalOcean Managed MySQL (two copies) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | DigitalOcean Managed MySQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | DigitalOcean Managed MySQL (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | DigitalOcean Managed MySQL (two copies) | Origin list price · Database reads | 0 | USD/operations | | DigitalOcean Managed MySQL (two copies) | Origin list price · Database writes | 0 | USD/operations | | DigitalOcean Managed MySQL (two copies) | Target CPU / source CPU | 1 | multiplier | | DigitalOcean Managed MySQL (two copies) | Target RAM / source RAM | 1 | multiplier | | DigitalOcean Managed MySQL (two copies) | Target disk / source disk | 1 | multiplier | | DigitalOcean Managed MySQL (two copies) | Target price guess · read | 0 | USD/read | | DigitalOcean Managed MySQL (two copies) | Target price guess · write | 0 | USD/write | | DigitalOcean Managed MySQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | DigitalOcean Managed MySQL (two copies) | Target list price · GiB-month | 0.115 | USD/GiB-month | | DigitalOcean Managed MySQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | DigitalOcean Managed MySQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | DigitalOcean Managed MySQL (two copies) | Target price guess · network GiB | 0 | USD/network GiB | | DigitalOcean Managed MySQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | DigitalOcean Managed MySQL (two copies) | Target list price · vCPU-hour | 0.0547945 | USD/vCPU-hour | | DigitalOcean Managed MySQL (two copies) | Target list price · GiB-hour | 0.00856164 | USD/GiB-hour | | DigitalOcean Managed MySQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | DigitalOcean Managed MySQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | DigitalOcean Managed MySQL (two copies) | Target price guess · input token | 0 | USD/input token | | DigitalOcean Managed MySQL (two copies) | Target price guess · output token | 0 | USD/output token | | DigitalOcean Managed MySQL (two copies) | Target monthly base charge | 0 | USD/month | | DigitalOcean Managed MySQL (two copies) | Target service minimum | 135.75 | USD/month | | DigitalOcean Managed MySQL (two copies) | Minimum primary CPU | 2 | vCPU | | DigitalOcean Managed MySQL (two copies) | Minimum primary RAM | 8 | GiB | | DigitalOcean Managed MySQL (two copies) | Minimum primary disk | 100 | GiB | | DigitalOcean Managed MySQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | DigitalOcean Managed MySQL (two copies) | Allocated share of provisioned cost | 1 | fraction | | DigitalOcean Managed MySQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | DigitalOcean Managed MySQL (two copies) | Planning peak / mean work | 2 | multiplier | | DigitalOcean Managed MySQL (two copies) | Planning primary CPU utilization | 0.7 | fraction | | DigitalOcean Managed MySQL (two copies) | Resident state reserved in RAM | 0.1 | fraction | | DigitalOcean Managed MySQL (two copies) | Planning disk utilization | 0.8 | fraction | | DigitalOcean Managed MySQL (two copies) | Maintenance and log disk reserve | 20 | GiB | | DigitalOcean Managed MySQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | DigitalOcean Managed MySQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | DigitalOcean Managed MySQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | DigitalOcean Managed MySQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | DigitalOcean Managed MySQL (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * CPU allocation does not imply an achieved transaction rate. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements. * Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → nyc, USD/month. * Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded. * Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied. * Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * DigitalOcean Managed MySQL priced at Advanced Edition rates, the edition that keeps standby nodes and plans above 4 GiB: from 2026-10-15 for new accounts and 2026-11-30 for all accounts, new Standard Edition clusters cannot exceed 4 GiB or add standby or read-only nodes ([https://docs.digitalocean.com/products/databases/postgresql/details/pricing/](https://docs.digitalocean.com/products/databases/postgresql/details/pricing/)). The vCPU and memory rates decompose the General Purpose (1:4) and Storage Optimized (1:8) node prices, which fit every plan up to 32 vCPUs exactly; each standby node bills at its primary's price. Traffic to and from managed databases does not count against DigitalOcean bandwidth billing, so selected network is not charged. Standard Edition (a 1 GiB single node is USD 13 plus 10 GiB at 0.215, 15.15/month) is not selected. Whether standby nodes also bill storage is not stated. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: The largest plan has 256 GiB and storage reaches 20 TB ([https://www.digitalocean.com/blog/larger-plan-sizes-for-mysql-and-postgresql](https://www.digitalocean.com/blog/larger-plan-sizes-for-mysql-and-postgresql)); this model's rates fit plans up to 32 vCPUs. * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonRDS offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json) * DigitalOcean Managed Databases pricing: [https://www.digitalocean.com/pricing/managed-databases](https://www.digitalocean.com/pricing/managed-databases) * DigitalOcean Managed Databases pricing: [https://docs.digitalocean.com/products/databases/postgresql/details/pricing/](https://docs.digitalocean.com/products/databases/postgresql/details/pricing/) Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. List prices read: 2026-10-22. Model: `plan-6ab1eebb3f2c2d122a724e244e3f16435bacdfd3` / `2026-10-22.planning.2`. Curve: `workload-1`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [DigitalOcean Managed Databases pricing](https://www.digitalocean.com/pricing/managed-databases), [DigitalOcean Managed Databases pricing](https://docs.digitalocean.com/products/databases/postgresql/details/pricing/). ##### RDS MySQL · Stored data Feature: RDS MySQL. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: nyc; currency: USD. ![RDS MySQL · Stored data: monthly service charges by Stored data. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/d64ecfea72da6b898b49faa99b2e41a161ec24363554491cbc4fc1f4f388ea70-light.svg) ![RDS MySQL · Stored data: monthly service charges by Stored data. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/d589c4e8e317dfaf5b6984a616bb4be5590256e290bbf68f2c7c96f6d6e852c7-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Stored data (GiB-month) | RDS MySQL | Target scenario | DigitalOcean Managed MySQL | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | DigitalOcean Managed MySQL (one copy) | 141.50 | 141.50 | | 0 | 0.00 | DigitalOcean Managed MySQL (two copies) | 283.00 | 283.00 | | 10 | 1.15 | DigitalOcean Managed MySQL (one copy) | 141.50 | 140.35 | | 10 | 1.15 | DigitalOcean Managed MySQL (two copies) | 283.00 | 281.85 | | 100 | 11.50 | DigitalOcean Managed MySQL (one copy) | 147.25 | 135.75 | | 100 | 11.50 | DigitalOcean Managed MySQL (two copies) | 294.50 | 283.00 | | 1,000 | 115.00 | DigitalOcean Managed MySQL (one copy) | 276.63 | 161.63 | | 1,000 | 115.00 | DigitalOcean Managed MySQL (two copies) | 553.25 | 438.25 | | 10,000 | 1,150.00 | DigitalOcean Managed MySQL (one copy) | 1,570.38 | 420.38 | | 10,000 | 1,150.00 | DigitalOcean Managed MySQL (two copies) | 3,140.75 | 1,990.75 | | 100,000 | 11,500.00 | DigitalOcean Managed MySQL (one copy) | Unpriced | Unavailable | | 100,000 | 11,500.00 | DigitalOcean Managed MySQL (two copies) | Unpriced | Unavailable | Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 GiB-month to 2 vCPU, 8 GiB memory and 12,525 GiB SSD at 10,000 GiB-month. From 100,000 GiB-month the workload exceeds the planning range and the target is unpriced. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | DigitalOcean Managed MySQL (one copy) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | DigitalOcean Managed MySQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | DigitalOcean Managed MySQL (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | DigitalOcean Managed MySQL (one copy) | Origin list price · Database reads | 0 | USD/operations | | DigitalOcean Managed MySQL (one copy) | Origin list price · Database writes | 0 | USD/operations | | DigitalOcean Managed MySQL (one copy) | Target CPU / source CPU | 1 | multiplier | | DigitalOcean Managed MySQL (one copy) | Target RAM / source RAM | 1 | multiplier | | DigitalOcean Managed MySQL (one copy) | Target disk / source disk | 1 | multiplier | | DigitalOcean Managed MySQL (one copy) | Target price guess · read | 0 | USD/read | | DigitalOcean Managed MySQL (one copy) | Target price guess · write | 0 | USD/write | | DigitalOcean Managed MySQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | DigitalOcean Managed MySQL (one copy) | Target list price · GiB-month | 0.115 | USD/GiB-month | | DigitalOcean Managed MySQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | DigitalOcean Managed MySQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | DigitalOcean Managed MySQL (one copy) | Target price guess · network GiB | 0 | USD/network GiB | | DigitalOcean Managed MySQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | DigitalOcean Managed MySQL (one copy) | Target list price · vCPU-hour | 0.0547945 | USD/vCPU-hour | | DigitalOcean Managed MySQL (one copy) | Target list price · GiB-hour | 0.00856164 | USD/GiB-hour | | DigitalOcean Managed MySQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | DigitalOcean Managed MySQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | DigitalOcean Managed MySQL (one copy) | Target price guess · input token | 0 | USD/input token | | DigitalOcean Managed MySQL (one copy) | Target price guess · output token | 0 | USD/output token | | DigitalOcean Managed MySQL (one copy) | Target monthly base charge | 0 | USD/month | | DigitalOcean Managed MySQL (one copy) | Target service minimum | 135.75 | USD/month | | DigitalOcean Managed MySQL (one copy) | Minimum primary CPU | 2 | vCPU | | DigitalOcean Managed MySQL (one copy) | Minimum primary RAM | 8 | GiB | | DigitalOcean Managed MySQL (one copy) | Minimum primary disk | 100 | GiB | | DigitalOcean Managed MySQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | DigitalOcean Managed MySQL (one copy) | Allocated share of provisioned cost | 1 | fraction | | DigitalOcean Managed MySQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | DigitalOcean Managed MySQL (one copy) | Planning peak / mean work | 2 | multiplier | | DigitalOcean Managed MySQL (one copy) | Planning primary CPU utilization | 0.7 | fraction | | DigitalOcean Managed MySQL (one copy) | Resident state reserved in RAM | 0.1 | fraction | | DigitalOcean Managed MySQL (one copy) | Planning disk utilization | 0.8 | fraction | | DigitalOcean Managed MySQL (one copy) | Maintenance and log disk reserve | 20 | GiB | | DigitalOcean Managed MySQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | DigitalOcean Managed MySQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | DigitalOcean Managed MySQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | DigitalOcean Managed MySQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | DigitalOcean Managed MySQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | DigitalOcean Managed MySQL (two copies) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | DigitalOcean Managed MySQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | DigitalOcean Managed MySQL (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | DigitalOcean Managed MySQL (two copies) | Origin list price · Database reads | 0 | USD/operations | | DigitalOcean Managed MySQL (two copies) | Origin list price · Database writes | 0 | USD/operations | | DigitalOcean Managed MySQL (two copies) | Target CPU / source CPU | 1 | multiplier | | DigitalOcean Managed MySQL (two copies) | Target RAM / source RAM | 1 | multiplier | | DigitalOcean Managed MySQL (two copies) | Target disk / source disk | 1 | multiplier | | DigitalOcean Managed MySQL (two copies) | Target price guess · read | 0 | USD/read | | DigitalOcean Managed MySQL (two copies) | Target price guess · write | 0 | USD/write | | DigitalOcean Managed MySQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | DigitalOcean Managed MySQL (two copies) | Target list price · GiB-month | 0.115 | USD/GiB-month | | DigitalOcean Managed MySQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | DigitalOcean Managed MySQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | DigitalOcean Managed MySQL (two copies) | Target price guess · network GiB | 0 | USD/network GiB | | DigitalOcean Managed MySQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | DigitalOcean Managed MySQL (two copies) | Target list price · vCPU-hour | 0.0547945 | USD/vCPU-hour | | DigitalOcean Managed MySQL (two copies) | Target list price · GiB-hour | 0.00856164 | USD/GiB-hour | | DigitalOcean Managed MySQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | DigitalOcean Managed MySQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | DigitalOcean Managed MySQL (two copies) | Target price guess · input token | 0 | USD/input token | | DigitalOcean Managed MySQL (two copies) | Target price guess · output token | 0 | USD/output token | | DigitalOcean Managed MySQL (two copies) | Target monthly base charge | 0 | USD/month | | DigitalOcean Managed MySQL (two copies) | Target service minimum | 135.75 | USD/month | | DigitalOcean Managed MySQL (two copies) | Minimum primary CPU | 2 | vCPU | | DigitalOcean Managed MySQL (two copies) | Minimum primary RAM | 8 | GiB | | DigitalOcean Managed MySQL (two copies) | Minimum primary disk | 100 | GiB | | DigitalOcean Managed MySQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | DigitalOcean Managed MySQL (two copies) | Allocated share of provisioned cost | 1 | fraction | | DigitalOcean Managed MySQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | DigitalOcean Managed MySQL (two copies) | Planning peak / mean work | 2 | multiplier | | DigitalOcean Managed MySQL (two copies) | Planning primary CPU utilization | 0.7 | fraction | | DigitalOcean Managed MySQL (two copies) | Resident state reserved in RAM | 0.1 | fraction | | DigitalOcean Managed MySQL (two copies) | Planning disk utilization | 0.8 | fraction | | DigitalOcean Managed MySQL (two copies) | Maintenance and log disk reserve | 20 | GiB | | DigitalOcean Managed MySQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | DigitalOcean Managed MySQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | DigitalOcean Managed MySQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | DigitalOcean Managed MySQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | DigitalOcean Managed MySQL (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * Request meters remain at their independently authored defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements. * Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → nyc, USD/month. * Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded. * Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied. * Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * DigitalOcean Managed MySQL priced at Advanced Edition rates, the edition that keeps standby nodes and plans above 4 GiB: from 2026-10-15 for new accounts and 2026-11-30 for all accounts, new Standard Edition clusters cannot exceed 4 GiB or add standby or read-only nodes ([https://docs.digitalocean.com/products/databases/postgresql/details/pricing/](https://docs.digitalocean.com/products/databases/postgresql/details/pricing/)). The vCPU and memory rates decompose the General Purpose (1:4) and Storage Optimized (1:8) node prices, which fit every plan up to 32 vCPUs exactly; each standby node bills at its primary's price. Traffic to and from managed databases does not count against DigitalOcean bandwidth billing, so selected network is not charged. Standard Edition (a 1 GiB single node is USD 13 plus 10 GiB at 0.215, 15.15/month) is not selected. Whether standby nodes also bill storage is not stated. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: The largest plan has 256 GiB and storage reaches 20 TB ([https://www.digitalocean.com/blog/larger-plan-sizes-for-mysql-and-postgresql](https://www.digitalocean.com/blog/larger-plan-sizes-for-mysql-and-postgresql)); this model's rates fit plans up to 32 vCPUs. * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonRDS offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json) * DigitalOcean Managed Databases pricing: [https://www.digitalocean.com/pricing/managed-databases](https://www.digitalocean.com/pricing/managed-databases) * DigitalOcean Managed Databases pricing: [https://docs.digitalocean.com/products/databases/postgresql/details/pricing/](https://docs.digitalocean.com/products/databases/postgresql/details/pricing/) Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. List prices read: 2026-10-22. Model: `plan-6ab1eebb3f2c2d122a724e244e3f16435bacdfd3` / `2026-10-22.planning.2`. Curve: `workload-2`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [DigitalOcean Managed Databases pricing](https://www.digitalocean.com/pricing/managed-databases), [DigitalOcean Managed Databases pricing](https://docs.digitalocean.com/products/databases/postgresql/details/pricing/). ##### RDS MySQL · Database writes Feature: RDS MySQL. Estimated monthly service charges by Database writes. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: nyc; currency: USD. ![RDS MySQL · Database writes: monthly service charges by Database writes. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/9c63b3041cc297c1ef7a963ee443f6034f059958b36dc6c7ad0b04365a3af1d5-light.svg) ![RDS MySQL · Database writes: monthly service charges by Database writes. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/3c90e4d68501ea957dd05c24d5b0f91c4847b14329453ff25537bd5e34c2399e-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Database writes (per second) | RDS MySQL | Target scenario | DigitalOcean Managed MySQL | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | DigitalOcean Managed MySQL (one copy) | 141.50 | 141.50 | | 0 | 0.00 | DigitalOcean Managed MySQL (two copies) | 283.00 | 283.00 | | 1 | 0.00 | DigitalOcean Managed MySQL (one copy) | 141.50 | 141.50 | | 1 | 0.00 | DigitalOcean Managed MySQL (two copies) | 283.00 | 283.00 | | 10 | 0.00 | DigitalOcean Managed MySQL (one copy) | 141.50 | 141.50 | | 10 | 0.00 | DigitalOcean Managed MySQL (two copies) | 283.00 | 283.00 | | 100 | 0.00 | DigitalOcean Managed MySQL (one copy) | 141.50 | 141.50 | | 100 | 0.00 | DigitalOcean Managed MySQL (two copies) | 283.00 | 283.00 | | 1,000 | 0.00 | DigitalOcean Managed MySQL (one copy) | 141.50 | 141.50 | | 1,000 | 0.00 | DigitalOcean Managed MySQL (two copies) | 283.00 | 283.00 | | 10,000 | 0.00 | DigitalOcean Managed MySQL (one copy) | 141.50 | 141.50 | | 10,000 | 0.00 | DigitalOcean Managed MySQL (two copies) | 283.00 | 283.00 | Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | DigitalOcean Managed MySQL (one copy) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | DigitalOcean Managed MySQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | DigitalOcean Managed MySQL (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | DigitalOcean Managed MySQL (one copy) | Origin list price · Database reads | 0 | USD/operations | | DigitalOcean Managed MySQL (one copy) | Origin list price · Database writes | 0 | USD/operations | | DigitalOcean Managed MySQL (one copy) | Target CPU / source CPU | 1 | multiplier | | DigitalOcean Managed MySQL (one copy) | Target RAM / source RAM | 1 | multiplier | | DigitalOcean Managed MySQL (one copy) | Target disk / source disk | 1 | multiplier | | DigitalOcean Managed MySQL (one copy) | Target price guess · read | 0 | USD/read | | DigitalOcean Managed MySQL (one copy) | Target price guess · write | 0 | USD/write | | DigitalOcean Managed MySQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | DigitalOcean Managed MySQL (one copy) | Target list price · GiB-month | 0.115 | USD/GiB-month | | DigitalOcean Managed MySQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | DigitalOcean Managed MySQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | DigitalOcean Managed MySQL (one copy) | Target price guess · network GiB | 0 | USD/network GiB | | DigitalOcean Managed MySQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | DigitalOcean Managed MySQL (one copy) | Target list price · vCPU-hour | 0.0547945 | USD/vCPU-hour | | DigitalOcean Managed MySQL (one copy) | Target list price · GiB-hour | 0.00856164 | USD/GiB-hour | | DigitalOcean Managed MySQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | DigitalOcean Managed MySQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | DigitalOcean Managed MySQL (one copy) | Target price guess · input token | 0 | USD/input token | | DigitalOcean Managed MySQL (one copy) | Target price guess · output token | 0 | USD/output token | | DigitalOcean Managed MySQL (one copy) | Target monthly base charge | 0 | USD/month | | DigitalOcean Managed MySQL (one copy) | Target service minimum | 135.75 | USD/month | | DigitalOcean Managed MySQL (one copy) | Minimum primary CPU | 2 | vCPU | | DigitalOcean Managed MySQL (one copy) | Minimum primary RAM | 8 | GiB | | DigitalOcean Managed MySQL (one copy) | Minimum primary disk | 100 | GiB | | DigitalOcean Managed MySQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | DigitalOcean Managed MySQL (one copy) | Allocated share of provisioned cost | 1 | fraction | | DigitalOcean Managed MySQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | DigitalOcean Managed MySQL (one copy) | Planning peak / mean work | 2 | multiplier | | DigitalOcean Managed MySQL (one copy) | Planning primary CPU utilization | 0.7 | fraction | | DigitalOcean Managed MySQL (one copy) | Resident state reserved in RAM | 0.1 | fraction | | DigitalOcean Managed MySQL (one copy) | Planning disk utilization | 0.8 | fraction | | DigitalOcean Managed MySQL (one copy) | Maintenance and log disk reserve | 20 | GiB | | DigitalOcean Managed MySQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | DigitalOcean Managed MySQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | DigitalOcean Managed MySQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | DigitalOcean Managed MySQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | DigitalOcean Managed MySQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | DigitalOcean Managed MySQL (two copies) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | DigitalOcean Managed MySQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | DigitalOcean Managed MySQL (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | DigitalOcean Managed MySQL (two copies) | Origin list price · Database reads | 0 | USD/operations | | DigitalOcean Managed MySQL (two copies) | Origin list price · Database writes | 0 | USD/operations | | DigitalOcean Managed MySQL (two copies) | Target CPU / source CPU | 1 | multiplier | | DigitalOcean Managed MySQL (two copies) | Target RAM / source RAM | 1 | multiplier | | DigitalOcean Managed MySQL (two copies) | Target disk / source disk | 1 | multiplier | | DigitalOcean Managed MySQL (two copies) | Target price guess · read | 0 | USD/read | | DigitalOcean Managed MySQL (two copies) | Target price guess · write | 0 | USD/write | | DigitalOcean Managed MySQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | DigitalOcean Managed MySQL (two copies) | Target list price · GiB-month | 0.115 | USD/GiB-month | | DigitalOcean Managed MySQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | DigitalOcean Managed MySQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | DigitalOcean Managed MySQL (two copies) | Target price guess · network GiB | 0 | USD/network GiB | | DigitalOcean Managed MySQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | DigitalOcean Managed MySQL (two copies) | Target list price · vCPU-hour | 0.0547945 | USD/vCPU-hour | | DigitalOcean Managed MySQL (two copies) | Target list price · GiB-hour | 0.00856164 | USD/GiB-hour | | DigitalOcean Managed MySQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | DigitalOcean Managed MySQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | DigitalOcean Managed MySQL (two copies) | Target price guess · input token | 0 | USD/input token | | DigitalOcean Managed MySQL (two copies) | Target price guess · output token | 0 | USD/output token | | DigitalOcean Managed MySQL (two copies) | Target monthly base charge | 0 | USD/month | | DigitalOcean Managed MySQL (two copies) | Target service minimum | 135.75 | USD/month | | DigitalOcean Managed MySQL (two copies) | Minimum primary CPU | 2 | vCPU | | DigitalOcean Managed MySQL (two copies) | Minimum primary RAM | 8 | GiB | | DigitalOcean Managed MySQL (two copies) | Minimum primary disk | 100 | GiB | | DigitalOcean Managed MySQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | DigitalOcean Managed MySQL (two copies) | Allocated share of provisioned cost | 1 | fraction | | DigitalOcean Managed MySQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | DigitalOcean Managed MySQL (two copies) | Planning peak / mean work | 2 | multiplier | | DigitalOcean Managed MySQL (two copies) | Planning primary CPU utilization | 0.7 | fraction | | DigitalOcean Managed MySQL (two copies) | Resident state reserved in RAM | 0.1 | fraction | | DigitalOcean Managed MySQL (two copies) | Planning disk utilization | 0.8 | fraction | | DigitalOcean Managed MySQL (two copies) | Maintenance and log disk reserve | 20 | GiB | | DigitalOcean Managed MySQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | DigitalOcean Managed MySQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | DigitalOcean Managed MySQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | DigitalOcean Managed MySQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | DigitalOcean Managed MySQL (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * Source compute and stored data remain independent; a throughput view needs explicit workload inputs. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements. * Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → nyc, USD/month. * Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded. * Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied. * Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * DigitalOcean Managed MySQL priced at Advanced Edition rates, the edition that keeps standby nodes and plans above 4 GiB: from 2026-10-15 for new accounts and 2026-11-30 for all accounts, new Standard Edition clusters cannot exceed 4 GiB or add standby or read-only nodes ([https://docs.digitalocean.com/products/databases/postgresql/details/pricing/](https://docs.digitalocean.com/products/databases/postgresql/details/pricing/)). The vCPU and memory rates decompose the General Purpose (1:4) and Storage Optimized (1:8) node prices, which fit every plan up to 32 vCPUs exactly; each standby node bills at its primary's price. Traffic to and from managed databases does not count against DigitalOcean bandwidth billing, so selected network is not charged. Standard Edition (a 1 GiB single node is USD 13 plus 10 GiB at 0.215, 15.15/month) is not selected. Whether standby nodes also bill storage is not stated. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: The largest plan has 256 GiB and storage reaches 20 TB ([https://www.digitalocean.com/blog/larger-plan-sizes-for-mysql-and-postgresql](https://www.digitalocean.com/blog/larger-plan-sizes-for-mysql-and-postgresql)); this model's rates fit plans up to 32 vCPUs. * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonRDS offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json) * DigitalOcean Managed Databases pricing: [https://www.digitalocean.com/pricing/managed-databases](https://www.digitalocean.com/pricing/managed-databases) * DigitalOcean Managed Databases pricing: [https://docs.digitalocean.com/products/databases/postgresql/details/pricing/](https://docs.digitalocean.com/products/databases/postgresql/details/pricing/) Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. List prices read: 2026-10-22. Model: `plan-6ab1eebb3f2c2d122a724e244e3f16435bacdfd3` / `2026-10-22.planning.2`. Curve: `workload-3`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [DigitalOcean Managed Databases pricing](https://www.digitalocean.com/pricing/managed-databases), [DigitalOcean Managed Databases pricing](https://docs.digitalocean.com/products/databases/postgresql/details/pricing/). **RDS MySQL → DigitalOcean Managed MySQL: Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: nyc. Currency: USD. | Monthly component | USD | | - | -: | | Origin: Primary compute | 0.00 | | Origin: Primary memory | 0.00 | | Origin: Primary provisioned storage | 0.00 | | Origin: Database reads | 0.00 | | Origin: Database writes | 0.00 | | Target: Provisioned primary CPU | 80.00 | | Target: Provisioned primary RAM | 50.00 | | Target: Provisioned primary disk | 11.50 | | Target: Selected billable network | 0.00 | | Target: Independent provisioned resources | 0.00 | | Target: Independent managed resources | 0.00 | | **Origin service subtotal** | **0.00** | | **Target service subtotal** | **141.50** | Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. **Scenario assumptions** | Input | Value | Unit | | - | -: | - | | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Origin list price · Primary memory | 0 | USD/GiB-hours | | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Origin list price · Database reads | 0 | USD/operations | | Origin list price · Database writes | 0 | USD/operations | | Target CPU / source CPU | 1 | multiplier | | Target RAM / source RAM | 1 | multiplier | | Target disk / source disk | 1 | multiplier | | Target price guess · read | 0 | USD/read | | Target price guess · write | 0 | USD/write | | Target price guess · provider operation | 0 | USD/provider operation | | Target list price · GiB-month | 0.115 | USD/GiB-month | | Target price guess · published GiB | 0 | USD/published GiB | | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Target price guess · network GiB | 0 | USD/network GiB | | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Target list price · vCPU-hour | 0.0547945 | USD/vCPU-hour | | Target list price · GiB-hour | 0.00856164 | USD/GiB-hour | | Target price guess · resource-hour | 0 | USD/resource-hour | | Target price guess · resource-month | 0 | USD/resource-month | | Target price guess · input token | 0 | USD/input token | | Target price guess · output token | 0 | USD/output token | | Target monthly base charge | 0 | USD/month | | Target service minimum | 135.75 | USD/month | | Minimum primary CPU | 2 | vCPU | | Minimum primary RAM | 8 | GiB | | Minimum primary disk | 100 | GiB | | Additional full-price standby copy | 0 | 0 or 1 | | Allocated share of provisioned cost | 1 | fraction | | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Planning peak / mean work | 2 | multiplier | | Planning primary CPU utilization | 0.7 | fraction | | Resident state reserved in RAM | 0.1 | fraction | | Planning disk utilization | 0.8 | fraction | | Maintenance and log disk reserve | 20 | GiB | | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Dependent object sink write price guess | 0.000005 | USD/write | | Primary compute | 0 | vCPU-hours | | Primary memory | 0 | GiB-hours | | Primary provisioned storage | 0 | GiB-month | | Database reads | 0 | operations | | Database writes | 0 | operations | * Translated reads: 0 operations. * Translated writes: 0 operations. * Translated resident physical data: 0 GiB-month. * Native provider operations: 0 operations. * Published payload: 0 GiB. * Delivered payload: 0 GiB. * Allocated execution CPU: 0 vCPU-hour. * Allocated execution RAM: 0 GiB-hour. * Independent resource allocation: 0 resource-hour. * Independent inventory: 0 resource-month. * Input tokens: 0 tokens. * Output tokens: 0 tokens. * Billable network: 0 GiB. * Dependent object sink retained data: 0 GiB-month. * Dependent object sink writes: 0 writes. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * DigitalOcean Managed MySQL priced at Advanced Edition rates, the edition that keeps standby nodes and plans above 4 GiB: from 2026-10-15 for new accounts and 2026-11-30 for all accounts, new Standard Edition clusters cannot exceed 4 GiB or add standby or read-only nodes ([https://docs.digitalocean.com/products/databases/postgresql/details/pricing/](https://docs.digitalocean.com/products/databases/postgresql/details/pricing/)). The vCPU and memory rates decompose the General Purpose (1:4) and Storage Optimized (1:8) node prices, which fit every plan up to 32 vCPUs exactly; each standby node bills at its primary's price. Traffic to and from managed databases does not count against DigitalOcean bandwidth billing, so selected network is not charged. Standard Edition (a 1 GiB single node is USD 13 plus 10 GiB at 0.215, 15.15/month) is not selected. Whether standby nodes also bill storage is not stated. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: The largest plan has 256 GiB and storage reaches 20 TB ([https://www.digitalocean.com/blog/larger-plan-sizes-for-mysql-and-postgresql](https://www.digitalocean.com/blog/larger-plan-sizes-for-mysql-and-postgresql)); this model's rates fit plans up to 32 vCPUs. * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. List prices read: 2026-10-22. Model: `plan-6ab1eebb3f2c2d122a724e244e3f16435bacdfd3` / `2026-10-22.planning.2`. Scenario: `planning-example`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [DigitalOcean Managed Databases pricing](https://www.digitalocean.com/pricing/managed-databases), [DigitalOcean Managed Databases pricing](https://docs.digitalocean.com/products/databases/postgresql/details/pricing/). ## On Google Cloud ### Cloud SQL for MySQL | Operation | Area | Support | Depth | Notes | | - | - | - | - | - | | AWS integration SQL: LOAD DATA FROM S3 / SELECT INTO OUTFILE S3, mysql.lambda\_async, mysql.rds\_\* procedures | SQL functions | Out of scope | Full surface | RDS MySQL extension procedures with no counterpart on vanilla MySQL; a query calling them fails | | MySQL client/server protocol (application SQL) | Wire protocol | Supported | Common | same MySQL engine; application SQL is unchanged | #### 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 Cloud Adapter deployment and translates snapshots, restores, replicas, failover, and configuration changes to the Cloud SQL admin API. ![Before: on AWS your app talks to an RDS for MySQL instance over the MySQL protocol. After: on Google Cloud the same app with the same driver talks over the same MySQL protocol to a native Cloud SQL for MySQL instance, without Tensor9 proxying database traffic.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjAwIiB2aWV3Qm94PSIwIDAgODM2IDIwMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJCZWZvcmU6IG9uIEFXUyB5b3VyIGFwcCB0YWxrcyB0byBhbiBSRFMgZm9yIE15U1FMIGluc3RhbmNlIG92ZXIgdGhlIE15U1FMIHByb3RvY29sLiBBZnRlcjogb24gR29vZ2xlIENsb3VkIHRoZSBzYW1lIGFwcCB3aXRoIHRoZSBzYW1lIGRyaXZlciB0YWxrcyBvdmVyIHRoZSBzYW1lIE15U1FMIHByb3RvY29sIHRvIGEgbmF0aXZlIENsb3VkIFNRTCBmb3IgTXlTUUwgaW5zdGFuY2UsIHdpdGhvdXQgVGVuc29yOSBwcm94eWluZyBkYXRhYmFzZSB0cmFmZmljLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJjc3ExaCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6Izk0YTNiOCIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iMTYiIHk9IjQwIiB3aWR0aD0iMzgwIiBoZWlnaHQ9IjE0MCIgcng9IjE0IiBzdHJva2Utd2lkdGg9IjEuNCIgc3Ryb2tlLWRhc2hhcnJheT0iNSA1IiBzdHlsZT0iZmlsbDojZjhmYWZjO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjMyIiB5PSI2MiIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjgiPk9OIEFXUyBUT0RBWTwvdGV4dD4KPHJlY3QgeD0iMzYiIHk9Ijg0IiB3aWR0aD0iMTUwIiBoZWlnaHQ9IjU4IiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjExMSIgeT0iMTEwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYSI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjExMSIgeT0iMTI3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+TXlTUUwgZHJpdmVyPC90ZXh0Pgo8bGluZSB4MT0iMTg2IiB5MT0iMTEzIiB4Mj0iMjIwIiB5Mj0iMTEzIiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLWVuZD0idXJsKCNjc3ExaCkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8dGV4dCB4PSIyMDMiIHk9IjEwNSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZTo4LjVweCI+TXlTUUw8L3RleHQ+CjxyZWN0IHg9IjIyMiIgeT0iODQiIHdpZHRoPSIxNTgiIGhlaWdodD0iNTgiIHJ4PSIxMSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iMzAxIiB5PSIxMDgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTJweCI+UkRTIGZvciBNeVNRTDwvdGV4dD4KPHRleHQgeD0iMzAxIiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjMzM0MTU1Ij5hd3NfZGJfaW5zdGFuY2U8L3RleHQ+CjxyZWN0IHg9IjQ0MCIgeT0iNDAiIHdpZHRoPSIzODAiIGhlaWdodD0iMTQwIiByeD0iMTQiIHN0cm9rZS13aWR0aD0iMS40IiBzdHJva2UtZGFzaGFycmF5PSI1IDUiIHN0eWxlPSJmaWxsOiNmOGZhZmM7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iNDU2IiB5PSI2MiIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjg7IGZpbGw6IzA0Nzg1NyI+T04gR09PR0xFIENMT1VEPC90ZXh0Pgo8cmVjdCB4PSI0NTYiIHk9Ijg0IiB3aWR0aD0iMTMwIiBoZWlnaHQ9IjU4IiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjUyMSIgeT0iMTEwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjEycHgiPllvdXIgYXBwPC90ZXh0Pgo8dGV4dCB4PSI1MjEiIHk9IjEyNyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij5zYW1lIGRyaXZlcjwvdGV4dD4KPGxpbmUgeDE9IjU4NiIgeTE9IjExMyIgeDI9IjYyMCIgeTI9IjExMyIgc3Ryb2tlLXdpZHRoPSIxLjgiIG1hcmtlci1lbmQ9InVybCgjY3NxMWgpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iNjAzIiB5PSIxMDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmb250LXNpemU6OC41cHgiPk15U1FMPC90ZXh0Pgo8cmVjdCB4PSI2MjIiIHk9Ijg0IiB3aWR0aD0iMTg0IiBoZWlnaHQ9IjU4IiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjcxNCIgeT0iMTA4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC1zaXplOjExLjVweCI+Q2xvdWQgU1FMIGZvciBNeVNRTDwvdGV4dD4KPHRleHQgeD0iNzE0IiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPk15U1FMIGVuZ2luZSDCtyBuYXRpdmU8L3RleHQ+Cjwvc3ZnPg==) ![Before: on AWS your app talks to an RDS for MySQL instance over the MySQL protocol. After: on Google Cloud the same app with the same driver talks over the same MySQL protocol to a native Cloud SQL for MySQL instance, without Tensor9 proxying database traffic.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjAwIiB2aWV3Qm94PSIwIDAgODM2IDIwMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJCZWZvcmU6IG9uIEFXUyB5b3VyIGFwcCB0YWxrcyB0byBhbiBSRFMgZm9yIE15U1FMIGluc3RhbmNlIG92ZXIgdGhlIE15U1FMIHByb3RvY29sLiBBZnRlcjogb24gR29vZ2xlIENsb3VkIHRoZSBzYW1lIGFwcCB3aXRoIHRoZSBzYW1lIGRyaXZlciB0YWxrcyBvdmVyIHRoZSBzYW1lIE15U1FMIHByb3RvY29sIHRvIGEgbmF0aXZlIENsb3VkIFNRTCBmb3IgTXlTUUwgaW5zdGFuY2UsIHdpdGhvdXQgVGVuc29yOSBwcm94eWluZyBkYXRhYmFzZSB0cmFmZmljLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJjc3ExaCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6IzY0NzQ4YiIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iMTYiIHk9IjQwIiB3aWR0aD0iMzgwIiBoZWlnaHQ9IjE0MCIgcng9IjE0IiBzdHJva2Utd2lkdGg9IjEuNCIgc3Ryb2tlLWRhc2hhcnJheT0iNSA1IiBzdHlsZT0iZmlsbDojMGYxNzJhO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjMyIiB5PSI2MiIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGIiPk9OIEFXUyBUT0RBWTwvdGV4dD4KPHJlY3QgeD0iMzYiIHk9Ijg0IiB3aWR0aD0iMTUwIiBoZWlnaHQ9IjU4IiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjExMSIgeT0iMTEwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOSI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjExMSIgeT0iMTI3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+TXlTUUwgZHJpdmVyPC90ZXh0Pgo8bGluZSB4MT0iMTg2IiB5MT0iMTEzIiB4Mj0iMjIwIiB5Mj0iMTEzIiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLWVuZD0idXJsKCNjc3ExaCkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8dGV4dCB4PSIyMDMiIHk9IjEwNSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZTo4LjVweCI+TXlTUUw8L3RleHQ+CjxyZWN0IHg9IjIyMiIgeT0iODQiIHdpZHRoPSIxNTgiIGhlaWdodD0iNTgiIHJ4PSIxMSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iMzAxIiB5PSIxMDgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTJweCI+UkRTIGZvciBNeVNRTDwvdGV4dD4KPHRleHQgeD0iMzAxIiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjY2JkNWUxIj5hd3NfZGJfaW5zdGFuY2U8L3RleHQ+CjxyZWN0IHg9IjQ0MCIgeT0iNDAiIHdpZHRoPSIzODAiIGhlaWdodD0iMTQwIiByeD0iMTQiIHN0cm9rZS13aWR0aD0iMS40IiBzdHJva2UtZGFzaGFycmF5PSI1IDUiIHN0eWxlPSJmaWxsOiMwZjE3MmE7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iNDU2IiB5PSI2MiIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGI7IGZpbGw6IzZlZTdiNyI+T04gR09PR0xFIENMT1VEPC90ZXh0Pgo8cmVjdCB4PSI0NTYiIHk9Ijg0IiB3aWR0aD0iMTMwIiBoZWlnaHQ9IjU4IiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjUyMSIgeT0iMTEwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjEycHgiPllvdXIgYXBwPC90ZXh0Pgo8dGV4dCB4PSI1MjEiIHk9IjEyNyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij5zYW1lIGRyaXZlcjwvdGV4dD4KPGxpbmUgeDE9IjU4NiIgeTE9IjExMyIgeDI9IjYyMCIgeTI9IjExMyIgc3Ryb2tlLXdpZHRoPSIxLjgiIG1hcmtlci1lbmQ9InVybCgjY3NxMWgpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iNjAzIiB5PSIxMDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmb250LXNpemU6OC41cHgiPk15U1FMPC90ZXh0Pgo8cmVjdCB4PSI2MjIiIHk9Ijg0IiB3aWR0aD0iMTg0IiBoZWlnaHQ9IjU4IiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjcxNCIgeT0iMTA4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC1zaXplOjExLjVweCI+Q2xvdWQgU1FMIGZvciBNeVNRTDwvdGV4dD4KPHRleHQgeD0iNzE0IiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPk15U1FMIGVuZ2luZSDCtyBuYXRpdmU8L3RleHQ+Cjwvc3ZnPg==) Your app keeps its driver and speaks the MySQL protocol straight to the database, no proxy in between. #### 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. ![A Cloud SQL primary in Region A replicates asynchronously to an in-region read replica and to a cross-region read replica in Region B. The cross-region replica is promotable for regional migration or disaster recovery. Up to seven read replicas per primary, in-region or cross-region.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjEwIiB2aWV3Qm94PSIwIDAgODM2IDIxMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJBIENsb3VkIFNRTCBwcmltYXJ5IGluIFJlZ2lvbiBBIHJlcGxpY2F0ZXMgYXN5bmNocm9ub3VzbHkgdG8gYW4gaW4tcmVnaW9uIHJlYWQgcmVwbGljYSBhbmQgdG8gYSBjcm9zcy1yZWdpb24gcmVhZCByZXBsaWNhIGluIFJlZ2lvbiBCLiBUaGUgY3Jvc3MtcmVnaW9uIHJlcGxpY2EgaXMgcHJvbW90YWJsZSBmb3IgcmVnaW9uYWwgbWlncmF0aW9uIG9yIGRpc2FzdGVyIHJlY292ZXJ5LiBVcCB0byBzZXZlbiByZWFkIHJlcGxpY2FzIHBlciBwcmltYXJ5LCBpbi1yZWdpb24gb3IgY3Jvc3MtcmVnaW9uLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJjc3EyaCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6Izk0YTNiOCIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iNDAiIHk9Ijc4IiB3aWR0aD0iMjAwIiBoZWlnaHQ9IjU2IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjE0MCIgeT0iMTA0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC1zaXplOjEycHgiPkNsb3VkIFNRTCBwcmltYXJ5PC90ZXh0Pgo8dGV4dCB4PSIxNDAiIHk9IjEyMSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+d3JpdGVyIMK3IFJlZ2lvbiBBPC90ZXh0Pgo8bGluZSB4MT0iMjQwIiB5MT0iOTgiIHgyPSI0ODIiIHkyPSI3MCIgc3Ryb2tlLXdpZHRoPSIxLjYiIG1hcmtlci1lbmQ9InVybCgjY3NxMmgpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iMzYwIiB5PSI3MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZTo5cHgiPmFzeW5jPC90ZXh0Pgo8bGluZSB4MT0iMjQwIiB5MT0iMTE2IiB4Mj0iNDgyIiB5Mj0iMTQ2IiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNjc3EyaCkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8dGV4dCB4PSIzNTYiIHk9IjE0NiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZTo5cHgiPmNyb3NzLXJlZ2lvbiBhc3luYzwvdGV4dD4KPHJlY3QgeD0iNDg2IiB5PSI0NCIgd2lkdGg9IjMxMCIgaGVpZ2h0PSI1MCIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSI2NDEiIHk9IjY2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjExLjVweCI+UmVhZCByZXBsaWNhIMK3IFJlZ2lvbiBBPC90ZXh0Pgo8dGV4dCB4PSI2NDEiIHk9IjgzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+aW4tcmVnaW9uIHJlYWQgc2NhbGUtb3V0PC90ZXh0Pgo8cmVjdCB4PSI0ODYiIHk9IjEyMCIgd2lkdGg9IjMxMCIgaGVpZ2h0PSI1MCIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNiIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI2NDEiIHk9IjE0MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC1zaXplOjExLjVweDtmb250LXdlaWdodDo3MDAiPlJlYWQgcmVwbGljYSDCtyBSZWdpb24gQjwvdGV4dD4KPHRleHQgeD0iNjQxIiB5PSIxNTkiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiMwNDc4NTciPmNyb3NzLXJlZ2lvbiwgcHJvbW90YWJsZSBmb3IgRFI8L3RleHQ+CjxyZWN0IHg9IjQwIiB5PSIxODAiIHdpZHRoPSI3NTYiIGhlaWdodD0iMjQiIHJ4PSI4IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6I2E3ZjNkMCIvPgo8dGV4dCB4PSI0MTgiIHk9IjE5NiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+VXAgdG8gc2V2ZW4gcmVhZCByZXBsaWNhcyBwZXIgcHJpbWFyeSwgaW4tcmVnaW9uIG9yIGNyb3NzLXJlZ2lvbjwvdGV4dD4KPC9zdmc+) ![A Cloud SQL primary in Region A replicates asynchronously to an in-region read replica and to a cross-region read replica in Region B. The cross-region replica is promotable for regional migration or disaster recovery. Up to seven read replicas per primary, in-region or cross-region.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjEwIiB2aWV3Qm94PSIwIDAgODM2IDIxMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJBIENsb3VkIFNRTCBwcmltYXJ5IGluIFJlZ2lvbiBBIHJlcGxpY2F0ZXMgYXN5bmNocm9ub3VzbHkgdG8gYW4gaW4tcmVnaW9uIHJlYWQgcmVwbGljYSBhbmQgdG8gYSBjcm9zcy1yZWdpb24gcmVhZCByZXBsaWNhIGluIFJlZ2lvbiBCLiBUaGUgY3Jvc3MtcmVnaW9uIHJlcGxpY2EgaXMgcHJvbW90YWJsZSBmb3IgcmVnaW9uYWwgbWlncmF0aW9uIG9yIGRpc2FzdGVyIHJlY292ZXJ5LiBVcCB0byBzZXZlbiByZWFkIHJlcGxpY2FzIHBlciBwcmltYXJ5LCBpbi1yZWdpb24gb3IgY3Jvc3MtcmVnaW9uLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJjc3EyaCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6IzY0NzQ4YiIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iNDAiIHk9Ijc4IiB3aWR0aD0iMjAwIiBoZWlnaHQ9IjU2IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjE0MCIgeT0iMTA0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC1zaXplOjEycHgiPkNsb3VkIFNRTCBwcmltYXJ5PC90ZXh0Pgo8dGV4dCB4PSIxNDAiIHk9IjEyMSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+d3JpdGVyIMK3IFJlZ2lvbiBBPC90ZXh0Pgo8bGluZSB4MT0iMjQwIiB5MT0iOTgiIHgyPSI0ODIiIHkyPSI3MCIgc3Ryb2tlLXdpZHRoPSIxLjYiIG1hcmtlci1lbmQ9InVybCgjY3NxMmgpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iMzYwIiB5PSI3MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZTo5cHgiPmFzeW5jPC90ZXh0Pgo8bGluZSB4MT0iMjQwIiB5MT0iMTE2IiB4Mj0iNDgyIiB5Mj0iMTQ2IiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNjc3EyaCkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8dGV4dCB4PSIzNTYiIHk9IjE0NiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZTo5cHgiPmNyb3NzLXJlZ2lvbiBhc3luYzwvdGV4dD4KPHJlY3QgeD0iNDg2IiB5PSI0NCIgd2lkdGg9IjMxMCIgaGVpZ2h0PSI1MCIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSI2NDEiIHk9IjY2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjExLjVweCI+UmVhZCByZXBsaWNhIMK3IFJlZ2lvbiBBPC90ZXh0Pgo8dGV4dCB4PSI2NDEiIHk9IjgzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+aW4tcmVnaW9uIHJlYWQgc2NhbGUtb3V0PC90ZXh0Pgo8cmVjdCB4PSI0ODYiIHk9IjEyMCIgd2lkdGg9IjMxMCIgaGVpZ2h0PSI1MCIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNiIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSI2NDEiIHk9IjE0MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC1zaXplOjExLjVweDtmb250LXdlaWdodDo3MDAiPlJlYWQgcmVwbGljYSDCtyBSZWdpb24gQjwvdGV4dD4KPHRleHQgeD0iNjQxIiB5PSIxNTkiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiM2ZWU3YjciPmNyb3NzLXJlZ2lvbiwgcHJvbW90YWJsZSBmb3IgRFI8L3RleHQ+CjxyZWN0IHg9IjQwIiB5PSIxODAiIHdpZHRoPSI3NTYiIGhlaWdodD0iMjQiIHJ4PSI4IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI0MTgiIHk9IjE5NiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+VXAgdG8gc2V2ZW4gcmVhZCByZXBsaWNhcyBwZXIgcHJpbWFyeSwgaW4tcmVnaW9uIG9yIGNyb3NzLXJlZ2lvbjwvdGV4dD4KPC9zdmc+) A primary feeds up to seven read replicas in its region or others; a cross-region replica can be promoted. #### 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. ![A Cloud SQL HA regional instance has a primary in zone A and a synchronous standby in zone B of the same region, replicated at the block level over a regional persistent disk. Failover loses no committed write (RPO 0); Enterprise Plus comes with a 99.99 percent availability SLA.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTc2IiB2aWV3Qm94PSIwIDAgODM2IDE3NiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJBIENsb3VkIFNRTCBIQSByZWdpb25hbCBpbnN0YW5jZSBoYXMgYSBwcmltYXJ5IGluIHpvbmUgQSBhbmQgYSBzeW5jaHJvbm91cyBzdGFuZGJ5IGluIHpvbmUgQiBvZiB0aGUgc2FtZSByZWdpb24sIHJlcGxpY2F0ZWQgYXQgdGhlIGJsb2NrIGxldmVsIG92ZXIgYSByZWdpb25hbCBwZXJzaXN0ZW50IGRpc2suIEZhaWxvdmVyIGxvc2VzIG5vIGNvbW1pdHRlZCB3cml0ZSAoUlBPIDApOyBFbnRlcnByaXNlIFBsdXMgY29tZXMgd2l0aCBhIDk5Ljk5IHBlcmNlbnQgYXZhaWxhYmlsaXR5IFNMQS4iPjxzdHlsZT50ZXh0e2ZvbnQtZmFtaWx5OkludGVyLC1hcHBsZS1zeXN0ZW0sQmxpbmtNYWNTeXN0ZW1Gb250LCdTZWdvZSBVSScsUm9ib3RvLCdIZWx2ZXRpY2EgTmV1ZScsQXJpYWwsc2Fucy1zZXJpZjtmaWxsOiMzMzQxNTV9PC9zdHlsZT4KPGRlZnM+PG1hcmtlciBpZD0iY3NxM2giIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjYuNSIgbWFya2VySGVpZ2h0PSI2LjUiIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiMwNDc4NTciLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjQwIiB5PSIzNCIgd2lkdGg9Ijc1NiIgaGVpZ2h0PSIxMDQiIHJ4PSIxMyIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0cm9rZS1kYXNoYXJyYXk9IjUgNSIgc3R5bGU9ImZpbGw6I2Y4ZmFmYztzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSI2MCIgeT0iNTYiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4OyBmaWxsOiMwNDc4NTciPlJFR0lPTiDCtyBIQSBSRUdJT05BTCBJTlNUQU5DRTwvdGV4dD4KPHJlY3QgeD0iNjYiIHk9IjY4IiB3aWR0aD0iMjkwIiBoZWlnaHQ9IjU2IiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS42IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjIxMSIgeT0iOTIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXNpemU6MTJweCI+UHJpbWFyeSDCtyB6b25lIEE8L3RleHQ+Cjx0ZXh0IHg9IjIxMSIgeT0iMTEwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij53cml0ZXI8L3RleHQ+CjxsaW5lIHgxPSIzNTYiIHkxPSI5NiIgeDI9IjQ3OCIgeTI9Ijk2IiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLWVuZD0idXJsKCNjc3EzaCkiIHN0eWxlPSJzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI0MjkuMCIgeT0iODgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmb250LXNpemU6OXB4O2ZpbGw6IzA0Nzg1NyI+c3luY2hyb25vdXM8L3RleHQ+CjxyZWN0IHg9IjQ4MiIgeT0iNjgiIHdpZHRoPSIyOTAiIGhlaWdodD0iNTYiIHJ4PSIxMSIgc3Ryb2tlLXdpZHRoPSIxLjYiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNhN2YzZDAiLz4KPHRleHQgeD0iNjI3IiB5PSI5MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMnB4Ij5TdGFuZGJ5IMK3IHpvbmUgQjwvdGV4dD4KPHRleHQgeD0iNjI3IiB5PSIxMTAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5zeW5jaHJvbm91cyBjb3B5PC90ZXh0Pgo8dGV4dCB4PSI0MTgiIHk9IjE2MCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+Tm8gY29tbWl0dGVkIHdyaXRlIGxvc3Qgb24gZmFpbG92ZXIgKFJQTyAwKSDCtyA5OS45OSUgU0xBIG9uIEVudGVycHJpc2UgUGx1czwvdGV4dD4KPC9zdmc+) ![A Cloud SQL HA regional instance has a primary in zone A and a synchronous standby in zone B of the same region, replicated at the block level over a regional persistent disk. Failover loses no committed write (RPO 0); Enterprise Plus comes with a 99.99 percent availability SLA.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTc2IiB2aWV3Qm94PSIwIDAgODM2IDE3NiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJBIENsb3VkIFNRTCBIQSByZWdpb25hbCBpbnN0YW5jZSBoYXMgYSBwcmltYXJ5IGluIHpvbmUgQSBhbmQgYSBzeW5jaHJvbm91cyBzdGFuZGJ5IGluIHpvbmUgQiBvZiB0aGUgc2FtZSByZWdpb24sIHJlcGxpY2F0ZWQgYXQgdGhlIGJsb2NrIGxldmVsIG92ZXIgYSByZWdpb25hbCBwZXJzaXN0ZW50IGRpc2suIEZhaWxvdmVyIGxvc2VzIG5vIGNvbW1pdHRlZCB3cml0ZSAoUlBPIDApOyBFbnRlcnByaXNlIFBsdXMgY29tZXMgd2l0aCBhIDk5Ljk5IHBlcmNlbnQgYXZhaWxhYmlsaXR5IFNMQS4iPjxzdHlsZT50ZXh0e2ZvbnQtZmFtaWx5OkludGVyLC1hcHBsZS1zeXN0ZW0sQmxpbmtNYWNTeXN0ZW1Gb250LCdTZWdvZSBVSScsUm9ib3RvLCdIZWx2ZXRpY2EgTmV1ZScsQXJpYWwsc2Fucy1zZXJpZjtmaWxsOiNjYmQ1ZTF9PC9zdHlsZT4KPGRlZnM+PG1hcmtlciBpZD0iY3NxM2giIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjYuNSIgbWFya2VySGVpZ2h0PSI2LjUiIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM2ZWU3YjciLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjQwIiB5PSIzNCIgd2lkdGg9Ijc1NiIgaGVpZ2h0PSIxMDQiIHJ4PSIxMyIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0cm9rZS1kYXNoYXJyYXk9IjUgNSIgc3R5bGU9ImZpbGw6IzBmMTcyYTtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSI2MCIgeT0iNTYiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiM2ZWU3YjciPlJFR0lPTiDCtyBIQSBSRUdJT05BTCBJTlNUQU5DRTwvdGV4dD4KPHJlY3QgeD0iNjYiIHk9IjY4IiB3aWR0aD0iMjkwIiBoZWlnaHQ9IjU2IiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS42IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjIxMSIgeT0iOTIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXNpemU6MTJweCI+UHJpbWFyeSDCtyB6b25lIEE8L3RleHQ+Cjx0ZXh0IHg9IjIxMSIgeT0iMTEwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij53cml0ZXI8L3RleHQ+CjxsaW5lIHgxPSIzNTYiIHkxPSI5NiIgeDI9IjQ3OCIgeTI9Ijk2IiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLWVuZD0idXJsKCNjc3EzaCkiIHN0eWxlPSJzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSI0MjkuMCIgeT0iODgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmb250LXNpemU6OXB4O2ZpbGw6IzZlZTdiNyI+c3luY2hyb25vdXM8L3RleHQ+CjxyZWN0IHg9IjQ4MiIgeT0iNjgiIHdpZHRoPSIyOTAiIGhlaWdodD0iNTYiIHJ4PSIxMSIgc3Ryb2tlLXdpZHRoPSIxLjYiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iNjI3IiB5PSI5MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMnB4Ij5TdGFuZGJ5IMK3IHpvbmUgQjwvdGV4dD4KPHRleHQgeD0iNjI3IiB5PSIxMTAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5zeW5jaHJvbm91cyBjb3B5PC90ZXh0Pgo8dGV4dCB4PSI0MTgiIHk9IjE2MCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+Tm8gY29tbWl0dGVkIHdyaXRlIGxvc3Qgb24gZmFpbG92ZXIgKFJQTyAwKSDCtyA5OS45OSUgU0xBIG9uIEVudGVycHJpc2UgUGx1czwvdGV4dD4KPC9zdmc+) A synchronous standby in a second zone means failover loses no committed write. #### Parameters as database flags Cloud SQL sets MySQL parameters such as `max_connections` and `long_query_time` as per-instance database flags. The reusable RDS parameter-group object has no counterpart. A declared `aws_db_parameter_group` is not kept: the deployment removes it and reports a warning, so the instance starts with Cloud SQL's default values. Set the flags you need on each instance. Later parameter changes made through the RDS API, such as `ModifyDBParameterGroup`, are translated to database flags where they map. Check the selected MySQL version and Cloud SQL's allowed flag values; parameters outside that list cannot be set. ![An RDS parameter group is not kept to Cloud SQL. The instance starts with Cloud SQL's default database flags, and you set the flags you need on each instance.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjEwIiB2aWV3Qm94PSIwIDAgODM2IDIxMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJBbiBSRFMgcGFyYW1ldGVyIGdyb3VwIGlzIG5vdCBrZXB0IHRvIENsb3VkIFNRTC4gVGhlIGluc3RhbmNlIHN0YXJ0cyB3aXRoIENsb3VkIFNRTCdzIGRlZmF1bHQgZGF0YWJhc2UgZmxhZ3MsIGFuZCB5b3Ugc2V0IHRoZSBmbGFncyB5b3UgbmVlZCBvbiBlYWNoIGluc3RhbmNlLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJjc3E0aCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6Izk0YTNiOCIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iNDQiIHk9IjQwIiB3aWR0aD0iMzAwIiBoZWlnaHQ9IjEyMiIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNCIgc3R5bGU9ImZpbGw6I2Y4ZmFmYztzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSIxOTQiIHk9IjYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjEycHgiPlJEUyBwYXJhbWV0ZXIgZ3JvdXA8L3RleHQ+Cjx0ZXh0IHg9IjYwIiB5PSI4OCIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICMzMzQxNTU7IGZvbnQtc2l6ZToxMHB4Ij5tYXhfY29ubmVjdGlvbnM8L3RleHQ+Cjx0ZXh0IHg9IjYwIiB5PSIxMTAiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjMzM0MTU1OyBmb250LXNpemU6MTBweCI+aW5ub2RiX2J1ZmZlcl9wb29sX3NpemU8L3RleHQ+Cjx0ZXh0IHg9IjYwIiB5PSIxMzIiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjMzM0MTU1OyBmb250LXNpemU6MTBweCI+bG9uZ19xdWVyeV90aW1lPC90ZXh0Pgo8bGluZSB4MT0iMzQ4IiB5MT0iMTAwIiB4Mj0iNDg2IiB5Mj0iMTAwIiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLWVuZD0idXJsKCNjc3E0aCkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8dGV4dCB4PSI0MTciIHk9IjkyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNiNDUzMDk7IGZvbnQtd2VpZ2h0OjcwMCI+bm90IGNhcnJpZWQ8L3RleHQ+CjxyZWN0IHg9IjQ5MCIgeT0iNDAiIHdpZHRoPSIzMDYiIGhlaWdodD0iMTIyIiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS42IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjY0MyIgeT0iNjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXNpemU6MTJweCI+Q2xvdWQgU1FMIGRhdGFiYXNlIGZsYWdzPC90ZXh0Pgo8dGV4dCB4PSI1MDYiIHk9Ijg4IiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzMzNDE1NTsgZm9udC1zaXplOjEwcHg7ZmlsbDojMDQ3ODU3Ij5zdGFydCBhdCBDbG91ZCBTUUwgZGVmYXVsdHM8L3RleHQ+Cjx0ZXh0IHg9IjUwNiIgeT0iMTEwIiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzMzNDE1NTsgZm9udC1zaXplOjEwcHg7ZmlsbDojMDQ3ODU3Ij55b3Ugc2V0IGVhY2ggZmxhZzwvdGV4dD4KPHRleHQgeD0iNTA2IiB5PSIxMzIiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjMzM0MTU1OyBmb250LXNpemU6MTBweDtmaWxsOiMwNDc4NTciPnBlciBpbnN0YW5jZTwvdGV4dD4KPHJlY3QgeD0iNDQiIHk9IjE3NCIgd2lkdGg9Ijc1MiIgaGVpZ2h0PSIzMCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS40IiBzdHlsZT0iZmlsbDojZmZmYmViO3N0cm9rZTojZmRlNjhhIi8+Cjx0ZXh0IHg9IjQyMCIgeT0iMTkzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNiNDUzMDkiPlRoZSBkZXBsb3ltZW50IHJlbW92ZXMgdGhlIHBhcmFtZXRlciBncm91cCBhbmQgcmVwb3J0cyBhIHdhcm5pbmc8L3RleHQ+Cjwvc3ZnPg==) ![An RDS parameter group is not kept to Cloud SQL. The instance starts with Cloud SQL's default database flags, and you set the flags you need on each instance.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjEwIiB2aWV3Qm94PSIwIDAgODM2IDIxMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJBbiBSRFMgcGFyYW1ldGVyIGdyb3VwIGlzIG5vdCBrZXB0IHRvIENsb3VkIFNRTC4gVGhlIGluc3RhbmNlIHN0YXJ0cyB3aXRoIENsb3VkIFNRTCdzIGRlZmF1bHQgZGF0YWJhc2UgZmxhZ3MsIGFuZCB5b3Ugc2V0IHRoZSBmbGFncyB5b3UgbmVlZCBvbiBlYWNoIGluc3RhbmNlLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJjc3E0aCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6IzY0NzQ4YiIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iNDQiIHk9IjQwIiB3aWR0aD0iMzAwIiBoZWlnaHQ9IjEyMiIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNCIgc3R5bGU9ImZpbGw6IzBmMTcyYTtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSIxOTQiIHk9IjYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjEycHgiPlJEUyBwYXJhbWV0ZXIgZ3JvdXA8L3RleHQ+Cjx0ZXh0IHg9IjYwIiB5PSI4OCIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICNjYmQ1ZTE7IGZvbnQtc2l6ZToxMHB4Ij5tYXhfY29ubmVjdGlvbnM8L3RleHQ+Cjx0ZXh0IHg9IjYwIiB5PSIxMTAiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjY2JkNWUxOyBmb250LXNpemU6MTBweCI+aW5ub2RiX2J1ZmZlcl9wb29sX3NpemU8L3RleHQ+Cjx0ZXh0IHg9IjYwIiB5PSIxMzIiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjY2JkNWUxOyBmb250LXNpemU6MTBweCI+bG9uZ19xdWVyeV90aW1lPC90ZXh0Pgo8bGluZSB4MT0iMzQ4IiB5MT0iMTAwIiB4Mj0iNDg2IiB5Mj0iMTAwIiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLWVuZD0idXJsKCNjc3E0aCkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8dGV4dCB4PSI0MTciIHk9IjkyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmYmJmMjQ7IGZvbnQtd2VpZ2h0OjcwMCI+bm90IGNhcnJpZWQ8L3RleHQ+CjxyZWN0IHg9IjQ5MCIgeT0iNDAiIHdpZHRoPSIzMDYiIGhlaWdodD0iMTIyIiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS42IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjY0MyIgeT0iNjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXNpemU6MTJweCI+Q2xvdWQgU1FMIGRhdGFiYXNlIGZsYWdzPC90ZXh0Pgo8dGV4dCB4PSI1MDYiIHk9Ijg4IiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogI2NiZDVlMTsgZm9udC1zaXplOjEwcHg7ZmlsbDojNmVlN2I3Ij5zdGFydCBhdCBDbG91ZCBTUUwgZGVmYXVsdHM8L3RleHQ+Cjx0ZXh0IHg9IjUwNiIgeT0iMTEwIiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogI2NiZDVlMTsgZm9udC1zaXplOjEwcHg7ZmlsbDojNmVlN2I3Ij55b3Ugc2V0IGVhY2ggZmxhZzwvdGV4dD4KPHRleHQgeD0iNTA2IiB5PSIxMzIiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjY2JkNWUxOyBmb250LXNpemU6MTBweDtmaWxsOiM2ZWU3YjciPnBlciBpbnN0YW5jZTwvdGV4dD4KPHJlY3QgeD0iNDQiIHk9IjE3NCIgd2lkdGg9Ijc1MiIgaGVpZ2h0PSIzMCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS40IiBzdHlsZT0iZmlsbDojNDIyMDA2O3N0cm9rZTojOTI0MDBlIi8+Cjx0ZXh0IHg9IjQyMCIgeT0iMTkzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmYmJmMjQiPlRoZSBkZXBsb3ltZW50IHJlbW92ZXMgdGhlIHBhcmFtZXRlciBncm91cCBhbmQgcmVwb3J0cyBhIHdhcm5pbmc8L3RleHQ+Cjwvc3ZnPg==) The parameter group is removed with a warning; you set database flags on each instance. #### 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. ![Three RDS control-plane features map to Cloud SQL: RDS Proxy connection pooling to Cloud SQL Managed Connection Pooling on Enterprise Plus, RDS IAM database authentication to Cloud SQL IAM database authentication, and a KMS customer key to a CMEK in Cloud KMS.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjA4IiB2aWV3Qm94PSIwIDAgODM2IDIwOCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaHJlZSBSRFMgY29udHJvbC1wbGFuZSBmZWF0dXJlcyBtYXAgdG8gQ2xvdWQgU1FMOiBSRFMgUHJveHkgY29ubmVjdGlvbiBwb29saW5nIHRvIENsb3VkIFNRTCBNYW5hZ2VkIENvbm5lY3Rpb24gUG9vbGluZyBvbiBFbnRlcnByaXNlIFBsdXMsIFJEUyBJQU0gZGF0YWJhc2UgYXV0aGVudGljYXRpb24gdG8gQ2xvdWQgU1FMIElBTSBkYXRhYmFzZSBhdXRoZW50aWNhdGlvbiwgYW5kIGEgS01TIGN1c3RvbWVyIGtleSB0byBhIENNRUsgaW4gQ2xvdWQgS01TLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJjc3E1aCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6Izk0YTNiOCIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iNDQiIHk9IjQwIiB3aWR0aD0iMzAwIiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjYwIiB5PSI2NyIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICMzMzQxNTU7IGZvbnQtc2l6ZToxMC41cHgiPlJEUyBQcm94eSAocG9vbGluZyk8L3RleHQ+CjxsaW5lIHgxPSIzNDgiIHkxPSI2MiIgeDI9IjQ3MCIgeTI9IjYyIiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLWVuZD0idXJsKCNjc3E1aCkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8cmVjdCB4PSI0NzQiIHk9IjQwIiB3aWR0aD0iMzE4IiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS42IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjQ5MCIgeT0iNjciIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTc7IGZvbnQtd2VpZ2h0OjcwMCI+TWFuYWdlZCBDb25uZWN0aW9uIFBvb2xpbmcgKEVudGVycHJpc2UgUGx1cyk8L3RleHQ+CjxyZWN0IHg9IjQ0IiB5PSI5NiIgd2lkdGg9IjMwMCIgaGVpZ2h0PSI0NCIgcng9IjEwIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSI2MCIgeT0iMTIzIiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzMzNDE1NTsgZm9udC1zaXplOjEwLjVweCI+UkRTIElBTSBkYXRhYmFzZSBhdXRoPC90ZXh0Pgo8bGluZSB4MT0iMzQ4IiB5MT0iMTE4IiB4Mj0iNDcwIiB5Mj0iMTE4IiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLWVuZD0idXJsKCNjc3E1aCkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8cmVjdCB4PSI0NzQiIHk9Ijk2IiB3aWR0aD0iMzE4IiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS42IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjQ5MCIgeT0iMTIzIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXdlaWdodDo3MDAiPkNsb3VkIFNRTCBJQU0gZGF0YWJhc2UgYXV0aGVudGljYXRpb248L3RleHQ+CjxyZWN0IHg9IjQ0IiB5PSIxNTIiIHdpZHRoPSIzMDAiIGhlaWdodD0iNDQiIHJ4PSIxMCIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iNjAiIHk9IjE3OSIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICMzMzQxNTU7IGZvbnQtc2l6ZToxMC41cHgiPktNUyBjdXN0b21lciBrZXk8L3RleHQ+CjxsaW5lIHgxPSIzNDgiIHkxPSIxNzQiIHgyPSI0NzAiIHkyPSIxNzQiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItZW5kPSJ1cmwoI2NzcTVoKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxyZWN0IHg9IjQ3NCIgeT0iMTUyIiB3aWR0aD0iMzE4IiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS42IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjQ5MCIgeT0iMTc5IiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXdlaWdodDo3MDAiPkNNRUsgdmlhIENsb3VkIEtNUzwvdGV4dD4KPC9zdmc+) ![Three RDS control-plane features map to Cloud SQL: RDS Proxy connection pooling to Cloud SQL Managed Connection Pooling on Enterprise Plus, RDS IAM database authentication to Cloud SQL IAM database authentication, and a KMS customer key to a CMEK in Cloud KMS.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjA4IiB2aWV3Qm94PSIwIDAgODM2IDIwOCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaHJlZSBSRFMgY29udHJvbC1wbGFuZSBmZWF0dXJlcyBtYXAgdG8gQ2xvdWQgU1FMOiBSRFMgUHJveHkgY29ubmVjdGlvbiBwb29saW5nIHRvIENsb3VkIFNRTCBNYW5hZ2VkIENvbm5lY3Rpb24gUG9vbGluZyBvbiBFbnRlcnByaXNlIFBsdXMsIFJEUyBJQU0gZGF0YWJhc2UgYXV0aGVudGljYXRpb24gdG8gQ2xvdWQgU1FMIElBTSBkYXRhYmFzZSBhdXRoZW50aWNhdGlvbiwgYW5kIGEgS01TIGN1c3RvbWVyIGtleSB0byBhIENNRUsgaW4gQ2xvdWQgS01TLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJjc3E1aCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6IzY0NzQ4YiIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iNDQiIHk9IjQwIiB3aWR0aD0iMzAwIiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjYwIiB5PSI2NyIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICNjYmQ1ZTE7IGZvbnQtc2l6ZToxMC41cHgiPlJEUyBQcm94eSAocG9vbGluZyk8L3RleHQ+CjxsaW5lIHgxPSIzNDgiIHkxPSI2MiIgeDI9IjQ3MCIgeTI9IjYyIiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLWVuZD0idXJsKCNjc3E1aCkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8cmVjdCB4PSI0NzQiIHk9IjQwIiB3aWR0aD0iMzE4IiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS42IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjQ5MCIgeT0iNjciIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3Yjc7IGZvbnQtd2VpZ2h0OjcwMCI+TWFuYWdlZCBDb25uZWN0aW9uIFBvb2xpbmcgKEVudGVycHJpc2UgUGx1cyk8L3RleHQ+CjxyZWN0IHg9IjQ0IiB5PSI5NiIgd2lkdGg9IjMwMCIgaGVpZ2h0PSI0NCIgcng9IjEwIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSI2MCIgeT0iMTIzIiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogI2NiZDVlMTsgZm9udC1zaXplOjEwLjVweCI+UkRTIElBTSBkYXRhYmFzZSBhdXRoPC90ZXh0Pgo8bGluZSB4MT0iMzQ4IiB5MT0iMTE4IiB4Mj0iNDcwIiB5Mj0iMTE4IiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLWVuZD0idXJsKCNjc3E1aCkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8cmVjdCB4PSI0NzQiIHk9Ijk2IiB3aWR0aD0iMzE4IiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS42IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjQ5MCIgeT0iMTIzIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXdlaWdodDo3MDAiPkNsb3VkIFNRTCBJQU0gZGF0YWJhc2UgYXV0aGVudGljYXRpb248L3RleHQ+CjxyZWN0IHg9IjQ0IiB5PSIxNTIiIHdpZHRoPSIzMDAiIGhlaWdodD0iNDQiIHJ4PSIxMCIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iNjAiIHk9IjE3OSIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICNjYmQ1ZTE7IGZvbnQtc2l6ZToxMC41cHgiPktNUyBjdXN0b21lciBrZXk8L3RleHQ+CjxsaW5lIHgxPSIzNDgiIHkxPSIxNzQiIHgyPSI0NzAiIHkyPSIxNzQiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItZW5kPSJ1cmwoI2NzcTVoKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxyZWN0IHg9IjQ3NCIgeT0iMTUyIiB3aWR0aD0iMzE4IiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS42IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjQ5MCIgeT0iMTc5IiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXdlaWdodDo3MDAiPkNNRUsgdmlhIENsb3VkIEtNUzwvdGV4dD4KPC9zdmc+) Pooling needs Enterprise Plus; IAM authentication and customer keys have direct Cloud SQL equivalents. #### Limitations Where RDS for MySQL and Cloud SQL differ * **Read replicas cap at seven per primary.** RDS allows fifteen, in the same region or across regions. Size a large read fan-out against seven before cutover. * **Managed pooling requires Enterprise Plus.** RDS Proxy pooling maps to Cloud SQL Managed Connection Pooling, which is available only on the Enterprise Plus edition. * **Declared parameter groups are dropped at deployment.** The deployment removes the group with a warning, and each instance starts with Cloud SQL's default flags. Set the flags you need per instance; parameters outside Cloud SQL's settable list cannot be set. * **MySQL versions and flags behave differently: Google chooses them.** Cloud SQL runs the versions and flags in its catalog. Move an instance that needs a version or flag Cloud SQL lacks to a supported one before cutover. * **RDS-only features are not supported.** Event subscriptions (SNS), S3 and Lambda integration SQL and Enhanced Monitoring have no counterpart; zero-ETL replicates to BigQuery through Datastream, not to 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. #### Example monthly charges This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include. ##### RDS MySQL · Primary allocated compute Feature: RDS MySQL. Estimated monthly service charges by Primary allocated compute. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. ![RDS MySQL · Primary allocated compute: monthly service charges by Primary allocated compute. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/28f05dfd65cf97a04968dea3ca78de9092ba06e741c3babafd6c90768e79d00b-light.svg) ![RDS MySQL · Primary allocated compute: monthly service charges by Primary allocated compute. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/21f599102a22e753e1b2f5cff0bdb01bdd7d5ba58f43be61dc5a17df1a7ca19f-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Primary allocated compute (vCPU-hours/month) | RDS MySQL | Target scenario | Cloud SQL for MySQL | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | Cloud SQL for MySQL (one copy) | 118.18 | 118.18 | | 0 | 0.00 | Cloud SQL for MySQL (two copies) | 236.36 | 236.36 | | 1,460 | 124.83 | Cloud SQL for MySQL (one copy) | 118.18 | -6.65 | | 1,460 | 124.83 | Cloud SQL for MySQL (two copies) | 236.36 | 111.53 | | 2,920 | 249.66 | Cloud SQL for MySQL (one copy) | 219.36 | -30.30 | | 2,920 | 249.66 | Cloud SQL for MySQL (two copies) | 438.71 | 189.05 | | 5,840 | 499.32 | Cloud SQL for MySQL (one copy) | 421.71 | -77.61 | | 5,840 | 499.32 | Cloud SQL for MySQL (two copies) | 843.42 | 344.10 | | 11,680 | 998.64 | Cloud SQL for MySQL (one copy) | 826.42 | -172.22 | | 11,680 | 998.64 | Cloud SQL for MySQL (two copies) | 1,652.85 | 654.21 | | 23,360 | 1,997.28 | Cloud SQL for MySQL (one copy) | 1,635.85 | -361.43 | | 23,360 | 1,997.28 | Cloud SQL for MySQL (two copies) | 3,271.70 | 1,274.42 | | 46,720 | 3,994.56 | Cloud SQL for MySQL (one copy) | 3,254.70 | -739.86 | | 46,720 | 3,994.56 | Cloud SQL for MySQL (two copies) | 6,509.39 | 2,514.83 | Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 vCPU-hours/month to 64 vCPU, 256 GiB memory and 100 GiB SSD at 46,720 vCPU-hours/month. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | Cloud SQL for MySQL (one copy) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Cloud SQL for MySQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Cloud SQL for MySQL (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Cloud SQL for MySQL (one copy) | Origin list price · Database reads | 0 | USD/operations | | Cloud SQL for MySQL (one copy) | Origin list price · Database writes | 0 | USD/operations | | Cloud SQL for MySQL (one copy) | Target CPU / source CPU | 1 | multiplier | | Cloud SQL for MySQL (one copy) | Target RAM / source RAM | 1 | multiplier | | Cloud SQL for MySQL (one copy) | Target disk / source disk | 1 | multiplier | | Cloud SQL for MySQL (one copy) | Target price guess · read | 0 | USD/read | | Cloud SQL for MySQL (one copy) | Target price guess · write | 0 | USD/write | | Cloud SQL for MySQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | Cloud SQL for MySQL (one copy) | Target list price · GiB-month | 0.17 | USD/GiB-month | | Cloud SQL for MySQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | Cloud SQL for MySQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Cloud SQL for MySQL (one copy) | Target list price · network GiB | 0.19 | USD/network GiB | | Cloud SQL for MySQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Cloud SQL for MySQL (one copy) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour | | Cloud SQL for MySQL (one copy) | Target list price · GiB-hour | 0.007 | USD/GiB-hour | | Cloud SQL for MySQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | Cloud SQL for MySQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | Cloud SQL for MySQL (one copy) | Target price guess · input token | 0 | USD/input token | | Cloud SQL for MySQL (one copy) | Target price guess · output token | 0 | USD/output token | | Cloud SQL for MySQL (one copy) | Target monthly base charge | 0 | USD/month | | Cloud SQL for MySQL (one copy) | Target service minimum | 9.365 | USD/month | | Cloud SQL for MySQL (one copy) | Minimum primary CPU | 2 | vCPU | | Cloud SQL for MySQL (one copy) | Minimum primary RAM | 8 | GiB | | Cloud SQL for MySQL (one copy) | Minimum primary disk | 100 | GiB | | Cloud SQL for MySQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | Cloud SQL for MySQL (one copy) | Allocated share of provisioned cost | 1 | fraction | | Cloud SQL for MySQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Cloud SQL for MySQL (one copy) | Planning peak / mean work | 2 | multiplier | | Cloud SQL for MySQL (one copy) | Planning primary CPU utilization | 0.7 | fraction | | Cloud SQL for MySQL (one copy) | Resident state reserved in RAM | 0.1 | fraction | | Cloud SQL for MySQL (one copy) | Planning disk utilization | 0.8 | fraction | | Cloud SQL for MySQL (one copy) | Maintenance and log disk reserve | 20 | GiB | | Cloud SQL for MySQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Cloud SQL for MySQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Cloud SQL for MySQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Cloud SQL for MySQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Cloud SQL for MySQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | Cloud SQL for MySQL (two copies) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Cloud SQL for MySQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Cloud SQL for MySQL (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Cloud SQL for MySQL (two copies) | Origin list price · Database reads | 0 | USD/operations | | Cloud SQL for MySQL (two copies) | Origin list price · Database writes | 0 | USD/operations | | Cloud SQL for MySQL (two copies) | Target CPU / source CPU | 1 | multiplier | | Cloud SQL for MySQL (two copies) | Target RAM / source RAM | 1 | multiplier | | Cloud SQL for MySQL (two copies) | Target disk / source disk | 1 | multiplier | | Cloud SQL for MySQL (two copies) | Target price guess · read | 0 | USD/read | | Cloud SQL for MySQL (two copies) | Target price guess · write | 0 | USD/write | | Cloud SQL for MySQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | Cloud SQL for MySQL (two copies) | Target list price · GiB-month | 0.17 | USD/GiB-month | | Cloud SQL for MySQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | Cloud SQL for MySQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Cloud SQL for MySQL (two copies) | Target list price · network GiB | 0.19 | USD/network GiB | | Cloud SQL for MySQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Cloud SQL for MySQL (two copies) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour | | Cloud SQL for MySQL (two copies) | Target list price · GiB-hour | 0.007 | USD/GiB-hour | | Cloud SQL for MySQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | Cloud SQL for MySQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | Cloud SQL for MySQL (two copies) | Target price guess · input token | 0 | USD/input token | | Cloud SQL for MySQL (two copies) | Target price guess · output token | 0 | USD/output token | | Cloud SQL for MySQL (two copies) | Target monthly base charge | 0 | USD/month | | Cloud SQL for MySQL (two copies) | Target service minimum | 9.365 | USD/month | | Cloud SQL for MySQL (two copies) | Minimum primary CPU | 2 | vCPU | | Cloud SQL for MySQL (two copies) | Minimum primary RAM | 8 | GiB | | Cloud SQL for MySQL (two copies) | Minimum primary disk | 100 | GiB | | Cloud SQL for MySQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | Cloud SQL for MySQL (two copies) | Allocated share of provisioned cost | 1 | fraction | | Cloud SQL for MySQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Cloud SQL for MySQL (two copies) | Planning peak / mean work | 2 | multiplier | | Cloud SQL for MySQL (two copies) | Planning primary CPU utilization | 0.7 | fraction | | Cloud SQL for MySQL (two copies) | Resident state reserved in RAM | 0.1 | fraction | | Cloud SQL for MySQL (two copies) | Planning disk utilization | 0.8 | fraction | | Cloud SQL for MySQL (two copies) | Maintenance and log disk reserve | 20 | GiB | | Cloud SQL for MySQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Cloud SQL for MySQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Cloud SQL for MySQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Cloud SQL for MySQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Cloud SQL for MySQL (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * CPU allocation does not imply an achieved transaction rate. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements. * Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month. * Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded. * Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied. * Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Cloud SQL Enterprise edition (MySQL) publishes separate vCPU, memory and SSD prices for zonal instances; a high-availability (regional) instance bills exactly twice each, which the standby copy reproduces. Enterprise Plus, committed-use discounts, backups (USD 0.08 per GiB-month) and idle IPv4 addresses (0.01 per hour) are not selected. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonRDS offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json) * Cloud SQL pricing: [https://cloud.google.com/sql/pricing](https://cloud.google.com/sql/pricing) Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. List prices read: 2026-10-22. Model: `plan-ee670329310268dd09cbb5242012e35e37c2b109` / `2026-10-22.planning.2`. Curve: `workload-1`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Cloud SQL pricing](https://cloud.google.com/sql/pricing). ##### RDS MySQL · Stored data Feature: RDS MySQL. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. ![RDS MySQL · Stored data: monthly service charges by Stored data. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/8f6f4fefc5eae1b103942c4ab6de46ad0a43dbd17fcee64a99297ef1d95a00af-light.svg) ![RDS MySQL · Stored data: monthly service charges by Stored data. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/e97c86951b127a36626359ed3959670c0779cadf2a4206a59e80cc49fed1182f-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Stored data (GiB-month) | RDS MySQL | Target scenario | Cloud SQL for MySQL | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | Cloud SQL for MySQL (one copy) | 118.18 | 118.18 | | 0 | 0.00 | Cloud SQL for MySQL (two copies) | 236.36 | 236.36 | | 10 | 1.15 | Cloud SQL for MySQL (one copy) | 118.18 | 117.03 | | 10 | 1.15 | Cloud SQL for MySQL (two copies) | 236.36 | 235.21 | | 100 | 11.50 | Cloud SQL for MySQL (one copy) | 126.68 | 115.18 | | 100 | 11.50 | Cloud SQL for MySQL (two copies) | 253.36 | 241.86 | | 1,000 | 115.00 | Cloud SQL for MySQL (one copy) | 317.93 | 202.93 | | 1,000 | 115.00 | Cloud SQL for MySQL (two copies) | 635.86 | 520.86 | | 10,000 | 1,150.00 | Cloud SQL for MySQL (one copy) | 2,230.43 | 1,080.43 | | 10,000 | 1,150.00 | Cloud SQL for MySQL (two copies) | 4,460.86 | 3,310.86 | | 100,000 | 11,500.00 | Cloud SQL for MySQL (one copy) | Unpriced | Unavailable | | 100,000 | 11,500.00 | Cloud SQL for MySQL (two copies) | Unpriced | Unavailable | Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 GiB-month to 2 vCPU, 8 GiB memory and 12,525 GiB SSD at 10,000 GiB-month. From 100,000 GiB-month the workload exceeds the planning range and the target is unpriced. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | Cloud SQL for MySQL (one copy) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Cloud SQL for MySQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Cloud SQL for MySQL (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Cloud SQL for MySQL (one copy) | Origin list price · Database reads | 0 | USD/operations | | Cloud SQL for MySQL (one copy) | Origin list price · Database writes | 0 | USD/operations | | Cloud SQL for MySQL (one copy) | Target CPU / source CPU | 1 | multiplier | | Cloud SQL for MySQL (one copy) | Target RAM / source RAM | 1 | multiplier | | Cloud SQL for MySQL (one copy) | Target disk / source disk | 1 | multiplier | | Cloud SQL for MySQL (one copy) | Target price guess · read | 0 | USD/read | | Cloud SQL for MySQL (one copy) | Target price guess · write | 0 | USD/write | | Cloud SQL for MySQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | Cloud SQL for MySQL (one copy) | Target list price · GiB-month | 0.17 | USD/GiB-month | | Cloud SQL for MySQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | Cloud SQL for MySQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Cloud SQL for MySQL (one copy) | Target list price · network GiB | 0.19 | USD/network GiB | | Cloud SQL for MySQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Cloud SQL for MySQL (one copy) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour | | Cloud SQL for MySQL (one copy) | Target list price · GiB-hour | 0.007 | USD/GiB-hour | | Cloud SQL for MySQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | Cloud SQL for MySQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | Cloud SQL for MySQL (one copy) | Target price guess · input token | 0 | USD/input token | | Cloud SQL for MySQL (one copy) | Target price guess · output token | 0 | USD/output token | | Cloud SQL for MySQL (one copy) | Target monthly base charge | 0 | USD/month | | Cloud SQL for MySQL (one copy) | Target service minimum | 9.365 | USD/month | | Cloud SQL for MySQL (one copy) | Minimum primary CPU | 2 | vCPU | | Cloud SQL for MySQL (one copy) | Minimum primary RAM | 8 | GiB | | Cloud SQL for MySQL (one copy) | Minimum primary disk | 100 | GiB | | Cloud SQL for MySQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | Cloud SQL for MySQL (one copy) | Allocated share of provisioned cost | 1 | fraction | | Cloud SQL for MySQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Cloud SQL for MySQL (one copy) | Planning peak / mean work | 2 | multiplier | | Cloud SQL for MySQL (one copy) | Planning primary CPU utilization | 0.7 | fraction | | Cloud SQL for MySQL (one copy) | Resident state reserved in RAM | 0.1 | fraction | | Cloud SQL for MySQL (one copy) | Planning disk utilization | 0.8 | fraction | | Cloud SQL for MySQL (one copy) | Maintenance and log disk reserve | 20 | GiB | | Cloud SQL for MySQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Cloud SQL for MySQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Cloud SQL for MySQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Cloud SQL for MySQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Cloud SQL for MySQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | Cloud SQL for MySQL (two copies) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Cloud SQL for MySQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Cloud SQL for MySQL (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Cloud SQL for MySQL (two copies) | Origin list price · Database reads | 0 | USD/operations | | Cloud SQL for MySQL (two copies) | Origin list price · Database writes | 0 | USD/operations | | Cloud SQL for MySQL (two copies) | Target CPU / source CPU | 1 | multiplier | | Cloud SQL for MySQL (two copies) | Target RAM / source RAM | 1 | multiplier | | Cloud SQL for MySQL (two copies) | Target disk / source disk | 1 | multiplier | | Cloud SQL for MySQL (two copies) | Target price guess · read | 0 | USD/read | | Cloud SQL for MySQL (two copies) | Target price guess · write | 0 | USD/write | | Cloud SQL for MySQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | Cloud SQL for MySQL (two copies) | Target list price · GiB-month | 0.17 | USD/GiB-month | | Cloud SQL for MySQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | Cloud SQL for MySQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Cloud SQL for MySQL (two copies) | Target list price · network GiB | 0.19 | USD/network GiB | | Cloud SQL for MySQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Cloud SQL for MySQL (two copies) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour | | Cloud SQL for MySQL (two copies) | Target list price · GiB-hour | 0.007 | USD/GiB-hour | | Cloud SQL for MySQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | Cloud SQL for MySQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | Cloud SQL for MySQL (two copies) | Target price guess · input token | 0 | USD/input token | | Cloud SQL for MySQL (two copies) | Target price guess · output token | 0 | USD/output token | | Cloud SQL for MySQL (two copies) | Target monthly base charge | 0 | USD/month | | Cloud SQL for MySQL (two copies) | Target service minimum | 9.365 | USD/month | | Cloud SQL for MySQL (two copies) | Minimum primary CPU | 2 | vCPU | | Cloud SQL for MySQL (two copies) | Minimum primary RAM | 8 | GiB | | Cloud SQL for MySQL (two copies) | Minimum primary disk | 100 | GiB | | Cloud SQL for MySQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | Cloud SQL for MySQL (two copies) | Allocated share of provisioned cost | 1 | fraction | | Cloud SQL for MySQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Cloud SQL for MySQL (two copies) | Planning peak / mean work | 2 | multiplier | | Cloud SQL for MySQL (two copies) | Planning primary CPU utilization | 0.7 | fraction | | Cloud SQL for MySQL (two copies) | Resident state reserved in RAM | 0.1 | fraction | | Cloud SQL for MySQL (two copies) | Planning disk utilization | 0.8 | fraction | | Cloud SQL for MySQL (two copies) | Maintenance and log disk reserve | 20 | GiB | | Cloud SQL for MySQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Cloud SQL for MySQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Cloud SQL for MySQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Cloud SQL for MySQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Cloud SQL for MySQL (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * Request meters remain at their independently authored defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements. * Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month. * Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded. * Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied. * Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Cloud SQL Enterprise edition (MySQL) publishes separate vCPU, memory and SSD prices for zonal instances; a high-availability (regional) instance bills exactly twice each, which the standby copy reproduces. Enterprise Plus, committed-use discounts, backups (USD 0.08 per GiB-month) and idle IPv4 addresses (0.01 per hour) are not selected. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonRDS offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json) * Cloud SQL pricing: [https://cloud.google.com/sql/pricing](https://cloud.google.com/sql/pricing) Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. List prices read: 2026-10-22. Model: `plan-ee670329310268dd09cbb5242012e35e37c2b109` / `2026-10-22.planning.2`. Curve: `workload-2`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Cloud SQL pricing](https://cloud.google.com/sql/pricing). ##### RDS MySQL · Database writes Feature: RDS MySQL. Estimated monthly service charges by Database writes. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. ![RDS MySQL · Database writes: monthly service charges by Database writes. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/53c146df5a9c21729a72138a6ba5604c08941497ff079fbbfe66a31df566d5b1-light.svg) ![RDS MySQL · Database writes: monthly service charges by Database writes. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/f3dd335dffa1cd1c59da5d8cbdde3fc0ab96c74de30ae79a69310234e05f69ff-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Database writes (per second) | RDS MySQL | Target scenario | Cloud SQL for MySQL | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | Cloud SQL for MySQL (one copy) | 118.18 | 118.18 | | 0 | 0.00 | Cloud SQL for MySQL (two copies) | 236.36 | 236.36 | | 1 | 0.00 | Cloud SQL for MySQL (one copy) | 118.18 | 118.18 | | 1 | 0.00 | Cloud SQL for MySQL (two copies) | 236.36 | 236.36 | | 10 | 0.00 | Cloud SQL for MySQL (one copy) | 118.18 | 118.18 | | 10 | 0.00 | Cloud SQL for MySQL (two copies) | 236.36 | 236.36 | | 100 | 0.00 | Cloud SQL for MySQL (one copy) | 118.18 | 118.18 | | 100 | 0.00 | Cloud SQL for MySQL (two copies) | 236.36 | 236.36 | | 1,000 | 0.00 | Cloud SQL for MySQL (one copy) | 118.18 | 118.18 | | 1,000 | 0.00 | Cloud SQL for MySQL (two copies) | 236.36 | 236.36 | | 10,000 | 0.00 | Cloud SQL for MySQL (one copy) | 118.18 | 118.18 | | 10,000 | 0.00 | Cloud SQL for MySQL (two copies) | 236.36 | 236.36 | Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | Cloud SQL for MySQL (one copy) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Cloud SQL for MySQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Cloud SQL for MySQL (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Cloud SQL for MySQL (one copy) | Origin list price · Database reads | 0 | USD/operations | | Cloud SQL for MySQL (one copy) | Origin list price · Database writes | 0 | USD/operations | | Cloud SQL for MySQL (one copy) | Target CPU / source CPU | 1 | multiplier | | Cloud SQL for MySQL (one copy) | Target RAM / source RAM | 1 | multiplier | | Cloud SQL for MySQL (one copy) | Target disk / source disk | 1 | multiplier | | Cloud SQL for MySQL (one copy) | Target price guess · read | 0 | USD/read | | Cloud SQL for MySQL (one copy) | Target price guess · write | 0 | USD/write | | Cloud SQL for MySQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | Cloud SQL for MySQL (one copy) | Target list price · GiB-month | 0.17 | USD/GiB-month | | Cloud SQL for MySQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | Cloud SQL for MySQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Cloud SQL for MySQL (one copy) | Target list price · network GiB | 0.19 | USD/network GiB | | Cloud SQL for MySQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Cloud SQL for MySQL (one copy) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour | | Cloud SQL for MySQL (one copy) | Target list price · GiB-hour | 0.007 | USD/GiB-hour | | Cloud SQL for MySQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | Cloud SQL for MySQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | Cloud SQL for MySQL (one copy) | Target price guess · input token | 0 | USD/input token | | Cloud SQL for MySQL (one copy) | Target price guess · output token | 0 | USD/output token | | Cloud SQL for MySQL (one copy) | Target monthly base charge | 0 | USD/month | | Cloud SQL for MySQL (one copy) | Target service minimum | 9.365 | USD/month | | Cloud SQL for MySQL (one copy) | Minimum primary CPU | 2 | vCPU | | Cloud SQL for MySQL (one copy) | Minimum primary RAM | 8 | GiB | | Cloud SQL for MySQL (one copy) | Minimum primary disk | 100 | GiB | | Cloud SQL for MySQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | Cloud SQL for MySQL (one copy) | Allocated share of provisioned cost | 1 | fraction | | Cloud SQL for MySQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Cloud SQL for MySQL (one copy) | Planning peak / mean work | 2 | multiplier | | Cloud SQL for MySQL (one copy) | Planning primary CPU utilization | 0.7 | fraction | | Cloud SQL for MySQL (one copy) | Resident state reserved in RAM | 0.1 | fraction | | Cloud SQL for MySQL (one copy) | Planning disk utilization | 0.8 | fraction | | Cloud SQL for MySQL (one copy) | Maintenance and log disk reserve | 20 | GiB | | Cloud SQL for MySQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Cloud SQL for MySQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Cloud SQL for MySQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Cloud SQL for MySQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Cloud SQL for MySQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | Cloud SQL for MySQL (two copies) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Cloud SQL for MySQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Cloud SQL for MySQL (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Cloud SQL for MySQL (two copies) | Origin list price · Database reads | 0 | USD/operations | | Cloud SQL for MySQL (two copies) | Origin list price · Database writes | 0 | USD/operations | | Cloud SQL for MySQL (two copies) | Target CPU / source CPU | 1 | multiplier | | Cloud SQL for MySQL (two copies) | Target RAM / source RAM | 1 | multiplier | | Cloud SQL for MySQL (two copies) | Target disk / source disk | 1 | multiplier | | Cloud SQL for MySQL (two copies) | Target price guess · read | 0 | USD/read | | Cloud SQL for MySQL (two copies) | Target price guess · write | 0 | USD/write | | Cloud SQL for MySQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | Cloud SQL for MySQL (two copies) | Target list price · GiB-month | 0.17 | USD/GiB-month | | Cloud SQL for MySQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | Cloud SQL for MySQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Cloud SQL for MySQL (two copies) | Target list price · network GiB | 0.19 | USD/network GiB | | Cloud SQL for MySQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Cloud SQL for MySQL (two copies) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour | | Cloud SQL for MySQL (two copies) | Target list price · GiB-hour | 0.007 | USD/GiB-hour | | Cloud SQL for MySQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | Cloud SQL for MySQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | Cloud SQL for MySQL (two copies) | Target price guess · input token | 0 | USD/input token | | Cloud SQL for MySQL (two copies) | Target price guess · output token | 0 | USD/output token | | Cloud SQL for MySQL (two copies) | Target monthly base charge | 0 | USD/month | | Cloud SQL for MySQL (two copies) | Target service minimum | 9.365 | USD/month | | Cloud SQL for MySQL (two copies) | Minimum primary CPU | 2 | vCPU | | Cloud SQL for MySQL (two copies) | Minimum primary RAM | 8 | GiB | | Cloud SQL for MySQL (two copies) | Minimum primary disk | 100 | GiB | | Cloud SQL for MySQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | Cloud SQL for MySQL (two copies) | Allocated share of provisioned cost | 1 | fraction | | Cloud SQL for MySQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Cloud SQL for MySQL (two copies) | Planning peak / mean work | 2 | multiplier | | Cloud SQL for MySQL (two copies) | Planning primary CPU utilization | 0.7 | fraction | | Cloud SQL for MySQL (two copies) | Resident state reserved in RAM | 0.1 | fraction | | Cloud SQL for MySQL (two copies) | Planning disk utilization | 0.8 | fraction | | Cloud SQL for MySQL (two copies) | Maintenance and log disk reserve | 20 | GiB | | Cloud SQL for MySQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Cloud SQL for MySQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Cloud SQL for MySQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Cloud SQL for MySQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Cloud SQL for MySQL (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * Source compute and stored data remain independent; a throughput view needs explicit workload inputs. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements. * Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month. * Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded. * Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied. * Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Cloud SQL Enterprise edition (MySQL) publishes separate vCPU, memory and SSD prices for zonal instances; a high-availability (regional) instance bills exactly twice each, which the standby copy reproduces. Enterprise Plus, committed-use discounts, backups (USD 0.08 per GiB-month) and idle IPv4 addresses (0.01 per hour) are not selected. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonRDS offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json) * Cloud SQL pricing: [https://cloud.google.com/sql/pricing](https://cloud.google.com/sql/pricing) Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. List prices read: 2026-10-22. Model: `plan-ee670329310268dd09cbb5242012e35e37c2b109` / `2026-10-22.planning.2`. Curve: `workload-3`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Cloud SQL pricing](https://cloud.google.com/sql/pricing). **RDS MySQL → Cloud SQL for MySQL: Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD. | Monthly component | USD | | - | -: | | Origin: Primary compute | 0.00 | | Origin: Primary memory | 0.00 | | Origin: Primary provisioned storage | 0.00 | | Origin: Database reads | 0.00 | | Origin: Database writes | 0.00 | | Target: Provisioned primary CPU | 60.30 | | Target: Provisioned primary RAM | 40.88 | | Target: Provisioned primary disk | 17.00 | | Target: Selected billable network | 0.00 | | Target: Independent provisioned resources | 0.00 | | Target: Independent managed resources | 0.00 | | **Origin service subtotal** | **0.00** | | **Target service subtotal** | **118.18** | Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. **Scenario assumptions** | Input | Value | Unit | | - | -: | - | | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Origin list price · Primary memory | 0 | USD/GiB-hours | | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Origin list price · Database reads | 0 | USD/operations | | Origin list price · Database writes | 0 | USD/operations | | Target CPU / source CPU | 1 | multiplier | | Target RAM / source RAM | 1 | multiplier | | Target disk / source disk | 1 | multiplier | | Target price guess · read | 0 | USD/read | | Target price guess · write | 0 | USD/write | | Target price guess · provider operation | 0 | USD/provider operation | | Target list price · GiB-month | 0.17 | USD/GiB-month | | Target price guess · published GiB | 0 | USD/published GiB | | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Target list price · network GiB | 0.19 | USD/network GiB | | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour | | Target list price · GiB-hour | 0.007 | USD/GiB-hour | | Target price guess · resource-hour | 0 | USD/resource-hour | | Target price guess · resource-month | 0 | USD/resource-month | | Target price guess · input token | 0 | USD/input token | | Target price guess · output token | 0 | USD/output token | | Target monthly base charge | 0 | USD/month | | Target service minimum | 9.365 | USD/month | | Minimum primary CPU | 2 | vCPU | | Minimum primary RAM | 8 | GiB | | Minimum primary disk | 100 | GiB | | Additional full-price standby copy | 0 | 0 or 1 | | Allocated share of provisioned cost | 1 | fraction | | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Planning peak / mean work | 2 | multiplier | | Planning primary CPU utilization | 0.7 | fraction | | Resident state reserved in RAM | 0.1 | fraction | | Planning disk utilization | 0.8 | fraction | | Maintenance and log disk reserve | 20 | GiB | | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Dependent object sink write price guess | 0.000005 | USD/write | | Primary compute | 0 | vCPU-hours | | Primary memory | 0 | GiB-hours | | Primary provisioned storage | 0 | GiB-month | | Database reads | 0 | operations | | Database writes | 0 | operations | * Translated reads: 0 operations. * Translated writes: 0 operations. * Translated resident physical data: 0 GiB-month. * Native provider operations: 0 operations. * Published payload: 0 GiB. * Delivered payload: 0 GiB. * Allocated execution CPU: 0 vCPU-hour. * Allocated execution RAM: 0 GiB-hour. * Independent resource allocation: 0 resource-hour. * Independent inventory: 0 resource-month. * Input tokens: 0 tokens. * Output tokens: 0 tokens. * Billable network: 0 GiB. * Dependent object sink retained data: 0 GiB-month. * Dependent object sink writes: 0 writes. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Cloud SQL Enterprise edition (MySQL) publishes separate vCPU, memory and SSD prices for zonal instances; a high-availability (regional) instance bills exactly twice each, which the standby copy reproduces. Enterprise Plus, committed-use discounts, backups (USD 0.08 per GiB-month) and idle IPv4 addresses (0.01 per hour) are not selected. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. List prices read: 2026-10-22. Model: `plan-ee670329310268dd09cbb5242012e35e37c2b109` / `2026-10-22.planning.2`. Scenario: `planning-example`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Cloud SQL pricing](https://cloud.google.com/sql/pricing). ## On OCI ### OCI MySQL Database (HeatWave) | Operation | Area | Support | Depth | Notes | | - | - | - | - | - | | AWS integration SQL: LOAD DATA FROM S3 / SELECT INTO OUTFILE S3, mysql.lambda\_async, mysql.rds\_\* procedures | SQL functions | Out of scope | Full surface | RDS MySQL extension procedures with no counterpart on vanilla MySQL; a query calling them fails | | MySQL client/server protocol (application SQL) | Wire protocol | Supported | Common | same MySQL engine; application SQL is unchanged | #### 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 Cloud Adapter deployment and translates snapshots, restores, replicas, failover, and configuration changes to OCI's management API. ![Before: on AWS your app talks to an RDS for MySQL instance over the MySQL protocol. After: on OCI the same app with the same driver talks over the same MySQL protocol to a native OCI MySQL HeatWave DB system, without Tensor9 proxying database traffic.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjAwIiB2aWV3Qm94PSIwIDAgODM2IDIwMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJCZWZvcmU6IG9uIEFXUyB5b3VyIGFwcCB0YWxrcyB0byBhbiBSRFMgZm9yIE15U1FMIGluc3RhbmNlIG92ZXIgdGhlIE15U1FMIHByb3RvY29sLiBBZnRlcjogb24gT0NJIHRoZSBzYW1lIGFwcCB3aXRoIHRoZSBzYW1lIGRyaXZlciB0YWxrcyBvdmVyIHRoZSBzYW1lIE15U1FMIHByb3RvY29sIHRvIGEgbmF0aXZlIE9DSSBNeVNRTCBIZWF0V2F2ZSBEQiBzeXN0ZW0sIHdpdGhvdXQgVGVuc29yOSBwcm94eWluZyBkYXRhYmFzZSB0cmFmZmljLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJvaHcxaCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6Izk0YTNiOCIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iMTYiIHk9IjQwIiB3aWR0aD0iMzgwIiBoZWlnaHQ9IjE0MCIgcng9IjE0IiBzdHJva2Utd2lkdGg9IjEuNCIgc3Ryb2tlLWRhc2hhcnJheT0iNSA1IiBzdHlsZT0iZmlsbDojZjhmYWZjO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjMyIiB5PSI2MiIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjgiPk9OIEFXUyBUT0RBWTwvdGV4dD4KPHJlY3QgeD0iMzYiIHk9Ijg0IiB3aWR0aD0iMTUwIiBoZWlnaHQ9IjU4IiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjExMSIgeT0iMTEwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYSI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjExMSIgeT0iMTI3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+TXlTUUwgZHJpdmVyPC90ZXh0Pgo8bGluZSB4MT0iMTg2IiB5MT0iMTEzIiB4Mj0iMjIwIiB5Mj0iMTEzIiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLWVuZD0idXJsKCNvaHcxaCkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8dGV4dCB4PSIyMDMiIHk9IjEwNSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZTo4LjVweCI+TXlTUUw8L3RleHQ+CjxyZWN0IHg9IjIyMiIgeT0iODQiIHdpZHRoPSIxNTgiIGhlaWdodD0iNTgiIHJ4PSIxMSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iMzAxIiB5PSIxMDgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTJweCI+UkRTIGZvciBNeVNRTDwvdGV4dD4KPHRleHQgeD0iMzAxIiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjMzM0MTU1Ij5hd3NfZGJfaW5zdGFuY2U8L3RleHQ+CjxyZWN0IHg9IjQ0MCIgeT0iNDAiIHdpZHRoPSIzODAiIGhlaWdodD0iMTQwIiByeD0iMTQiIHN0cm9rZS13aWR0aD0iMS40IiBzdHJva2UtZGFzaGFycmF5PSI1IDUiIHN0eWxlPSJmaWxsOiNmOGZhZmM7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iNDU2IiB5PSI2MiIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjg7IGZpbGw6IzA0Nzg1NyI+T04gT0NJPC90ZXh0Pgo8cmVjdCB4PSI0NTYiIHk9Ijg0IiB3aWR0aD0iMTIwIiBoZWlnaHQ9IjU4IiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjUxNiIgeT0iMTEwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjEycHgiPllvdXIgYXBwPC90ZXh0Pgo8dGV4dCB4PSI1MTYiIHk9IjEyNyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij5zYW1lIGRyaXZlcjwvdGV4dD4KPGxpbmUgeDE9IjU3NiIgeTE9IjExMyIgeDI9IjYxMCIgeTI9IjExMyIgc3Ryb2tlLXdpZHRoPSIxLjgiIG1hcmtlci1lbmQ9InVybCgjb2h3MWgpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iNTkzIiB5PSIxMDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmb250LXNpemU6OC41cHgiPk15U1FMPC90ZXh0Pgo8cmVjdCB4PSI2MTIiIHk9Ijg0IiB3aWR0aD0iMTk0IiBoZWlnaHQ9IjU4IiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjcwOSIgeT0iMTA4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC1zaXplOjExLjVweCI+T0NJIE15U1FMIEhlYXRXYXZlPC90ZXh0Pgo8dGV4dCB4PSI3MDkiIHk9IjEyNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+TXlTUUwgZW5naW5lIMK3IG5hdGl2ZTwvdGV4dD4KPC9zdmc+) ![Before: on AWS your app talks to an RDS for MySQL instance over the MySQL protocol. After: on OCI the same app with the same driver talks over the same MySQL protocol to a native OCI MySQL HeatWave DB system, without Tensor9 proxying database traffic.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjAwIiB2aWV3Qm94PSIwIDAgODM2IDIwMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJCZWZvcmU6IG9uIEFXUyB5b3VyIGFwcCB0YWxrcyB0byBhbiBSRFMgZm9yIE15U1FMIGluc3RhbmNlIG92ZXIgdGhlIE15U1FMIHByb3RvY29sLiBBZnRlcjogb24gT0NJIHRoZSBzYW1lIGFwcCB3aXRoIHRoZSBzYW1lIGRyaXZlciB0YWxrcyBvdmVyIHRoZSBzYW1lIE15U1FMIHByb3RvY29sIHRvIGEgbmF0aXZlIE9DSSBNeVNRTCBIZWF0V2F2ZSBEQiBzeXN0ZW0sIHdpdGhvdXQgVGVuc29yOSBwcm94eWluZyBkYXRhYmFzZSB0cmFmZmljLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJvaHcxaCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6IzY0NzQ4YiIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iMTYiIHk9IjQwIiB3aWR0aD0iMzgwIiBoZWlnaHQ9IjE0MCIgcng9IjE0IiBzdHJva2Utd2lkdGg9IjEuNCIgc3Ryb2tlLWRhc2hhcnJheT0iNSA1IiBzdHlsZT0iZmlsbDojMGYxNzJhO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjMyIiB5PSI2MiIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGIiPk9OIEFXUyBUT0RBWTwvdGV4dD4KPHJlY3QgeD0iMzYiIHk9Ijg0IiB3aWR0aD0iMTUwIiBoZWlnaHQ9IjU4IiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjExMSIgeT0iMTEwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOSI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjExMSIgeT0iMTI3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+TXlTUUwgZHJpdmVyPC90ZXh0Pgo8bGluZSB4MT0iMTg2IiB5MT0iMTEzIiB4Mj0iMjIwIiB5Mj0iMTEzIiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLWVuZD0idXJsKCNvaHcxaCkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8dGV4dCB4PSIyMDMiIHk9IjEwNSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZTo4LjVweCI+TXlTUUw8L3RleHQ+CjxyZWN0IHg9IjIyMiIgeT0iODQiIHdpZHRoPSIxNTgiIGhlaWdodD0iNTgiIHJ4PSIxMSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iMzAxIiB5PSIxMDgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTJweCI+UkRTIGZvciBNeVNRTDwvdGV4dD4KPHRleHQgeD0iMzAxIiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjY2JkNWUxIj5hd3NfZGJfaW5zdGFuY2U8L3RleHQ+CjxyZWN0IHg9IjQ0MCIgeT0iNDAiIHdpZHRoPSIzODAiIGhlaWdodD0iMTQwIiByeD0iMTQiIHN0cm9rZS13aWR0aD0iMS40IiBzdHJva2UtZGFzaGFycmF5PSI1IDUiIHN0eWxlPSJmaWxsOiMwZjE3MmE7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iNDU2IiB5PSI2MiIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGI7IGZpbGw6IzZlZTdiNyI+T04gT0NJPC90ZXh0Pgo8cmVjdCB4PSI0NTYiIHk9Ijg0IiB3aWR0aD0iMTIwIiBoZWlnaHQ9IjU4IiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjUxNiIgeT0iMTEwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjEycHgiPllvdXIgYXBwPC90ZXh0Pgo8dGV4dCB4PSI1MTYiIHk9IjEyNyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij5zYW1lIGRyaXZlcjwvdGV4dD4KPGxpbmUgeDE9IjU3NiIgeTE9IjExMyIgeDI9IjYxMCIgeTI9IjExMyIgc3Ryb2tlLXdpZHRoPSIxLjgiIG1hcmtlci1lbmQ9InVybCgjb2h3MWgpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iNTkzIiB5PSIxMDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmb250LXNpemU6OC41cHgiPk15U1FMPC90ZXh0Pgo8cmVjdCB4PSI2MTIiIHk9Ijg0IiB3aWR0aD0iMTk0IiBoZWlnaHQ9IjU4IiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjcwOSIgeT0iMTA4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC1zaXplOjExLjVweCI+T0NJIE15U1FMIEhlYXRXYXZlPC90ZXh0Pgo8dGV4dCB4PSI3MDkiIHk9IjEyNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+TXlTUUwgZW5naW5lIMK3IG5hdGl2ZTwvdGV4dD4KPC9zdmc+) Your app keeps its driver and speaks the MySQL protocol straight to the database, no proxy in between. #### 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. ![OCI MySQL HeatWave runs MySQL with optional analytics. The MySQL DB system serves transactional (OLTP) queries against your tables, and a HeatWave cluster of in-memory analytics nodes attaches to the same DB system to serve analytics (OLAP) queries against the same data without a separate extraction and loading pipeline.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTg4IiB2aWV3Qm94PSIwIDAgODM2IDE4OCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJPQ0kgTXlTUUwgSGVhdFdhdmUgcnVucyBNeVNRTCB3aXRoIG9wdGlvbmFsIGFuYWx5dGljcy4gVGhlIE15U1FMIERCIHN5c3RlbSBzZXJ2ZXMgdHJhbnNhY3Rpb25hbCAoT0xUUCkgcXVlcmllcyBhZ2FpbnN0IHlvdXIgdGFibGVzLCBhbmQgYSBIZWF0V2F2ZSBjbHVzdGVyIG9mIGluLW1lbW9yeSBhbmFseXRpY3Mgbm9kZXMgYXR0YWNoZXMgdG8gdGhlIHNhbWUgREIgc3lzdGVtIHRvIHNlcnZlIGFuYWx5dGljcyAoT0xBUCkgcXVlcmllcyBhZ2FpbnN0IHRoZSBzYW1lIGRhdGEgd2l0aG91dCBhIHNlcGFyYXRlIGV4dHJhY3Rpb24gYW5kIGxvYWRpbmcgcGlwZWxpbmUuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojMzM0MTU1fTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9Im9odzJoIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjUiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI2IiBtYXJrZXJIZWlnaHQ9IjYiIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiMwNDc4NTciLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjU2IiB5PSI1MiIgd2lkdGg9IjMxMCIgaGVpZ2h0PSI4NiIgcng9IjEzIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSIyMTEiIHk9IjgyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC1zaXplOjEyLjVweCI+TXlTUUwgREIgc3lzdGVtPC90ZXh0Pgo8dGV4dCB4PSIyMTEiIHk9IjEwNCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+T0xUUCDCtyB5b3VyIHRhYmxlcywgbmF0aXZlIE15U1FMPC90ZXh0Pgo8dGV4dCB4PSIyMTEiIHk9IjEyNCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPnRoZSBhcHAgY29ubmVjdHMgaGVyZSwgdW5jaGFuZ2VkPC90ZXh0Pgo8bGluZSB4MT0iMzY2IiB5MT0iOTUiIHgyPSI0NzAiIHkyPSI5NSIgc3Ryb2tlLXdpZHRoPSIxLjgiIG1hcmtlci1zdGFydD0idXJsKCNvaHcyaCkiIG1hcmtlci1lbmQ9InVybCgjb2h3MmgpIiBzdHlsZT0ic3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iNDE4IiB5PSI4NyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZTo5cHg7ZmlsbDojMDQ3ODU3Ij50YWJsZSBkYXRhIGxvYWQ8L3RleHQ+CjxyZWN0IHg9IjQ3NCIgeT0iNTIiIHdpZHRoPSIzMDYiIGhlaWdodD0iODYiIHJ4PSIxMyIgc3Ryb2tlLXdpZHRoPSIxLjYiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNhN2YzZDAiLz4KPHRleHQgeD0iNjI3IiB5PSI4MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMi41cHgiPkhlYXRXYXZlIGNsdXN0ZXI8L3RleHQ+Cjx0ZXh0IHg9IjYyNyIgeT0iMTA0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+aW4tbWVtb3J5IGFuYWx5dGljcyAoT0xBUCk8L3RleHQ+Cjx0ZXh0IHg9IjYyNyIgeT0iMTI0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+YXR0YWNoZWQgdG8gdGhlIHNhbWUgREIgc3lzdGVtPC90ZXh0Pgo8dGV4dCB4PSI0MTgiIHk9IjE2OCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+VGhlIEhlYXRXYXZlIGFuYWx5dGljcyBjbHVzdGVyIGlzIG9wdGlvbmFsPC90ZXh0Pgo8L3N2Zz4=) ![OCI MySQL HeatWave runs MySQL with optional analytics. The MySQL DB system serves transactional (OLTP) queries against your tables, and a HeatWave cluster of in-memory analytics nodes attaches to the same DB system to serve analytics (OLAP) queries against the same data without a separate extraction and loading pipeline.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTg4IiB2aWV3Qm94PSIwIDAgODM2IDE4OCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJPQ0kgTXlTUUwgSGVhdFdhdmUgcnVucyBNeVNRTCB3aXRoIG9wdGlvbmFsIGFuYWx5dGljcy4gVGhlIE15U1FMIERCIHN5c3RlbSBzZXJ2ZXMgdHJhbnNhY3Rpb25hbCAoT0xUUCkgcXVlcmllcyBhZ2FpbnN0IHlvdXIgdGFibGVzLCBhbmQgYSBIZWF0V2F2ZSBjbHVzdGVyIG9mIGluLW1lbW9yeSBhbmFseXRpY3Mgbm9kZXMgYXR0YWNoZXMgdG8gdGhlIHNhbWUgREIgc3lzdGVtIHRvIHNlcnZlIGFuYWx5dGljcyAoT0xBUCkgcXVlcmllcyBhZ2FpbnN0IHRoZSBzYW1lIGRhdGEgd2l0aG91dCBhIHNlcGFyYXRlIGV4dHJhY3Rpb24gYW5kIGxvYWRpbmcgcGlwZWxpbmUuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojY2JkNWUxfTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9Im9odzJoIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjUiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI2IiBtYXJrZXJIZWlnaHQ9IjYiIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM2ZWU3YjciLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjU2IiB5PSI1MiIgd2lkdGg9IjMxMCIgaGVpZ2h0PSI4NiIgcng9IjEzIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSIyMTEiIHk9IjgyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC1zaXplOjEyLjVweCI+TXlTUUwgREIgc3lzdGVtPC90ZXh0Pgo8dGV4dCB4PSIyMTEiIHk9IjEwNCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+T0xUUCDCtyB5b3VyIHRhYmxlcywgbmF0aXZlIE15U1FMPC90ZXh0Pgo8dGV4dCB4PSIyMTEiIHk9IjEyNCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPnRoZSBhcHAgY29ubmVjdHMgaGVyZSwgdW5jaGFuZ2VkPC90ZXh0Pgo8bGluZSB4MT0iMzY2IiB5MT0iOTUiIHgyPSI0NzAiIHkyPSI5NSIgc3Ryb2tlLXdpZHRoPSIxLjgiIG1hcmtlci1zdGFydD0idXJsKCNvaHcyaCkiIG1hcmtlci1lbmQ9InVybCgjb2h3MmgpIiBzdHlsZT0ic3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iNDE4IiB5PSI4NyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZTo5cHg7ZmlsbDojNmVlN2I3Ij50YWJsZSBkYXRhIGxvYWQ8L3RleHQ+CjxyZWN0IHg9IjQ3NCIgeT0iNTIiIHdpZHRoPSIzMDYiIGhlaWdodD0iODYiIHJ4PSIxMyIgc3Ryb2tlLXdpZHRoPSIxLjYiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iNjI3IiB5PSI4MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMi41cHgiPkhlYXRXYXZlIGNsdXN0ZXI8L3RleHQ+Cjx0ZXh0IHg9IjYyNyIgeT0iMTA0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+aW4tbWVtb3J5IGFuYWx5dGljcyAoT0xBUCk8L3RleHQ+Cjx0ZXh0IHg9IjYyNyIgeT0iMTI0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+YXR0YWNoZWQgdG8gdGhlIHNhbWUgREIgc3lzdGVtPC90ZXh0Pgo8dGV4dCB4PSI0MTgiIHk9IjE2OCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+VGhlIEhlYXRXYXZlIGFuYWx5dGljcyBjbHVzdGVyIGlzIG9wdGlvbmFsPC90ZXh0Pgo8L3N2Zz4=) 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. ![An OCI MySQL DB system serves up to eighteen in-region read replicas, automatically distributed across availability and fault domains. Managed read replicas stay in-region. A replication channel can maintain a readable DB system in another region; a backup copy must be restored.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjEwIiB2aWV3Qm94PSIwIDAgODM2IDIxMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJBbiBPQ0kgTXlTUUwgREIgc3lzdGVtIHNlcnZlcyB1cCB0byBlaWdodGVlbiBpbi1yZWdpb24gcmVhZCByZXBsaWNhcywgYXV0b21hdGljYWxseSBkaXN0cmlidXRlZCBhY3Jvc3MgYXZhaWxhYmlsaXR5IGFuZCBmYXVsdCBkb21haW5zLiBNYW5hZ2VkIHJlYWQgcmVwbGljYXMgc3RheSBpbi1yZWdpb24uIEEgcmVwbGljYXRpb24gY2hhbm5lbCBjYW4gbWFpbnRhaW4gYSByZWFkYWJsZSBEQiBzeXN0ZW0gaW4gYW5vdGhlciByZWdpb247IGEgYmFja3VwIGNvcHkgbXVzdCBiZSByZXN0b3JlZC4iPjxzdHlsZT50ZXh0e2ZvbnQtZmFtaWx5OkludGVyLC1hcHBsZS1zeXN0ZW0sQmxpbmtNYWNTeXN0ZW1Gb250LCdTZWdvZSBVSScsUm9ib3RvLCdIZWx2ZXRpY2EgTmV1ZScsQXJpYWwsc2Fucy1zZXJpZjtmaWxsOiMzMzQxNTV9PC9zdHlsZT4KPGRlZnM+PG1hcmtlciBpZD0ib2h3M2giIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjYuNSIgbWFya2VySGVpZ2h0PSI2LjUiIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM5NGEzYjgiLz48L21hcmtlcj4KPG1hcmtlciBpZD0ib2h3M2EiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjYuNSIgbWFya2VySGVpZ2h0PSI2LjUiIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiNiNDUzMDkiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjQwIiB5PSI3MiIgd2lkdGg9IjE5MCIgaGVpZ2h0PSI1OCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSIxMzUiIHk9Ijk4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC1zaXplOjEycHgiPk15U1FMIERCIHN5c3RlbTwvdGV4dD4KPHRleHQgeD0iMTM1IiB5PSIxMTUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPndyaXRlcjwvdGV4dD4KPGxpbmUgeDE9IjIzMCIgeTE9IjkwIiB4Mj0iMjk4IiB5Mj0iODAiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI29odzNoKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjMwMCIgeT0iNTIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmb250LXNpemU6OXB4Ij5pbi1yZWdpb248L3RleHQ+CjxyZWN0IHg9IjMwMiIgeT0iNTYiIHdpZHRoPSIyMjgiIGhlaWdodD0iNzQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNhN2YzZDAiLz4KPHRleHQgeD0iNDE2IiB5PSI4MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMS41cHgiPlJlYWQgcmVwbGljYXMgwrcgdXAgdG8gMTg8L3RleHQ+Cjx0ZXh0IHg9IjQxNiIgeT0iMTAwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+YWNyb3NzIGF2YWlsYWJpbGl0eSAvIGZhdWx0IGRvbWFpbnM8L3RleHQ+Cjx0ZXh0IHg9IjQxNiIgeT0iMTE3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+ZWFjaCB3aXRoIGl0cyBvd24gZW5kcG9pbnQ8L3RleHQ+CjxsaW5lIHgxPSIyMzAiIHkxPSIxMDQiIHgyPSI1NTIiIHkyPSIxNTAiIHN0cm9rZS13aWR0aD0iMS42IiBzdHJva2UtZGFzaGFycmF5PSI1IDQiIG1hcmtlci1lbmQ9InVybCgjb2h3M2EpIiBzdHlsZT0ic3Ryb2tlOiNiNDUzMDkiLz4KPHRleHQgeD0iMzg2IiB5PSIxNTAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2MDAgMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2I0NTMwOTsgZm9udC1zaXplOjlweCI+YXN5bmMgcmVwbGljYXRpb248L3RleHQ+CjxyZWN0IHg9IjU1NiIgeT0iMTMyIiB3aWR0aD0iMjUwIiBoZWlnaHQ9IjYwIiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmYmViO3N0cm9rZTojZmRlNjhhIi8+Cjx0ZXh0IHg9IjY4MSIgeT0iMTU2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNiNDUzMDk7IGZvbnQtc2l6ZToxMS41cHgiPlJlZ2lvbiBCOiBzZXBhcmF0ZSBEQiBzeXN0ZW08L3RleHQ+Cjx0ZXh0IHg9IjY4MSIgeT0iMTc0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNiNDUzMDk7IGZvbnQtc2l6ZToxMHB4Ij5yZXBsaWNhdGlvbiBjaGFubmVsOyByZWFkYWJsZTwvdGV4dD4KPC9zdmc+) ![An OCI MySQL DB system serves up to eighteen in-region read replicas, automatically distributed across availability and fault domains. Managed read replicas stay in-region. A replication channel can maintain a readable DB system in another region; a backup copy must be restored.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjEwIiB2aWV3Qm94PSIwIDAgODM2IDIxMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJBbiBPQ0kgTXlTUUwgREIgc3lzdGVtIHNlcnZlcyB1cCB0byBlaWdodGVlbiBpbi1yZWdpb24gcmVhZCByZXBsaWNhcywgYXV0b21hdGljYWxseSBkaXN0cmlidXRlZCBhY3Jvc3MgYXZhaWxhYmlsaXR5IGFuZCBmYXVsdCBkb21haW5zLiBNYW5hZ2VkIHJlYWQgcmVwbGljYXMgc3RheSBpbi1yZWdpb24uIEEgcmVwbGljYXRpb24gY2hhbm5lbCBjYW4gbWFpbnRhaW4gYSByZWFkYWJsZSBEQiBzeXN0ZW0gaW4gYW5vdGhlciByZWdpb247IGEgYmFja3VwIGNvcHkgbXVzdCBiZSByZXN0b3JlZC4iPjxzdHlsZT50ZXh0e2ZvbnQtZmFtaWx5OkludGVyLC1hcHBsZS1zeXN0ZW0sQmxpbmtNYWNTeXN0ZW1Gb250LCdTZWdvZSBVSScsUm9ib3RvLCdIZWx2ZXRpY2EgTmV1ZScsQXJpYWwsc2Fucy1zZXJpZjtmaWxsOiNjYmQ1ZTF9PC9zdHlsZT4KPGRlZnM+PG1hcmtlciBpZD0ib2h3M2giIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjYuNSIgbWFya2VySGVpZ2h0PSI2LjUiIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM2NDc0OGIiLz48L21hcmtlcj4KPG1hcmtlciBpZD0ib2h3M2EiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjYuNSIgbWFya2VySGVpZ2h0PSI2LjUiIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiNmYmJmMjQiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjQwIiB5PSI3MiIgd2lkdGg9IjE5MCIgaGVpZ2h0PSI1OCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSIxMzUiIHk9Ijk4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC1zaXplOjEycHgiPk15U1FMIERCIHN5c3RlbTwvdGV4dD4KPHRleHQgeD0iMTM1IiB5PSIxMTUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPndyaXRlcjwvdGV4dD4KPGxpbmUgeDE9IjIzMCIgeTE9IjkwIiB4Mj0iMjk4IiB5Mj0iODAiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI29odzNoKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjMwMCIgeT0iNTIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmb250LXNpemU6OXB4Ij5pbi1yZWdpb248L3RleHQ+CjxyZWN0IHg9IjMwMiIgeT0iNTYiIHdpZHRoPSIyMjgiIGhlaWdodD0iNzQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iNDE2IiB5PSI4MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMS41cHgiPlJlYWQgcmVwbGljYXMgwrcgdXAgdG8gMTg8L3RleHQ+Cjx0ZXh0IHg9IjQxNiIgeT0iMTAwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+YWNyb3NzIGF2YWlsYWJpbGl0eSAvIGZhdWx0IGRvbWFpbnM8L3RleHQ+Cjx0ZXh0IHg9IjQxNiIgeT0iMTE3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+ZWFjaCB3aXRoIGl0cyBvd24gZW5kcG9pbnQ8L3RleHQ+CjxsaW5lIHgxPSIyMzAiIHkxPSIxMDQiIHgyPSI1NTIiIHkyPSIxNTAiIHN0cm9rZS13aWR0aD0iMS42IiBzdHJva2UtZGFzaGFycmF5PSI1IDQiIG1hcmtlci1lbmQ9InVybCgjb2h3M2EpIiBzdHlsZT0ic3Ryb2tlOiNmYmJmMjQiLz4KPHRleHQgeD0iMzg2IiB5PSIxNTAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2MDAgMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2ZiYmYyNDsgZm9udC1zaXplOjlweCI+YXN5bmMgcmVwbGljYXRpb248L3RleHQ+CjxyZWN0IHg9IjU1NiIgeT0iMTMyIiB3aWR0aD0iMjUwIiBoZWlnaHQ9IjYwIiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojNDIyMDA2O3N0cm9rZTojOTI0MDBlIi8+Cjx0ZXh0IHg9IjY4MSIgeT0iMTU2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmYmJmMjQ7IGZvbnQtc2l6ZToxMS41cHgiPlJlZ2lvbiBCOiBzZXBhcmF0ZSBEQiBzeXN0ZW08L3RleHQ+Cjx0ZXh0IHg9IjY4MSIgeT0iMTc0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmYmJmMjQ7IGZvbnQtc2l6ZToxMHB4Ij5yZXBsaWNhdGlvbiBjaGFubmVsOyByZWFkYWJsZTwvdGV4dD4KPC9zdmc+) 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 with Paxos consensus, spread across availability or fault domains. A transaction is acknowledged by a quorum before commit, so failover loses no committed write (RPO 0), with a 99.99 percent availability SLA.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTkwIiB2aWV3Qm94PSIwIDAgODM2IDE5MCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJPQ0kgTXlTUUwgSGVhdFdhdmUgSEEgaXMgYSB0aHJlZS1ub2RlIEdyb3VwIFJlcGxpY2F0aW9uIHF1b3J1bSB3aXRoIFBheG9zIGNvbnNlbnN1cywgc3ByZWFkIGFjcm9zcyBhdmFpbGFiaWxpdHkgb3IgZmF1bHQgZG9tYWlucy4gQSB0cmFuc2FjdGlvbiBpcyBhY2tub3dsZWRnZWQgYnkgYSBxdW9ydW0gYmVmb3JlIGNvbW1pdCwgc28gZmFpbG92ZXIgbG9zZXMgbm8gY29tbWl0dGVkIHdyaXRlIChSUE8gMCksIHdpdGggYSA5OS45OSBwZXJjZW50IGF2YWlsYWJpbGl0eSBTTEEuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojMzM0MTU1fTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9Im9odzRoIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjUiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI2IiBtYXJrZXJIZWlnaHQ9IjYiIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiMwNDc4NTciLz48L21hcmtlcj48L2RlZnM+Cjx0ZXh0IHg9IjQxOCIgeT0iMjgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4OyBmaWxsOiMwNDc4NTciPjMtTk9ERSBHUk9VUCBSRVBMSUNBVElPTiAoUEFYT1MpPC90ZXh0Pgo8cmVjdCB4PSIxMjAiIHk9IjU2IiB3aWR0aD0iMTUwIiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS42IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjE5NSIgeT0iODQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXNpemU6MTJweCI+cHJpbWFyeTwvdGV4dD4KPHRleHQgeD0iMTk1IiB5PSIxMDMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPkFEIC8gRkQgMTwvdGV4dD4KPHJlY3QgeD0iMzQzIiB5PSI1NiIgd2lkdGg9IjE1MCIgaGVpZ2h0PSI2NCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNiIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI0MTgiIHk9Ijg0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC1zaXplOjEycHgiPnNlY29uZGFyeTwvdGV4dD4KPHRleHQgeD0iNDE4IiB5PSIxMDMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPkFEIC8gRkQgMjwvdGV4dD4KPHJlY3QgeD0iNTY2IiB5PSI1NiIgd2lkdGg9IjE1MCIgaGVpZ2h0PSI2NCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNiIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI2NDEiIHk9Ijg0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC1zaXplOjEycHgiPnNlY29uZGFyeTwvdGV4dD4KPHRleHQgeD0iNjQxIiB5PSIxMDMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPkFEIC8gRkQgMzwvdGV4dD4KPGxpbmUgeDE9IjI3MiIgeTE9Ijg4IiB4Mj0iMzQxIiB5Mj0iODgiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItc3RhcnQ9InVybCgjb2h3NGgpIiBtYXJrZXItZW5kPSJ1cmwoI29odzRoKSIgc3R5bGU9InN0cm9rZTojMDQ3ODU3Ii8+CjxsaW5lIHgxPSI0OTUiIHkxPSI4OCIgeDI9IjU2NCIgeTI9Ijg4IiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLXN0YXJ0PSJ1cmwoI29odzRoKSIgbWFya2VyLWVuZD0idXJsKCNvaHc0aCkiIHN0eWxlPSJzdHJva2U6IzA0Nzg1NyIvPgo8cmVjdCB4PSIxMjAiIHk9IjE0MCIgd2lkdGg9IjU5NiIgaGVpZ2h0PSIzNCIgcng9IjEwIiBzdHJva2Utd2lkdGg9IjEuMyIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6I2E3ZjNkMCIvPgo8dGV4dCB4PSI0MTgiIHk9IjE2MSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+QSBxdW9ydW0gYWNrbm93bGVkZ2VzIGVhY2ggY29tbWl0IGJlZm9yZSBpdCByZXR1cm5zOyBmYWlsb3ZlciBsb3NlcyBubyBjb21taXR0ZWQgd3JpdGUgKFJQTyAwKSDCtyA5OS45OSUgU0xBPC90ZXh0Pgo8L3N2Zz4=) ![OCI MySQL HeatWave HA is a three-node Group Replication quorum with Paxos consensus, spread across availability or fault domains. A transaction is acknowledged by a quorum before commit, so failover loses no committed write (RPO 0), with a 99.99 percent availability SLA.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTkwIiB2aWV3Qm94PSIwIDAgODM2IDE5MCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJPQ0kgTXlTUUwgSGVhdFdhdmUgSEEgaXMgYSB0aHJlZS1ub2RlIEdyb3VwIFJlcGxpY2F0aW9uIHF1b3J1bSB3aXRoIFBheG9zIGNvbnNlbnN1cywgc3ByZWFkIGFjcm9zcyBhdmFpbGFiaWxpdHkgb3IgZmF1bHQgZG9tYWlucy4gQSB0cmFuc2FjdGlvbiBpcyBhY2tub3dsZWRnZWQgYnkgYSBxdW9ydW0gYmVmb3JlIGNvbW1pdCwgc28gZmFpbG92ZXIgbG9zZXMgbm8gY29tbWl0dGVkIHdyaXRlIChSUE8gMCksIHdpdGggYSA5OS45OSBwZXJjZW50IGF2YWlsYWJpbGl0eSBTTEEuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojY2JkNWUxfTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9Im9odzRoIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjUiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI2IiBtYXJrZXJIZWlnaHQ9IjYiIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM2ZWU3YjciLz48L21hcmtlcj48L2RlZnM+Cjx0ZXh0IHg9IjQxOCIgeT0iMjgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiM2ZWU3YjciPjMtTk9ERSBHUk9VUCBSRVBMSUNBVElPTiAoUEFYT1MpPC90ZXh0Pgo8cmVjdCB4PSIxMjAiIHk9IjU2IiB3aWR0aD0iMTUwIiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS42IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjE5NSIgeT0iODQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXNpemU6MTJweCI+cHJpbWFyeTwvdGV4dD4KPHRleHQgeD0iMTk1IiB5PSIxMDMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPkFEIC8gRkQgMTwvdGV4dD4KPHJlY3QgeD0iMzQzIiB5PSI1NiIgd2lkdGg9IjE1MCIgaGVpZ2h0PSI2NCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNiIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSI0MTgiIHk9Ijg0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC1zaXplOjEycHgiPnNlY29uZGFyeTwvdGV4dD4KPHRleHQgeD0iNDE4IiB5PSIxMDMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPkFEIC8gRkQgMjwvdGV4dD4KPHJlY3QgeD0iNTY2IiB5PSI1NiIgd2lkdGg9IjE1MCIgaGVpZ2h0PSI2NCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNiIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSI2NDEiIHk9Ijg0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC1zaXplOjEycHgiPnNlY29uZGFyeTwvdGV4dD4KPHRleHQgeD0iNjQxIiB5PSIxMDMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPkFEIC8gRkQgMzwvdGV4dD4KPGxpbmUgeDE9IjI3MiIgeTE9Ijg4IiB4Mj0iMzQxIiB5Mj0iODgiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItc3RhcnQ9InVybCgjb2h3NGgpIiBtYXJrZXItZW5kPSJ1cmwoI29odzRoKSIgc3R5bGU9InN0cm9rZTojNmVlN2I3Ii8+CjxsaW5lIHgxPSI0OTUiIHkxPSI4OCIgeDI9IjU2NCIgeTI9Ijg4IiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLXN0YXJ0PSJ1cmwoI29odzRoKSIgbWFya2VyLWVuZD0idXJsKCNvaHc0aCkiIHN0eWxlPSJzdHJva2U6IzZlZTdiNyIvPgo8cmVjdCB4PSIxMjAiIHk9IjE0MCIgd2lkdGg9IjU5NiIgaGVpZ2h0PSIzNCIgcng9IjEwIiBzdHJva2Utd2lkdGg9IjEuMyIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI0MTgiIHk9IjE2MSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+QSBxdW9ydW0gYWNrbm93bGVkZ2VzIGVhY2ggY29tbWl0IGJlZm9yZSBpdCByZXR1cm5zOyBmYWlsb3ZlciBsb3NlcyBubyBjb21taXR0ZWQgd3JpdGUgKFJQTyAwKSDCtyA5OS45OSUgU0xBPC90ZXh0Pgo8L3N2Zz4=) A majority of three nodes acknowledges each commit, so failover loses no committed write. #### Parameters, native auth, and the customer key OCI sets MySQL parameters through configuration variables; the reusable RDS parameter-group object has no counterpart. A declared `aws_db_parameter_group` is not kept: the deployment removes it and reports a warning, so the DB system starts with OCI's default values. Set the configuration variables you need; parameters outside OCI's allowed list cannot be set. Later parameter changes made through the RDS API, such as `ModifyDBParameterGroup`, are translated to configuration variables where they map. 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 backend database credentials. ![An RDS parameter group is not kept; you set OCI MySQL configuration variables yourself. A KMS customer key maps to a customer-managed key in OCI Vault. RDS IAM database authentication has no counterpart: OCI MySQL uses native MySQL accounts.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjA4IiB2aWV3Qm94PSIwIDAgODM2IDIwOCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJBbiBSRFMgcGFyYW1ldGVyIGdyb3VwIGlzIG5vdCBrZXB0OyB5b3Ugc2V0IE9DSSBNeVNRTCBjb25maWd1cmF0aW9uIHZhcmlhYmxlcyB5b3Vyc2VsZi4gQSBLTVMgY3VzdG9tZXIga2V5IG1hcHMgdG8gYSBjdXN0b21lci1tYW5hZ2VkIGtleSBpbiBPQ0kgVmF1bHQuIFJEUyBJQU0gZGF0YWJhc2UgYXV0aGVudGljYXRpb24gaGFzIG5vIGNvdW50ZXJwYXJ0OiBPQ0kgTXlTUUwgdXNlcyBuYXRpdmUgTXlTUUwgYWNjb3VudHMuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojMzM0MTU1fTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9Im9odzVoIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI2LjUiIG1hcmtlckhlaWdodD0iNi41IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+PHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBzdHlsZT0iZmlsbDojOTRhM2I4Ii8+PC9tYXJrZXI+PC9kZWZzPgo8cmVjdCB4PSI0NCIgeT0iNDAiIHdpZHRoPSIzMDAiIGhlaWdodD0iNDQiIHJ4PSIxMCIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iNjAiIHk9IjY3IiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzMzNDE1NTsgZm9udC1zaXplOjEwLjVweCI+UkRTIHBhcmFtZXRlciBncm91cDwvdGV4dD4KPGxpbmUgeDE9IjM0OCIgeTE9IjYyIiB4Mj0iNDcwIiB5Mj0iNjIiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItZW5kPSJ1cmwoI29odzVoKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxyZWN0IHg9IjQ3NCIgeT0iNDAiIHdpZHRoPSIzMTgiIGhlaWdodD0iNDQiIHJ4PSIxMCIgc3Ryb2tlLXdpZHRoPSIxLjYiIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iNDkwIiB5PSI2NyIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjYjQ1MzA5OyBmb250LXdlaWdodDo3MDAiPm5vdCBjYXJyaWVkOyBzZXQgT0NJIGNvbmZpZyB5b3Vyc2VsZjwvdGV4dD4KPHJlY3QgeD0iNDQiIHk9Ijk2IiB3aWR0aD0iMzAwIiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjYwIiB5PSIxMjMiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjMzM0MTU1OyBmb250LXNpemU6MTAuNXB4Ij5LTVMgY3VzdG9tZXIga2V5PC90ZXh0Pgo8bGluZSB4MT0iMzQ4IiB5MT0iMTE4IiB4Mj0iNDcwIiB5Mj0iMTE4IiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLWVuZD0idXJsKCNvaHc1aCkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8cmVjdCB4PSI0NzQiIHk9Ijk2IiB3aWR0aD0iMzE4IiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS42IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjQ5MCIgeT0iMTIzIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXdlaWdodDo3MDAiPmN1c3RvbWVyLW1hbmFnZWQga2V5IChPQ0kgVmF1bHQpPC90ZXh0Pgo8cmVjdCB4PSI0NCIgeT0iMTUyIiB3aWR0aD0iNzQ4IiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS40IiBzdHlsZT0iZmlsbDojZmZmYmViO3N0cm9rZTojZmRlNjhhIi8+Cjx0ZXh0IHg9IjYwIiB5PSIxNzIiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjMzM0MTU1OyBmb250LXNpemU6MTAuNXB4Ij5SRFMgSUFNIGRhdGFiYXNlIGF1dGg8L3RleHQ+Cjx0ZXh0IHg9IjQxOCIgeT0iMTg4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNiNDUzMDkiPm5vIGNsb3VkLUlBTSBkYXRhYmFzZSBhdXRoIG9uIE9DSSBNeVNRTDsgbmF0aXZlIE15U1FMIGFjY291bnRzIGF1dGhlbnRpY2F0ZSB0aGUgY29ubmVjdGlvbjwvdGV4dD4KPC9zdmc+) ![An RDS parameter group is not kept; you set OCI MySQL configuration variables yourself. A KMS customer key maps to a customer-managed key in OCI Vault. RDS IAM database authentication has no counterpart: OCI MySQL uses native MySQL accounts.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjA4IiB2aWV3Qm94PSIwIDAgODM2IDIwOCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJBbiBSRFMgcGFyYW1ldGVyIGdyb3VwIGlzIG5vdCBrZXB0OyB5b3Ugc2V0IE9DSSBNeVNRTCBjb25maWd1cmF0aW9uIHZhcmlhYmxlcyB5b3Vyc2VsZi4gQSBLTVMgY3VzdG9tZXIga2V5IG1hcHMgdG8gYSBjdXN0b21lci1tYW5hZ2VkIGtleSBpbiBPQ0kgVmF1bHQuIFJEUyBJQU0gZGF0YWJhc2UgYXV0aGVudGljYXRpb24gaGFzIG5vIGNvdW50ZXJwYXJ0OiBPQ0kgTXlTUUwgdXNlcyBuYXRpdmUgTXlTUUwgYWNjb3VudHMuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojY2JkNWUxfTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9Im9odzVoIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI2LjUiIG1hcmtlckhlaWdodD0iNi41IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+PHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBzdHlsZT0iZmlsbDojNjQ3NDhiIi8+PC9tYXJrZXI+PC9kZWZzPgo8cmVjdCB4PSI0NCIgeT0iNDAiIHdpZHRoPSIzMDAiIGhlaWdodD0iNDQiIHJ4PSIxMCIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iNjAiIHk9IjY3IiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogI2NiZDVlMTsgZm9udC1zaXplOjEwLjVweCI+UkRTIHBhcmFtZXRlciBncm91cDwvdGV4dD4KPGxpbmUgeDE9IjM0OCIgeTE9IjYyIiB4Mj0iNDcwIiB5Mj0iNjIiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItZW5kPSJ1cmwoI29odzVoKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxyZWN0IHg9IjQ3NCIgeT0iNDAiIHdpZHRoPSIzMTgiIGhlaWdodD0iNDQiIHJ4PSIxMCIgc3Ryb2tlLXdpZHRoPSIxLjYiIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iNDkwIiB5PSI2NyIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZmJiZjI0OyBmb250LXdlaWdodDo3MDAiPm5vdCBjYXJyaWVkOyBzZXQgT0NJIGNvbmZpZyB5b3Vyc2VsZjwvdGV4dD4KPHJlY3QgeD0iNDQiIHk9Ijk2IiB3aWR0aD0iMzAwIiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjYwIiB5PSIxMjMiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjY2JkNWUxOyBmb250LXNpemU6MTAuNXB4Ij5LTVMgY3VzdG9tZXIga2V5PC90ZXh0Pgo8bGluZSB4MT0iMzQ4IiB5MT0iMTE4IiB4Mj0iNDcwIiB5Mj0iMTE4IiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLWVuZD0idXJsKCNvaHc1aCkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8cmVjdCB4PSI0NzQiIHk9Ijk2IiB3aWR0aD0iMzE4IiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS42IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjQ5MCIgeT0iMTIzIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXdlaWdodDo3MDAiPmN1c3RvbWVyLW1hbmFnZWQga2V5IChPQ0kgVmF1bHQpPC90ZXh0Pgo8cmVjdCB4PSI0NCIgeT0iMTUyIiB3aWR0aD0iNzQ4IiBoZWlnaHQ9IjQ0IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS40IiBzdHlsZT0iZmlsbDojNDIyMDA2O3N0cm9rZTojOTI0MDBlIi8+Cjx0ZXh0IHg9IjYwIiB5PSIxNzIiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjY2JkNWUxOyBmb250LXNpemU6MTAuNXB4Ij5SRFMgSUFNIGRhdGFiYXNlIGF1dGg8L3RleHQ+Cjx0ZXh0IHg9IjQxOCIgeT0iMTg4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmYmJmMjQiPm5vIGNsb3VkLUlBTSBkYXRhYmFzZSBhdXRoIG9uIE9DSSBNeVNRTDsgbmF0aXZlIE15U1FMIGFjY291bnRzIGF1dGhlbnRpY2F0ZSB0aGUgY29ubmVjdGlvbjwvdGV4dD4KPC9zdmc+) Parameter groups are not kept, customer keys move to OCI Vault, and authentication uses native MySQL accounts. #### Limitations Where RDS for MySQL and OCI MySQL HeatWave differ * **Cross-region read replicas behave differently: they need a separate DB system.** Managed read replicas stay in-region (up to eighteen). A replication channel can keep a readable database in another region, but it needs separate configuration and can lag behind the source. * **No cloud-IAM database authentication is available.** OCI MySQL authenticates with native MySQL accounts, so a workload that uses RDS IAM database authentication moves to native credentials. * **No managed connection pooler is available.** The DB system has no RDS Proxy equivalent; run a pooler in front of it if you need one. * **Declared parameter groups are dropped at deployment.** The deployment removes the group with a warning, and the DB system starts with OCI's defaults. Set the configuration variables you need; parameters outside OCI's settable list cannot be set. * **MySQL versions behave differently: Oracle chooses them.** The DB system runs the versions OCI offers. Move an instance that needs a version OCI does not publish to a supported one before cutover. * **RDS-only features are not supported.** S3 and Lambda integration SQL and Enhanced Monitoring have no counterpart, 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. #### Example monthly charges This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include. ##### RDS MySQL · Primary allocated compute Feature: RDS MySQL. Estimated monthly service charges by Primary allocated compute. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1 (global list); currency: USD. ![RDS MySQL · Primary allocated compute: monthly service charges by Primary allocated compute. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/c15d167ce21e137e7d26b1dd14e56686007f5a9eea417dc709b3e0ec3bf23735-light.svg) ![RDS MySQL · Primary allocated compute: monthly service charges by Primary allocated compute. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/3b434779d30c97c8c14bd848c92d7a99c06602aa495811fe7528ed6d70e5408b-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Primary allocated compute (vCPU-hours/month) | RDS MySQL | Target scenario | OCI MySQL Database (HeatWave) | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | OCI MySQL Database (HeatWave) (one copy) | 57.44 | 57.44 | | 0 | 0.00 | OCI MySQL Database (HeatWave) (two copies) | 172.31 | 172.31 | | 1,460 | 124.83 | OCI MySQL Database (HeatWave) (one copy) | 57.44 | -67.39 | | 1,460 | 124.83 | OCI MySQL Database (HeatWave) (two copies) | 172.31 | 47.48 | | 2,920 | 249.66 | OCI MySQL Database (HeatWave) (one copy) | 110.87 | -138.79 | | 2,920 | 249.66 | OCI MySQL Database (HeatWave) (two copies) | 332.62 | 82.96 | | 5,840 | 499.32 | OCI MySQL Database (HeatWave) (one copy) | 217.74 | -281.58 | | 5,840 | 499.32 | OCI MySQL Database (HeatWave) (two copies) | 653.23 | 153.91 | | 11,680 | 998.64 | OCI MySQL Database (HeatWave) (one copy) | 431.49 | -567.15 | | 11,680 | 998.64 | OCI MySQL Database (HeatWave) (two copies) | 1,294.46 | 295.82 | | 23,360 | 1,997.28 | OCI MySQL Database (HeatWave) (one copy) | 858.98 | -1,138.30 | | 23,360 | 1,997.28 | OCI MySQL Database (HeatWave) (two copies) | 2,576.93 | 579.65 | | 46,720 | 3,994.56 | OCI MySQL Database (HeatWave) (one copy) | 1,713.95 | -2,280.61 | | 46,720 | 3,994.56 | OCI MySQL Database (HeatWave) (two copies) | 5,141.86 | 1,147.30 | Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 vCPU-hours/month to 64 vCPU, 256 GiB memory and 100 GiB SSD at 46,720 vCPU-hours/month. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | OCI MySQL Database (HeatWave) (one copy) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | OCI MySQL Database (HeatWave) (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | OCI MySQL Database (HeatWave) (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | OCI MySQL Database (HeatWave) (one copy) | Origin list price · Database reads | 0 | USD/operations | | OCI MySQL Database (HeatWave) (one copy) | Origin list price · Database writes | 0 | USD/operations | | OCI MySQL Database (HeatWave) (one copy) | Target CPU / source CPU | 1 | multiplier | | OCI MySQL Database (HeatWave) (one copy) | Target RAM / source RAM | 1 | multiplier | | OCI MySQL Database (HeatWave) (one copy) | Target disk / source disk | 1 | multiplier | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · read | 0 | USD/read | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · write | 0 | USD/write | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | OCI MySQL Database (HeatWave) (one copy) | Target list price · GiB-month | 0.04 | USD/GiB-month | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | OCI MySQL Database (HeatWave) (one copy) | Target list price · network GiB | 0 | USD/network GiB | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | OCI MySQL Database (HeatWave) (one copy) | Target list price · vCPU-hour | 0.0366 | USD/vCPU-hour | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · GiB-hour | 0 | USD/GiB-hour | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · input token | 0 | USD/input token | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · output token | 0 | USD/output token | | OCI MySQL Database (HeatWave) (one copy) | Target monthly base charge | 0 | USD/month | | OCI MySQL Database (HeatWave) (one copy) | Target service minimum | 53.436 | USD/month | | OCI MySQL Database (HeatWave) (one copy) | Minimum primary CPU | 2 | vCPU | | OCI MySQL Database (HeatWave) (one copy) | Minimum primary RAM | 8 | GiB | | OCI MySQL Database (HeatWave) (one copy) | Minimum primary disk | 100 | GiB | | OCI MySQL Database (HeatWave) (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | OCI MySQL Database (HeatWave) (one copy) | Allocated share of provisioned cost | 1 | fraction | | OCI MySQL Database (HeatWave) (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | OCI MySQL Database (HeatWave) (one copy) | Planning peak / mean work | 2 | multiplier | | OCI MySQL Database (HeatWave) (one copy) | Planning primary CPU utilization | 0.7 | fraction | | OCI MySQL Database (HeatWave) (one copy) | Resident state reserved in RAM | 0.1 | fraction | | OCI MySQL Database (HeatWave) (one copy) | Planning disk utilization | 0.8 | fraction | | OCI MySQL Database (HeatWave) (one copy) | Maintenance and log disk reserve | 20 | GiB | | OCI MySQL Database (HeatWave) (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | OCI MySQL Database (HeatWave) (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | OCI MySQL Database (HeatWave) (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | OCI MySQL Database (HeatWave) (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | OCI MySQL Database (HeatWave) (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | OCI MySQL Database (HeatWave) (two copies) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | OCI MySQL Database (HeatWave) (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | OCI MySQL Database (HeatWave) (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | OCI MySQL Database (HeatWave) (two copies) | Origin list price · Database reads | 0 | USD/operations | | OCI MySQL Database (HeatWave) (two copies) | Origin list price · Database writes | 0 | USD/operations | | OCI MySQL Database (HeatWave) (two copies) | Target CPU / source CPU | 1 | multiplier | | OCI MySQL Database (HeatWave) (two copies) | Target RAM / source RAM | 1 | multiplier | | OCI MySQL Database (HeatWave) (two copies) | Target disk / source disk | 1 | multiplier | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · read | 0 | USD/read | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · write | 0 | USD/write | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | OCI MySQL Database (HeatWave) (two copies) | Target list price · GiB-month | 0.04 | USD/GiB-month | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | OCI MySQL Database (HeatWave) (two copies) | Target list price · network GiB | 0 | USD/network GiB | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | OCI MySQL Database (HeatWave) (two copies) | Target list price · vCPU-hour | 0.0366 | USD/vCPU-hour | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · GiB-hour | 0 | USD/GiB-hour | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · input token | 0 | USD/input token | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · output token | 0 | USD/output token | | OCI MySQL Database (HeatWave) (two copies) | Target monthly base charge | 0 | USD/month | | OCI MySQL Database (HeatWave) (two copies) | Target service minimum | 53.436 | USD/month | | OCI MySQL Database (HeatWave) (two copies) | Minimum primary CPU | 2 | vCPU | | OCI MySQL Database (HeatWave) (two copies) | Minimum primary RAM | 8 | GiB | | OCI MySQL Database (HeatWave) (two copies) | Minimum primary disk | 100 | GiB | | OCI MySQL Database (HeatWave) (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | OCI MySQL Database (HeatWave) (two copies) | Allocated share of provisioned cost | 1 | fraction | | OCI MySQL Database (HeatWave) (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | OCI MySQL Database (HeatWave) (two copies) | Planning peak / mean work | 2 | multiplier | | OCI MySQL Database (HeatWave) (two copies) | Planning primary CPU utilization | 0.7 | fraction | | OCI MySQL Database (HeatWave) (two copies) | Resident state reserved in RAM | 0.1 | fraction | | OCI MySQL Database (HeatWave) (two copies) | Planning disk utilization | 0.8 | fraction | | OCI MySQL Database (HeatWave) (two copies) | Maintenance and log disk reserve | 20 | GiB | | OCI MySQL Database (HeatWave) (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | OCI MySQL Database (HeatWave) (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | OCI MySQL Database (HeatWave) (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | OCI MySQL Database (HeatWave) (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | OCI MySQL Database (HeatWave) (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * CPU allocation does not imply an achieved transaction rate. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements. * Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-ashburn-1 (global list), USD/month. * Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded. * Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied. * Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * OCI HeatWave MySQL bills ECPUs per hour with 8 GiB of memory included per ECPU (MySQL.2 is 2 ECPU and 16 GiB; [https://docs.oracle.com/en-us/iaas/mysql-database/doc/supported-shapes.html](https://docs.oracle.com/en-us/iaas/mysql-database/doc/supported-shapes.html)), so memory has no separate rate and one ECPU is treated as one vCPU; a sizing above 8 GiB per vCPU needs a larger shape this rate does not add. A high-availability DB system runs three instances ([https://docs.oracle.com/en-us/iaas/mysql-database/doc/overview-high-availability.html](https://docs.oracle.com/en-us/iaas/mysql-database/doc/overview-high-availability.html)), so a standby selection adds two copies of compute and storage. HeatWave clusters, backups and the MySQL.Free shape are not selected. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: MySQL.96 has 96 ECPUs and 768 GiB ([https://docs.oracle.com/en-us/iaas/mysql-database/doc/supported-shapes.html](https://docs.oracle.com/en-us/iaas/mysql-database/doc/supported-shapes.html)); storage reaches 32 TiB from a small initial size ([https://docs.oracle.com/en-us/iaas/mysql-database/doc/db-system-storage.html](https://docs.oracle.com/en-us/iaas/mysql-database/doc/db-system-storage.html)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonRDS offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json) * OCI price list API: [https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/](https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/) Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. List prices read: 2026-10-22. Model: `plan-ca5859d924b1dc2b224b756d50f256b36b5e6d19` / `2026-10-22.planning.2`. Curve: `workload-1`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [OCI price list API](https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/). ##### RDS MySQL · Stored data Feature: RDS MySQL. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1 (global list); currency: USD. ![RDS MySQL · Stored data: monthly service charges by Stored data. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/4ecc1f8d28940f3245e55f62e5cab94a6420687f6d23ed7c873a547bd25bc6d8-light.svg) ![RDS MySQL · Stored data: monthly service charges by Stored data. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/0deb1340cbb66e7ec5ad1134821361a9fbfad6b86836a0bc439bd356f3877a5d-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Stored data (GiB-month) | RDS MySQL | Target scenario | OCI MySQL Database (HeatWave) | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | OCI MySQL Database (HeatWave) (one copy) | 57.44 | 57.44 | | 0 | 0.00 | OCI MySQL Database (HeatWave) (two copies) | 172.31 | 172.31 | | 10 | 1.15 | OCI MySQL Database (HeatWave) (one copy) | 57.44 | 56.29 | | 10 | 1.15 | OCI MySQL Database (HeatWave) (two copies) | 172.31 | 171.16 | | 100 | 11.50 | OCI MySQL Database (HeatWave) (one copy) | 59.44 | 47.94 | | 100 | 11.50 | OCI MySQL Database (HeatWave) (two copies) | 178.31 | 166.81 | | 1,000 | 115.00 | OCI MySQL Database (HeatWave) (one copy) | 104.44 | -10.56 | | 1,000 | 115.00 | OCI MySQL Database (HeatWave) (two copies) | 313.31 | 198.31 | | 10,000 | 1,150.00 | OCI MySQL Database (HeatWave) (one copy) | 554.44 | -595.56 | | 10,000 | 1,150.00 | OCI MySQL Database (HeatWave) (two copies) | 1,663.31 | 513.31 | | 100,000 | 11,500.00 | OCI MySQL Database (HeatWave) (one copy) | Unpriced | Unavailable | | 100,000 | 11,500.00 | OCI MySQL Database (HeatWave) (two copies) | Unpriced | Unavailable | Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 GiB-month to 2 vCPU, 8 GiB memory and 12,525 GiB SSD at 10,000 GiB-month. From 100,000 GiB-month the workload exceeds the planning range and the target is unpriced. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | OCI MySQL Database (HeatWave) (one copy) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | OCI MySQL Database (HeatWave) (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | OCI MySQL Database (HeatWave) (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | OCI MySQL Database (HeatWave) (one copy) | Origin list price · Database reads | 0 | USD/operations | | OCI MySQL Database (HeatWave) (one copy) | Origin list price · Database writes | 0 | USD/operations | | OCI MySQL Database (HeatWave) (one copy) | Target CPU / source CPU | 1 | multiplier | | OCI MySQL Database (HeatWave) (one copy) | Target RAM / source RAM | 1 | multiplier | | OCI MySQL Database (HeatWave) (one copy) | Target disk / source disk | 1 | multiplier | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · read | 0 | USD/read | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · write | 0 | USD/write | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | OCI MySQL Database (HeatWave) (one copy) | Target list price · GiB-month | 0.04 | USD/GiB-month | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | OCI MySQL Database (HeatWave) (one copy) | Target list price · network GiB | 0 | USD/network GiB | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | OCI MySQL Database (HeatWave) (one copy) | Target list price · vCPU-hour | 0.0366 | USD/vCPU-hour | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · GiB-hour | 0 | USD/GiB-hour | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · input token | 0 | USD/input token | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · output token | 0 | USD/output token | | OCI MySQL Database (HeatWave) (one copy) | Target monthly base charge | 0 | USD/month | | OCI MySQL Database (HeatWave) (one copy) | Target service minimum | 53.436 | USD/month | | OCI MySQL Database (HeatWave) (one copy) | Minimum primary CPU | 2 | vCPU | | OCI MySQL Database (HeatWave) (one copy) | Minimum primary RAM | 8 | GiB | | OCI MySQL Database (HeatWave) (one copy) | Minimum primary disk | 100 | GiB | | OCI MySQL Database (HeatWave) (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | OCI MySQL Database (HeatWave) (one copy) | Allocated share of provisioned cost | 1 | fraction | | OCI MySQL Database (HeatWave) (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | OCI MySQL Database (HeatWave) (one copy) | Planning peak / mean work | 2 | multiplier | | OCI MySQL Database (HeatWave) (one copy) | Planning primary CPU utilization | 0.7 | fraction | | OCI MySQL Database (HeatWave) (one copy) | Resident state reserved in RAM | 0.1 | fraction | | OCI MySQL Database (HeatWave) (one copy) | Planning disk utilization | 0.8 | fraction | | OCI MySQL Database (HeatWave) (one copy) | Maintenance and log disk reserve | 20 | GiB | | OCI MySQL Database (HeatWave) (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | OCI MySQL Database (HeatWave) (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | OCI MySQL Database (HeatWave) (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | OCI MySQL Database (HeatWave) (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | OCI MySQL Database (HeatWave) (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | OCI MySQL Database (HeatWave) (two copies) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | OCI MySQL Database (HeatWave) (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | OCI MySQL Database (HeatWave) (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | OCI MySQL Database (HeatWave) (two copies) | Origin list price · Database reads | 0 | USD/operations | | OCI MySQL Database (HeatWave) (two copies) | Origin list price · Database writes | 0 | USD/operations | | OCI MySQL Database (HeatWave) (two copies) | Target CPU / source CPU | 1 | multiplier | | OCI MySQL Database (HeatWave) (two copies) | Target RAM / source RAM | 1 | multiplier | | OCI MySQL Database (HeatWave) (two copies) | Target disk / source disk | 1 | multiplier | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · read | 0 | USD/read | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · write | 0 | USD/write | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | OCI MySQL Database (HeatWave) (two copies) | Target list price · GiB-month | 0.04 | USD/GiB-month | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | OCI MySQL Database (HeatWave) (two copies) | Target list price · network GiB | 0 | USD/network GiB | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | OCI MySQL Database (HeatWave) (two copies) | Target list price · vCPU-hour | 0.0366 | USD/vCPU-hour | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · GiB-hour | 0 | USD/GiB-hour | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · input token | 0 | USD/input token | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · output token | 0 | USD/output token | | OCI MySQL Database (HeatWave) (two copies) | Target monthly base charge | 0 | USD/month | | OCI MySQL Database (HeatWave) (two copies) | Target service minimum | 53.436 | USD/month | | OCI MySQL Database (HeatWave) (two copies) | Minimum primary CPU | 2 | vCPU | | OCI MySQL Database (HeatWave) (two copies) | Minimum primary RAM | 8 | GiB | | OCI MySQL Database (HeatWave) (two copies) | Minimum primary disk | 100 | GiB | | OCI MySQL Database (HeatWave) (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | OCI MySQL Database (HeatWave) (two copies) | Allocated share of provisioned cost | 1 | fraction | | OCI MySQL Database (HeatWave) (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | OCI MySQL Database (HeatWave) (two copies) | Planning peak / mean work | 2 | multiplier | | OCI MySQL Database (HeatWave) (two copies) | Planning primary CPU utilization | 0.7 | fraction | | OCI MySQL Database (HeatWave) (two copies) | Resident state reserved in RAM | 0.1 | fraction | | OCI MySQL Database (HeatWave) (two copies) | Planning disk utilization | 0.8 | fraction | | OCI MySQL Database (HeatWave) (two copies) | Maintenance and log disk reserve | 20 | GiB | | OCI MySQL Database (HeatWave) (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | OCI MySQL Database (HeatWave) (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | OCI MySQL Database (HeatWave) (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | OCI MySQL Database (HeatWave) (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | OCI MySQL Database (HeatWave) (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * Request meters remain at their independently authored defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements. * Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-ashburn-1 (global list), USD/month. * Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded. * Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied. * Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * OCI HeatWave MySQL bills ECPUs per hour with 8 GiB of memory included per ECPU (MySQL.2 is 2 ECPU and 16 GiB; [https://docs.oracle.com/en-us/iaas/mysql-database/doc/supported-shapes.html](https://docs.oracle.com/en-us/iaas/mysql-database/doc/supported-shapes.html)), so memory has no separate rate and one ECPU is treated as one vCPU; a sizing above 8 GiB per vCPU needs a larger shape this rate does not add. A high-availability DB system runs three instances ([https://docs.oracle.com/en-us/iaas/mysql-database/doc/overview-high-availability.html](https://docs.oracle.com/en-us/iaas/mysql-database/doc/overview-high-availability.html)), so a standby selection adds two copies of compute and storage. HeatWave clusters, backups and the MySQL.Free shape are not selected. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: MySQL.96 has 96 ECPUs and 768 GiB ([https://docs.oracle.com/en-us/iaas/mysql-database/doc/supported-shapes.html](https://docs.oracle.com/en-us/iaas/mysql-database/doc/supported-shapes.html)); storage reaches 32 TiB from a small initial size ([https://docs.oracle.com/en-us/iaas/mysql-database/doc/db-system-storage.html](https://docs.oracle.com/en-us/iaas/mysql-database/doc/db-system-storage.html)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonRDS offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json) * OCI price list API: [https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/](https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/) Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. List prices read: 2026-10-22. Model: `plan-ca5859d924b1dc2b224b756d50f256b36b5e6d19` / `2026-10-22.planning.2`. Curve: `workload-2`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [OCI price list API](https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/). ##### RDS MySQL · Database writes Feature: RDS MySQL. Estimated monthly service charges by Database writes. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1 (global list); currency: USD. ![RDS MySQL · Database writes: monthly service charges by Database writes. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/82bedcc0abcbd4ac50c51494866641cef7d01f34c09b90ea288b35a12674f728-light.svg) ![RDS MySQL · Database writes: monthly service charges by Database writes. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/56410e992516b845567774325b2adb7efe3657c9a961ca4e64594a3572869954-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Database writes (per second) | RDS MySQL | Target scenario | OCI MySQL Database (HeatWave) | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | OCI MySQL Database (HeatWave) (one copy) | 57.44 | 57.44 | | 0 | 0.00 | OCI MySQL Database (HeatWave) (two copies) | 172.31 | 172.31 | | 1 | 0.00 | OCI MySQL Database (HeatWave) (one copy) | 57.44 | 57.44 | | 1 | 0.00 | OCI MySQL Database (HeatWave) (two copies) | 172.31 | 172.31 | | 10 | 0.00 | OCI MySQL Database (HeatWave) (one copy) | 57.44 | 57.44 | | 10 | 0.00 | OCI MySQL Database (HeatWave) (two copies) | 172.31 | 172.31 | | 100 | 0.00 | OCI MySQL Database (HeatWave) (one copy) | 57.44 | 57.44 | | 100 | 0.00 | OCI MySQL Database (HeatWave) (two copies) | 172.31 | 172.31 | | 1,000 | 0.00 | OCI MySQL Database (HeatWave) (one copy) | 57.44 | 57.44 | | 1,000 | 0.00 | OCI MySQL Database (HeatWave) (two copies) | 172.31 | 172.31 | | 10,000 | 0.00 | OCI MySQL Database (HeatWave) (one copy) | 57.44 | 57.44 | | 10,000 | 0.00 | OCI MySQL Database (HeatWave) (two copies) | 172.31 | 172.31 | Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | OCI MySQL Database (HeatWave) (one copy) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | OCI MySQL Database (HeatWave) (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | OCI MySQL Database (HeatWave) (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | OCI MySQL Database (HeatWave) (one copy) | Origin list price · Database reads | 0 | USD/operations | | OCI MySQL Database (HeatWave) (one copy) | Origin list price · Database writes | 0 | USD/operations | | OCI MySQL Database (HeatWave) (one copy) | Target CPU / source CPU | 1 | multiplier | | OCI MySQL Database (HeatWave) (one copy) | Target RAM / source RAM | 1 | multiplier | | OCI MySQL Database (HeatWave) (one copy) | Target disk / source disk | 1 | multiplier | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · read | 0 | USD/read | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · write | 0 | USD/write | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | OCI MySQL Database (HeatWave) (one copy) | Target list price · GiB-month | 0.04 | USD/GiB-month | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | OCI MySQL Database (HeatWave) (one copy) | Target list price · network GiB | 0 | USD/network GiB | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | OCI MySQL Database (HeatWave) (one copy) | Target list price · vCPU-hour | 0.0366 | USD/vCPU-hour | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · GiB-hour | 0 | USD/GiB-hour | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · input token | 0 | USD/input token | | OCI MySQL Database (HeatWave) (one copy) | Target price guess · output token | 0 | USD/output token | | OCI MySQL Database (HeatWave) (one copy) | Target monthly base charge | 0 | USD/month | | OCI MySQL Database (HeatWave) (one copy) | Target service minimum | 53.436 | USD/month | | OCI MySQL Database (HeatWave) (one copy) | Minimum primary CPU | 2 | vCPU | | OCI MySQL Database (HeatWave) (one copy) | Minimum primary RAM | 8 | GiB | | OCI MySQL Database (HeatWave) (one copy) | Minimum primary disk | 100 | GiB | | OCI MySQL Database (HeatWave) (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | OCI MySQL Database (HeatWave) (one copy) | Allocated share of provisioned cost | 1 | fraction | | OCI MySQL Database (HeatWave) (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | OCI MySQL Database (HeatWave) (one copy) | Planning peak / mean work | 2 | multiplier | | OCI MySQL Database (HeatWave) (one copy) | Planning primary CPU utilization | 0.7 | fraction | | OCI MySQL Database (HeatWave) (one copy) | Resident state reserved in RAM | 0.1 | fraction | | OCI MySQL Database (HeatWave) (one copy) | Planning disk utilization | 0.8 | fraction | | OCI MySQL Database (HeatWave) (one copy) | Maintenance and log disk reserve | 20 | GiB | | OCI MySQL Database (HeatWave) (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | OCI MySQL Database (HeatWave) (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | OCI MySQL Database (HeatWave) (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | OCI MySQL Database (HeatWave) (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | OCI MySQL Database (HeatWave) (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | OCI MySQL Database (HeatWave) (two copies) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | OCI MySQL Database (HeatWave) (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | OCI MySQL Database (HeatWave) (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | OCI MySQL Database (HeatWave) (two copies) | Origin list price · Database reads | 0 | USD/operations | | OCI MySQL Database (HeatWave) (two copies) | Origin list price · Database writes | 0 | USD/operations | | OCI MySQL Database (HeatWave) (two copies) | Target CPU / source CPU | 1 | multiplier | | OCI MySQL Database (HeatWave) (two copies) | Target RAM / source RAM | 1 | multiplier | | OCI MySQL Database (HeatWave) (two copies) | Target disk / source disk | 1 | multiplier | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · read | 0 | USD/read | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · write | 0 | USD/write | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | OCI MySQL Database (HeatWave) (two copies) | Target list price · GiB-month | 0.04 | USD/GiB-month | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | OCI MySQL Database (HeatWave) (two copies) | Target list price · network GiB | 0 | USD/network GiB | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | OCI MySQL Database (HeatWave) (two copies) | Target list price · vCPU-hour | 0.0366 | USD/vCPU-hour | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · GiB-hour | 0 | USD/GiB-hour | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · input token | 0 | USD/input token | | OCI MySQL Database (HeatWave) (two copies) | Target price guess · output token | 0 | USD/output token | | OCI MySQL Database (HeatWave) (two copies) | Target monthly base charge | 0 | USD/month | | OCI MySQL Database (HeatWave) (two copies) | Target service minimum | 53.436 | USD/month | | OCI MySQL Database (HeatWave) (two copies) | Minimum primary CPU | 2 | vCPU | | OCI MySQL Database (HeatWave) (two copies) | Minimum primary RAM | 8 | GiB | | OCI MySQL Database (HeatWave) (two copies) | Minimum primary disk | 100 | GiB | | OCI MySQL Database (HeatWave) (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | OCI MySQL Database (HeatWave) (two copies) | Allocated share of provisioned cost | 1 | fraction | | OCI MySQL Database (HeatWave) (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | OCI MySQL Database (HeatWave) (two copies) | Planning peak / mean work | 2 | multiplier | | OCI MySQL Database (HeatWave) (two copies) | Planning primary CPU utilization | 0.7 | fraction | | OCI MySQL Database (HeatWave) (two copies) | Resident state reserved in RAM | 0.1 | fraction | | OCI MySQL Database (HeatWave) (two copies) | Planning disk utilization | 0.8 | fraction | | OCI MySQL Database (HeatWave) (two copies) | Maintenance and log disk reserve | 20 | GiB | | OCI MySQL Database (HeatWave) (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | OCI MySQL Database (HeatWave) (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | OCI MySQL Database (HeatWave) (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | OCI MySQL Database (HeatWave) (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | OCI MySQL Database (HeatWave) (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * Source compute and stored data remain independent; a throughput view needs explicit workload inputs. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements. * Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-ashburn-1 (global list), USD/month. * Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded. * Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied. * Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * OCI HeatWave MySQL bills ECPUs per hour with 8 GiB of memory included per ECPU (MySQL.2 is 2 ECPU and 16 GiB; [https://docs.oracle.com/en-us/iaas/mysql-database/doc/supported-shapes.html](https://docs.oracle.com/en-us/iaas/mysql-database/doc/supported-shapes.html)), so memory has no separate rate and one ECPU is treated as one vCPU; a sizing above 8 GiB per vCPU needs a larger shape this rate does not add. A high-availability DB system runs three instances ([https://docs.oracle.com/en-us/iaas/mysql-database/doc/overview-high-availability.html](https://docs.oracle.com/en-us/iaas/mysql-database/doc/overview-high-availability.html)), so a standby selection adds two copies of compute and storage. HeatWave clusters, backups and the MySQL.Free shape are not selected. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: MySQL.96 has 96 ECPUs and 768 GiB ([https://docs.oracle.com/en-us/iaas/mysql-database/doc/supported-shapes.html](https://docs.oracle.com/en-us/iaas/mysql-database/doc/supported-shapes.html)); storage reaches 32 TiB from a small initial size ([https://docs.oracle.com/en-us/iaas/mysql-database/doc/db-system-storage.html](https://docs.oracle.com/en-us/iaas/mysql-database/doc/db-system-storage.html)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonRDS offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json) * OCI price list API: [https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/](https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/) Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. List prices read: 2026-10-22. Model: `plan-ca5859d924b1dc2b224b756d50f256b36b5e6d19` / `2026-10-22.planning.2`. Curve: `workload-3`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [OCI price list API](https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/). **RDS MySQL → OCI MySQL Database (HeatWave): Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: us-ashburn-1 (global list). Currency: USD. | Monthly component | USD | | - | -: | | Origin: Primary compute | 0.00 | | Origin: Primary memory | 0.00 | | Origin: Primary provisioned storage | 0.00 | | Origin: Database reads | 0.00 | | Origin: Database writes | 0.00 | | Target: Provisioned primary CPU | 53.44 | | Target: Provisioned primary RAM | 0.00 | | Target: Provisioned primary disk | 4.00 | | Target: Selected billable network | 0.00 | | Target: Independent provisioned resources | 0.00 | | Target: Independent managed resources | 0.00 | | **Origin service subtotal** | **0.00** | | **Target service subtotal** | **57.44** | Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. **Scenario assumptions** | Input | Value | Unit | | - | -: | - | | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Origin list price · Primary memory | 0 | USD/GiB-hours | | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Origin list price · Database reads | 0 | USD/operations | | Origin list price · Database writes | 0 | USD/operations | | Target CPU / source CPU | 1 | multiplier | | Target RAM / source RAM | 1 | multiplier | | Target disk / source disk | 1 | multiplier | | Target price guess · read | 0 | USD/read | | Target price guess · write | 0 | USD/write | | Target price guess · provider operation | 0 | USD/provider operation | | Target list price · GiB-month | 0.04 | USD/GiB-month | | Target price guess · published GiB | 0 | USD/published GiB | | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Target list price · network GiB | 0 | USD/network GiB | | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Target list price · vCPU-hour | 0.0366 | USD/vCPU-hour | | Target price guess · GiB-hour | 0 | USD/GiB-hour | | Target price guess · resource-hour | 0 | USD/resource-hour | | Target price guess · resource-month | 0 | USD/resource-month | | Target price guess · input token | 0 | USD/input token | | Target price guess · output token | 0 | USD/output token | | Target monthly base charge | 0 | USD/month | | Target service minimum | 53.436 | USD/month | | Minimum primary CPU | 2 | vCPU | | Minimum primary RAM | 8 | GiB | | Minimum primary disk | 100 | GiB | | Additional full-price standby copy | 0 | 0 or 1 | | Allocated share of provisioned cost | 1 | fraction | | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Planning peak / mean work | 2 | multiplier | | Planning primary CPU utilization | 0.7 | fraction | | Resident state reserved in RAM | 0.1 | fraction | | Planning disk utilization | 0.8 | fraction | | Maintenance and log disk reserve | 20 | GiB | | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Dependent object sink write price guess | 0.000005 | USD/write | | Primary compute | 0 | vCPU-hours | | Primary memory | 0 | GiB-hours | | Primary provisioned storage | 0 | GiB-month | | Database reads | 0 | operations | | Database writes | 0 | operations | * Translated reads: 0 operations. * Translated writes: 0 operations. * Translated resident physical data: 0 GiB-month. * Native provider operations: 0 operations. * Published payload: 0 GiB. * Delivered payload: 0 GiB. * Allocated execution CPU: 0 vCPU-hour. * Allocated execution RAM: 0 GiB-hour. * Independent resource allocation: 0 resource-hour. * Independent inventory: 0 resource-month. * Input tokens: 0 tokens. * Output tokens: 0 tokens. * Billable network: 0 GiB. * Dependent object sink retained data: 0 GiB-month. * Dependent object sink writes: 0 writes. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * OCI HeatWave MySQL bills ECPUs per hour with 8 GiB of memory included per ECPU (MySQL.2 is 2 ECPU and 16 GiB; [https://docs.oracle.com/en-us/iaas/mysql-database/doc/supported-shapes.html](https://docs.oracle.com/en-us/iaas/mysql-database/doc/supported-shapes.html)), so memory has no separate rate and one ECPU is treated as one vCPU; a sizing above 8 GiB per vCPU needs a larger shape this rate does not add. A high-availability DB system runs three instances ([https://docs.oracle.com/en-us/iaas/mysql-database/doc/overview-high-availability.html](https://docs.oracle.com/en-us/iaas/mysql-database/doc/overview-high-availability.html)), so a standby selection adds two copies of compute and storage. HeatWave clusters, backups and the MySQL.Free shape are not selected. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: MySQL.96 has 96 ECPUs and 768 GiB ([https://docs.oracle.com/en-us/iaas/mysql-database/doc/supported-shapes.html](https://docs.oracle.com/en-us/iaas/mysql-database/doc/supported-shapes.html)); storage reaches 32 TiB from a small initial size ([https://docs.oracle.com/en-us/iaas/mysql-database/doc/db-system-storage.html](https://docs.oracle.com/en-us/iaas/mysql-database/doc/db-system-storage.html)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. List prices read: 2026-10-22. Model: `plan-ca5859d924b1dc2b224b756d50f256b36b5e6d19` / `2026-10-22.planning.2`. Scenario: `planning-example`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [OCI price list API](https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/). ## On Private Kubernetes and Scaleway ### Percona XtraDB Cluster (MySQL) | Operation | Area | Support | Depth | Notes | | - | - | - | - | - | | AWS integration SQL: LOAD DATA FROM S3 / SELECT INTO OUTFILE S3, mysql.lambda\_async, mysql.rds\_\* procedures | SQL functions | Out of scope | Full surface | RDS MySQL extension procedures with no counterpart on vanilla MySQL; a query calling them fails | | MySQL client/server protocol (application SQL) | Wire protocol | Supported | Common | same MySQL engine; application SQL is unchanged | #### How it works An `aws_db_instance` with `engine = "mysql"` becomes a `PerconaXtraDBCluster` resource (`pxc.percona.com/v1`), from which the Percona operator runs a Galera cluster on Kubernetes. Your application keeps its MySQL driver and connects straight to the cluster's HAProxy endpoint; Tensor9 adds no proxy or protocol translation to that connection. Your application sends SQL over the MySQL protocol; these requests are the **data plane**. RDS management requests, the **control plane**, go to Tensor9 in the customer's Cloud Adapter deployment, which turns requests for snapshots, restores, replicas, failover and configuration changes into changes to the Percona operator's Kubernetes resources. ![Before: on AWS, your app talks to an RDS for MySQL instance over the MySQL protocol. After: in the Kubernetes cluster, the same app and driver talk the same MySQL protocol to an HAProxy endpoint in front of three Percona XtraDB Cluster pods, with nothing from Tensor9 in between.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjE0IiB2aWV3Qm94PSIwIDAgODM2IDIxNCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJCZWZvcmU6IG9uIEFXUywgeW91ciBhcHAgdGFsa3MgdG8gYW4gUkRTIGZvciBNeVNRTCBpbnN0YW5jZSBvdmVyIHRoZSBNeVNRTCBwcm90b2NvbC4gQWZ0ZXI6IGluIHRoZSBLdWJlcm5ldGVzIGNsdXN0ZXIsIHRoZSBzYW1lIGFwcCBhbmQgZHJpdmVyIHRhbGsgdGhlIHNhbWUgTXlTUUwgcHJvdG9jb2wgdG8gYW4gSEFQcm94eSBlbmRwb2ludCBpbiBmcm9udCBvZiB0aHJlZSBQZXJjb25hIFh0cmFEQiBDbHVzdGVyIHBvZHMsIHdpdGggbm90aGluZyBmcm9tIFRlbnNvcjkgaW4gYmV0d2Vlbi4iPjxzdHlsZT50ZXh0e2ZvbnQtZmFtaWx5OkludGVyLC1hcHBsZS1zeXN0ZW0sQmxpbmtNYWNTeXN0ZW1Gb250LCdTZWdvZSBVSScsUm9ib3RvLCdIZWx2ZXRpY2EgTmV1ZScsQXJpYWwsc2Fucy1zZXJpZjtmaWxsOiMzMzQxNTV9PC9zdHlsZT4KPGRlZnM+PG1hcmtlciBpZD0icHhjMWgiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjYuNSIgbWFya2VySGVpZ2h0PSI2LjUiIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM5NGEzYjgiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjE2IiB5PSI0NCIgd2lkdGg9IjM4MCIgaGVpZ2h0PSIxNTAiIHJ4PSIxNCIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0cm9rZS1kYXNoYXJyYXk9IjUgNSIgc3R5bGU9ImZpbGw6I2Y4ZmFmYztzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSIzMiIgeT0iNjYiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4Ij5PTiBBV1MgVE9EQVk8L3RleHQ+CjxyZWN0IHg9IjM2IiB5PSI5MiIgd2lkdGg9IjE1MCIgaGVpZ2h0PSI1OCIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSIxMTEiIHk9IjExOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmEiPllvdXIgYXBwPC90ZXh0Pgo8dGV4dCB4PSIxMTEiIHk9IjEzNSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPk15U1FMIGRyaXZlcjwvdGV4dD4KPGxpbmUgeDE9IjE4NiIgeTE9IjEyMSIgeDI9IjIyMCIgeTI9IjEyMSIgc3Ryb2tlLXdpZHRoPSIxLjgiIG1hcmtlci1lbmQ9InVybCgjcHhjMWgpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iMjAzIiB5PSIxMTMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmb250LXNpemU6OC41cHgiPk15U1FMPC90ZXh0Pgo8cmVjdCB4PSIyMjIiIHk9IjkyIiB3aWR0aD0iMTU4IiBoZWlnaHQ9IjU4IiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjMwMSIgeT0iMTE2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjEycHgiPlJEUyBmb3IgTXlTUUw8L3RleHQ+Cjx0ZXh0IHg9IjMwMSIgeT0iMTM0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzMzNDE1NSI+YXdzX2RiX2luc3RhbmNlPC90ZXh0Pgo8cmVjdCB4PSI0NDAiIHk9IjQ0IiB3aWR0aD0iMzgwIiBoZWlnaHQ9IjE1MCIgcng9IjE0IiBzdHJva2Utd2lkdGg9IjEuNCIgc3Ryb2tlLWRhc2hhcnJheT0iNSA1IiBzdHlsZT0iZmlsbDojZjhmYWZjO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjQ1NiIgeT0iNjYiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4OyBmaWxsOiMwNDc4NTciPklOIFRIRSBUQVJHRVQgQ0xVU1RFUjwvdGV4dD4KPHJlY3QgeD0iNDU2IiB5PSI5MiIgd2lkdGg9IjEyMCIgaGVpZ2h0PSI1OCIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSI1MTYiIHk9IjExOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMnB4Ij5Zb3VyIGFwcDwvdGV4dD4KPHRleHQgeD0iNTE2IiB5PSIxMzUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2MDAgMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+c2FtZSBkcml2ZXI8L3RleHQ+CjxsaW5lIHgxPSI1NzYiIHkxPSIxMjEiIHgyPSI2MDQiIHkyPSIxMjEiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItZW5kPSJ1cmwoI3B4YzFoKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjU5MCIgeT0iMTEzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjguNXB4Ij5NeVNRTDwvdGV4dD4KPHJlY3QgeD0iNjA2IiB5PSI3NiIgd2lkdGg9IjIwMCIgaGVpZ2h0PSIxMTAiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iNzA2IiB5PSI5NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTc7IGZvbnQtc2l6ZToxMS41cHgiPlBlcmNvbmFYdHJhREJDbHVzdGVyPC90ZXh0Pgo8cmVjdCB4PSI2MjAiIHk9IjEwMiIgd2lkdGg9IjE3MiIgaGVpZ2h0PSIyNCIgcng9IjciIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojYTdmM2QwIi8+Cjx0ZXh0IHg9IjcwNiIgeT0iMTE4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzMzNDE1NTsgZmlsbDojMDQ3ODU3Ij5IQVByb3h5IGVuZHBvaW50PC90ZXh0Pgo8cmVjdCB4PSI2MjAiIHk9IjEzNCIgd2lkdGg9IjUyIiBoZWlnaHQ9IjQwIiByeD0iNyIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNhN2YzZDAiLz4KPHRleHQgeD0iNjQ2IiB5PSIxNTgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjMzM0MTU1OyBmb250LXNpemU6OXB4Ij5weGMtMDwvdGV4dD4KPHJlY3QgeD0iNjc4IiB5PSIxMzQiIHdpZHRoPSI1MiIgaGVpZ2h0PSI0MCIgcng9IjciIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojYTdmM2QwIi8+Cjx0ZXh0IHg9IjcwNCIgeT0iMTU4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzMzNDE1NTsgZm9udC1zaXplOjlweCI+cHhjLTE8L3RleHQ+CjxyZWN0IHg9IjczNiIgeT0iMTM0IiB3aWR0aD0iNTIiIGhlaWdodD0iNDAiIHJ4PSI3IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2E3ZjNkMCIvPgo8dGV4dCB4PSI3NjIiIHk9IjE1OCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICMzMzQxNTU7IGZvbnQtc2l6ZTo5cHgiPnB4Yy0yPC90ZXh0Pgo8L3N2Zz4=) ![Before: on AWS, your app talks to an RDS for MySQL instance over the MySQL protocol. After: in the Kubernetes cluster, the same app and driver talk the same MySQL protocol to an HAProxy endpoint in front of three Percona XtraDB Cluster pods, with nothing from Tensor9 in between.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjE0IiB2aWV3Qm94PSIwIDAgODM2IDIxNCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJCZWZvcmU6IG9uIEFXUywgeW91ciBhcHAgdGFsa3MgdG8gYW4gUkRTIGZvciBNeVNRTCBpbnN0YW5jZSBvdmVyIHRoZSBNeVNRTCBwcm90b2NvbC4gQWZ0ZXI6IGluIHRoZSBLdWJlcm5ldGVzIGNsdXN0ZXIsIHRoZSBzYW1lIGFwcCBhbmQgZHJpdmVyIHRhbGsgdGhlIHNhbWUgTXlTUUwgcHJvdG9jb2wgdG8gYW4gSEFQcm94eSBlbmRwb2ludCBpbiBmcm9udCBvZiB0aHJlZSBQZXJjb25hIFh0cmFEQiBDbHVzdGVyIHBvZHMsIHdpdGggbm90aGluZyBmcm9tIFRlbnNvcjkgaW4gYmV0d2Vlbi4iPjxzdHlsZT50ZXh0e2ZvbnQtZmFtaWx5OkludGVyLC1hcHBsZS1zeXN0ZW0sQmxpbmtNYWNTeXN0ZW1Gb250LCdTZWdvZSBVSScsUm9ib3RvLCdIZWx2ZXRpY2EgTmV1ZScsQXJpYWwsc2Fucy1zZXJpZjtmaWxsOiNjYmQ1ZTF9PC9zdHlsZT4KPGRlZnM+PG1hcmtlciBpZD0icHhjMWgiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjYuNSIgbWFya2VySGVpZ2h0PSI2LjUiIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM2NDc0OGIiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjE2IiB5PSI0NCIgd2lkdGg9IjM4MCIgaGVpZ2h0PSIxNTAiIHJ4PSIxNCIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0cm9rZS1kYXNoYXJyYXk9IjUgNSIgc3R5bGU9ImZpbGw6IzBmMTcyYTtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSIzMiIgeT0iNjYiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiIj5PTiBBV1MgVE9EQVk8L3RleHQ+CjxyZWN0IHg9IjM2IiB5PSI5MiIgd2lkdGg9IjE1MCIgaGVpZ2h0PSI1OCIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSIxMTEiIHk9IjExOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1ZjkiPllvdXIgYXBwPC90ZXh0Pgo8dGV4dCB4PSIxMTEiIHk9IjEzNSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPk15U1FMIGRyaXZlcjwvdGV4dD4KPGxpbmUgeDE9IjE4NiIgeTE9IjEyMSIgeDI9IjIyMCIgeTI9IjEyMSIgc3Ryb2tlLXdpZHRoPSIxLjgiIG1hcmtlci1lbmQ9InVybCgjcHhjMWgpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iMjAzIiB5PSIxMTMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmb250LXNpemU6OC41cHgiPk15U1FMPC90ZXh0Pgo8cmVjdCB4PSIyMjIiIHk9IjkyIiB3aWR0aD0iMTU4IiBoZWlnaHQ9IjU4IiByeD0iMTEiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjMwMSIgeT0iMTE2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjEycHgiPlJEUyBmb3IgTXlTUUw8L3RleHQ+Cjx0ZXh0IHg9IjMwMSIgeT0iMTM0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogI2NiZDVlMSI+YXdzX2RiX2luc3RhbmNlPC90ZXh0Pgo8cmVjdCB4PSI0NDAiIHk9IjQ0IiB3aWR0aD0iMzgwIiBoZWlnaHQ9IjE1MCIgcng9IjE0IiBzdHJva2Utd2lkdGg9IjEuNCIgc3Ryb2tlLWRhc2hhcnJheT0iNSA1IiBzdHlsZT0iZmlsbDojMGYxNzJhO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjQ1NiIgeT0iNjYiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiM2ZWU3YjciPklOIFRIRSBUQVJHRVQgQ0xVU1RFUjwvdGV4dD4KPHJlY3QgeD0iNDU2IiB5PSI5MiIgd2lkdGg9IjEyMCIgaGVpZ2h0PSI1OCIgcng9IjExIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSI1MTYiIHk9IjExOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMnB4Ij5Zb3VyIGFwcDwvdGV4dD4KPHRleHQgeD0iNTE2IiB5PSIxMzUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2MDAgMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+c2FtZSBkcml2ZXI8L3RleHQ+CjxsaW5lIHgxPSI1NzYiIHkxPSIxMjEiIHgyPSI2MDQiIHkyPSIxMjEiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItZW5kPSJ1cmwoI3B4YzFoKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjU5MCIgeT0iMTEzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjguNXB4Ij5NeVNRTDwvdGV4dD4KPHJlY3QgeD0iNjA2IiB5PSI3NiIgd2lkdGg9IjIwMCIgaGVpZ2h0PSIxMTAiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iNzA2IiB5PSI5NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3Yjc7IGZvbnQtc2l6ZToxMS41cHgiPlBlcmNvbmFYdHJhREJDbHVzdGVyPC90ZXh0Pgo8cmVjdCB4PSI2MjAiIHk9IjEwMiIgd2lkdGg9IjE3MiIgaGVpZ2h0PSIyNCIgcng9IjciIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjcwNiIgeT0iMTE4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogI2NiZDVlMTsgZmlsbDojNmVlN2I3Ij5IQVByb3h5IGVuZHBvaW50PC90ZXh0Pgo8cmVjdCB4PSI2MjAiIHk9IjEzNCIgd2lkdGg9IjUyIiBoZWlnaHQ9IjQwIiByeD0iNyIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iNjQ2IiB5PSIxNTgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjY2JkNWUxOyBmb250LXNpemU6OXB4Ij5weGMtMDwvdGV4dD4KPHJlY3QgeD0iNjc4IiB5PSIxMzQiIHdpZHRoPSI1MiIgaGVpZ2h0PSI0MCIgcng9IjciIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjcwNCIgeT0iMTU4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogI2NiZDVlMTsgZm9udC1zaXplOjlweCI+cHhjLTE8L3RleHQ+CjxyZWN0IHg9IjczNiIgeT0iMTM0IiB3aWR0aD0iNTIiIGhlaWdodD0iNDAiIHJ4PSI3IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI3NjIiIHk9IjE1OCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICNjYmQ1ZTE7IGZvbnQtc2l6ZTo5cHgiPnB4Yy0yPC90ZXh0Pgo8L3N2Zz4=) Your app keeps its driver and reaches a three-node Percona cluster through HAProxy over the 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. ![Three Percona nodes replicate transaction changes using Galera. A majority must remain connected for the cluster to accept writes.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTkwIiB2aWV3Qm94PSIwIDAgODM2IDE5MCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaHJlZSBQZXJjb25hIG5vZGVzIHJlcGxpY2F0ZSB0cmFuc2FjdGlvbiBjaGFuZ2VzIHVzaW5nIEdhbGVyYS4gQSBtYWpvcml0eSBtdXN0IHJlbWFpbiBjb25uZWN0ZWQgZm9yIHRoZSBjbHVzdGVyIHRvIGFjY2VwdCB3cml0ZXMuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojMzM0MTU1fTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9InB4YzJoIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjUiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI2IiBtYXJrZXJIZWlnaHQ9IjYiIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiMwNDc4NTciLz48L21hcmtlcj48L2RlZnM+Cjx0ZXh0IHg9IjQxOCIgeT0iMjgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4OyBmaWxsOiMwNDc4NTciPlNZTkNIUk9OT1VTIFdSSVRFLVNFVCBSRVBMSUNBVElPTjwvdGV4dD4KPHJlY3QgeD0iMTIwIiB5PSI1NiIgd2lkdGg9IjE1MCIgaGVpZ2h0PSI2NCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNiIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSIxOTUiIHk9Ijg0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC1zaXplOjEycHgiPnB4Yy0wPC90ZXh0Pgo8dGV4dCB4PSIxOTUiIHk9IjEwMyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+Y2VydGlmeSB3cml0ZS1zZXQ8L3RleHQ+CjxyZWN0IHg9IjM0MyIgeT0iNTYiIHdpZHRoPSIxNTAiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjYiIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iNDE4IiB5PSI4NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTc7IGZvbnQtc2l6ZToxMnB4Ij5weGMtMTwvdGV4dD4KPHRleHQgeD0iNDE4IiB5PSIxMDMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPmNlcnRpZnkgd3JpdGUtc2V0PC90ZXh0Pgo8cmVjdCB4PSI1NjYiIHk9IjU2IiB3aWR0aD0iMTUwIiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS42IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjY0MSIgeT0iODQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXNpemU6MTJweCI+cHhjLTI8L3RleHQ+Cjx0ZXh0IHg9IjY0MSIgeT0iMTAzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij5jZXJ0aWZ5IHdyaXRlLXNldDwvdGV4dD4KPGxpbmUgeDE9IjI3MiIgeTE9Ijg4IiB4Mj0iMzQxIiB5Mj0iODgiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItc3RhcnQ9InVybCgjcHhjMmgpIiBtYXJrZXItZW5kPSJ1cmwoI3B4YzJoKSIgc3R5bGU9InN0cm9rZTojMDQ3ODU3Ii8+CjxsaW5lIHgxPSI0OTUiIHkxPSI4OCIgeDI9IjU2NCIgeTI9Ijg4IiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLXN0YXJ0PSJ1cmwoI3B4YzJoKSIgbWFya2VyLWVuZD0idXJsKCNweGMyaCkiIHN0eWxlPSJzdHJva2U6IzA0Nzg1NyIvPgo8cmVjdCB4PSIxMjAiIHk9IjE0MCIgd2lkdGg9IjU5NiIgaGVpZ2h0PSIzNCIgcng9IjEwIiBzdHJva2Utd2lkdGg9IjEuNCIgc3R5bGU9ImZpbGw6I2ZmZmJlYjtzdHJva2U6I2ZkZTY4YSIvPgo8dGV4dCB4PSI0MTgiIHk9IjE2MSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjYjQ1MzA5Ij5UaHJlZSBub2RlcyByZXRhaW4gYSBtYWpvcml0eSBhZnRlciBvbmUgbm9kZSBmYWlscy48L3RleHQ+Cjwvc3ZnPg==) ![Three Percona nodes replicate transaction changes using Galera. A majority must remain connected for the cluster to accept writes.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTkwIiB2aWV3Qm94PSIwIDAgODM2IDE5MCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaHJlZSBQZXJjb25hIG5vZGVzIHJlcGxpY2F0ZSB0cmFuc2FjdGlvbiBjaGFuZ2VzIHVzaW5nIEdhbGVyYS4gQSBtYWpvcml0eSBtdXN0IHJlbWFpbiBjb25uZWN0ZWQgZm9yIHRoZSBjbHVzdGVyIHRvIGFjY2VwdCB3cml0ZXMuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojY2JkNWUxfTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9InB4YzJoIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjUiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI2IiBtYXJrZXJIZWlnaHQ9IjYiIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM2ZWU3YjciLz48L21hcmtlcj48L2RlZnM+Cjx0ZXh0IHg9IjQxOCIgeT0iMjgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiM2ZWU3YjciPlNZTkNIUk9OT1VTIFdSSVRFLVNFVCBSRVBMSUNBVElPTjwvdGV4dD4KPHJlY3QgeD0iMTIwIiB5PSI1NiIgd2lkdGg9IjE1MCIgaGVpZ2h0PSI2NCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNiIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSIxOTUiIHk9Ijg0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC1zaXplOjEycHgiPnB4Yy0wPC90ZXh0Pgo8dGV4dCB4PSIxOTUiIHk9IjEwMyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+Y2VydGlmeSB3cml0ZS1zZXQ8L3RleHQ+CjxyZWN0IHg9IjM0MyIgeT0iNTYiIHdpZHRoPSIxNTAiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjYiIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iNDE4IiB5PSI4NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3Yjc7IGZvbnQtc2l6ZToxMnB4Ij5weGMtMTwvdGV4dD4KPHRleHQgeD0iNDE4IiB5PSIxMDMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPmNlcnRpZnkgd3JpdGUtc2V0PC90ZXh0Pgo8cmVjdCB4PSI1NjYiIHk9IjU2IiB3aWR0aD0iMTUwIiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS42IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjY0MSIgeT0iODQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXNpemU6MTJweCI+cHhjLTI8L3RleHQ+Cjx0ZXh0IHg9IjY0MSIgeT0iMTAzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij5jZXJ0aWZ5IHdyaXRlLXNldDwvdGV4dD4KPGxpbmUgeDE9IjI3MiIgeTE9Ijg4IiB4Mj0iMzQxIiB5Mj0iODgiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItc3RhcnQ9InVybCgjcHhjMmgpIiBtYXJrZXItZW5kPSJ1cmwoI3B4YzJoKSIgc3R5bGU9InN0cm9rZTojNmVlN2I3Ii8+CjxsaW5lIHgxPSI0OTUiIHkxPSI4OCIgeDI9IjU2NCIgeTI9Ijg4IiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLXN0YXJ0PSJ1cmwoI3B4YzJoKSIgbWFya2VyLWVuZD0idXJsKCNweGMyaCkiIHN0eWxlPSJzdHJva2U6IzZlZTdiNyIvPgo8cmVjdCB4PSIxMjAiIHk9IjE0MCIgd2lkdGg9IjU5NiIgaGVpZ2h0PSIzNCIgcng9IjEwIiBzdHJva2Utd2lkdGg9IjEuNCIgc3R5bGU9ImZpbGw6IzQyMjAwNjtzdHJva2U6IzkyNDAwZSIvPgo8dGV4dCB4PSI0MTgiIHk9IjE2MSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZmJiZjI0Ij5UaHJlZSBub2RlcyByZXRhaW4gYSBtYWpvcml0eSBhZnRlciBvbmUgbm9kZSBmYWlscy48L3RleHQ+Cjwvc3ZnPg==) 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. ![The RDS instance's fields map into the PerconaXtraDBCluster spec: engine\_version becomes the Percona Server for MySQL image tag, allocated\_storage becomes the PersistentVolumeClaim size, and instance\_class becomes the pods' CPU and memory resource requests.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjAwIiB2aWV3Qm94PSIwIDAgODM2IDIwMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaGUgUkRTIGluc3RhbmNlJ3MgZmllbGRzIG1hcCBpbnRvIHRoZSBQZXJjb25hWHRyYURCQ2x1c3RlciBzcGVjOiBlbmdpbmVfdmVyc2lvbiBiZWNvbWVzIHRoZSBQZXJjb25hIFNlcnZlciBmb3IgTXlTUUwgaW1hZ2UgdGFnLCBhbGxvY2F0ZWRfc3RvcmFnZSBiZWNvbWVzIHRoZSBQZXJzaXN0ZW50Vm9sdW1lQ2xhaW0gc2l6ZSwgYW5kIGluc3RhbmNlX2NsYXNzIGJlY29tZXMgdGhlIHBvZHMnIENQVSBhbmQgbWVtb3J5IHJlc291cmNlIHJlcXVlc3RzLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJweGMzaCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6Izk0YTNiOCIvPjwvbWFya2VyPjwvZGVmcz4KPHRleHQgeD0iMTk0IiB5PSIzMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjgiPmF3c19kYl9pbnN0YW5jZTwvdGV4dD4KPHRleHQgeD0iNjM2IiB5PSIzMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjg7IGZpbGw6IzA0Nzg1NyI+UGVyY29uYVh0cmFEQkNsdXN0ZXIgU1BFQzwvdGV4dD4KPHJlY3QgeD0iNDQiIHk9IjQ0IiB3aWR0aD0iMzAwIiBoZWlnaHQ9IjQwIiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iNjAiIHk9IjY5IiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzMzNDE1NTsgZm9udC1zaXplOjEwLjVweCI+ZW5naW5lX3ZlcnNpb24gPSAiOC4wIjwvdGV4dD4KPGxpbmUgeDE9IjM0OCIgeTE9IjY0IiB4Mj0iNDg2IiB5Mj0iNjQiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItZW5kPSJ1cmwoI3B4YzNoKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxyZWN0IHg9IjQ5MCIgeT0iNDQiIHdpZHRoPSIzMDYiIGhlaWdodD0iNDAiIHJ4PSI5IiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI1MDYiIHk9IjY5IiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzMzNDE1NTsgZm9udC1zaXplOjEwLjVweDtmaWxsOiMwNDc4NTciPnB4YyBpbWFnZSB0YWcg4oaSIDguMDwvdGV4dD4KPHJlY3QgeD0iNDQiIHk9IjkyIiB3aWR0aD0iMzAwIiBoZWlnaHQ9IjQwIiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iNjAiIHk9IjExNyIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICMzMzQxNTU7IGZvbnQtc2l6ZToxMC41cHgiPmFsbG9jYXRlZF9zdG9yYWdlID0gMjAwPC90ZXh0Pgo8bGluZSB4MT0iMzQ4IiB5MT0iMTEyIiB4Mj0iNDg2IiB5Mj0iMTEyIiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLWVuZD0idXJsKCNweGMzaCkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8cmVjdCB4PSI0OTAiIHk9IjkyIiB3aWR0aD0iMzA2IiBoZWlnaHQ9IjQwIiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iNTA2IiB5PSIxMTciIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjMzM0MTU1OyBmb250LXNpemU6MTAuNXB4O2ZpbGw6IzA0Nzg1NyI+dm9sdW1lU3BlYyBQVkMgPSAyMDBHaTwvdGV4dD4KPHJlY3QgeD0iNDQiIHk9IjE0MCIgd2lkdGg9IjMwMCIgaGVpZ2h0PSI0MCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS40IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjYwIiB5PSIxNjUiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjMzM0MTU1OyBmb250LXNpemU6MTAuNXB4Ij5pbnN0YW5jZV9jbGFzcyA9IGRiLnI2Zy54bGFyZ2U8L3RleHQ+CjxsaW5lIHgxPSIzNDgiIHkxPSIxNjAiIHgyPSI0ODYiIHkyPSIxNjAiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItZW5kPSJ1cmwoI3B4YzNoKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxyZWN0IHg9IjQ5MCIgeT0iMTQwIiB3aWR0aD0iMzA2IiBoZWlnaHQ9IjQwIiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iNTA2IiB5PSIxNjUiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjMzM0MTU1OyBmb250LXNpemU6MTAuNXB4O2ZpbGw6IzA0Nzg1NyI+cmVzb3VyY2VzOiBjcHUgLyBtZW1vcnk8L3RleHQ+Cjwvc3ZnPg==) ![The RDS instance's fields map into the PerconaXtraDBCluster spec: engine\_version becomes the Percona Server for MySQL image tag, allocated\_storage becomes the PersistentVolumeClaim size, and instance\_class becomes the pods' CPU and memory resource requests.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjAwIiB2aWV3Qm94PSIwIDAgODM2IDIwMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaGUgUkRTIGluc3RhbmNlJ3MgZmllbGRzIG1hcCBpbnRvIHRoZSBQZXJjb25hWHRyYURCQ2x1c3RlciBzcGVjOiBlbmdpbmVfdmVyc2lvbiBiZWNvbWVzIHRoZSBQZXJjb25hIFNlcnZlciBmb3IgTXlTUUwgaW1hZ2UgdGFnLCBhbGxvY2F0ZWRfc3RvcmFnZSBiZWNvbWVzIHRoZSBQZXJzaXN0ZW50Vm9sdW1lQ2xhaW0gc2l6ZSwgYW5kIGluc3RhbmNlX2NsYXNzIGJlY29tZXMgdGhlIHBvZHMnIENQVSBhbmQgbWVtb3J5IHJlc291cmNlIHJlcXVlc3RzLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJweGMzaCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6IzY0NzQ4YiIvPjwvbWFya2VyPjwvZGVmcz4KPHRleHQgeD0iMTk0IiB5PSIzMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGIiPmF3c19kYl9pbnN0YW5jZTwvdGV4dD4KPHRleHQgeD0iNjM2IiB5PSIzMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGI7IGZpbGw6IzZlZTdiNyI+UGVyY29uYVh0cmFEQkNsdXN0ZXIgU1BFQzwvdGV4dD4KPHJlY3QgeD0iNDQiIHk9IjQ0IiB3aWR0aD0iMzAwIiBoZWlnaHQ9IjQwIiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iNjAiIHk9IjY5IiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogI2NiZDVlMTsgZm9udC1zaXplOjEwLjVweCI+ZW5naW5lX3ZlcnNpb24gPSAiOC4wIjwvdGV4dD4KPGxpbmUgeDE9IjM0OCIgeTE9IjY0IiB4Mj0iNDg2IiB5Mj0iNjQiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItZW5kPSJ1cmwoI3B4YzNoKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxyZWN0IHg9IjQ5MCIgeT0iNDQiIHdpZHRoPSIzMDYiIGhlaWdodD0iNDAiIHJ4PSI5IiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSI1MDYiIHk9IjY5IiBzdHlsZT0iZm9udDogMTFweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogI2NiZDVlMTsgZm9udC1zaXplOjEwLjVweDtmaWxsOiM2ZWU3YjciPnB4YyBpbWFnZSB0YWcg4oaSIDguMDwvdGV4dD4KPHJlY3QgeD0iNDQiIHk9IjkyIiB3aWR0aD0iMzAwIiBoZWlnaHQ9IjQwIiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iNjAiIHk9IjExNyIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICNjYmQ1ZTE7IGZvbnQtc2l6ZToxMC41cHgiPmFsbG9jYXRlZF9zdG9yYWdlID0gMjAwPC90ZXh0Pgo8bGluZSB4MT0iMzQ4IiB5MT0iMTEyIiB4Mj0iNDg2IiB5Mj0iMTEyIiBzdHJva2Utd2lkdGg9IjEuOCIgbWFya2VyLWVuZD0idXJsKCNweGMzaCkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8cmVjdCB4PSI0OTAiIHk9IjkyIiB3aWR0aD0iMzA2IiBoZWlnaHQ9IjQwIiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iNTA2IiB5PSIxMTciIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjY2JkNWUxOyBmb250LXNpemU6MTAuNXB4O2ZpbGw6IzZlZTdiNyI+dm9sdW1lU3BlYyBQVkMgPSAyMDBHaTwvdGV4dD4KPHJlY3QgeD0iNDQiIHk9IjE0MCIgd2lkdGg9IjMwMCIgaGVpZ2h0PSI0MCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS40IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjYwIiB5PSIxNjUiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjY2JkNWUxOyBmb250LXNpemU6MTAuNXB4Ij5pbnN0YW5jZV9jbGFzcyA9IGRiLnI2Zy54bGFyZ2U8L3RleHQ+CjxsaW5lIHgxPSIzNDgiIHkxPSIxNjAiIHgyPSI0ODYiIHkyPSIxNjAiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItZW5kPSJ1cmwoI3B4YzNoKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxyZWN0IHg9IjQ5MCIgeT0iMTQwIiB3aWR0aD0iMzA2IiBoZWlnaHQ9IjQwIiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iNTA2IiB5PSIxNjUiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjY2JkNWUxOyBmb250LXNpemU6MTAuNXB4O2ZpbGw6IzZlZTdiNyI+cmVzb3VyY2VzOiBjcHUgLyBtZW1vcnk8L3RleHQ+Cjwvc3ZnPg==) 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. ![RDS backup settings become Percona operator backup configuration. The operator writes full backups to S3-compatible or Azure-compatible object storage. Point-in-time recovery runs a binlog-collector pod that streams binary logs to the same object storage; a restore replays them onto the nearest full backup.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTk2IiB2aWV3Qm94PSIwIDAgODM2IDE5NiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJSRFMgYmFja3VwIHNldHRpbmdzIGJlY29tZSBQZXJjb25hIG9wZXJhdG9yIGJhY2t1cCBjb25maWd1cmF0aW9uLiBUaGUgb3BlcmF0b3Igd3JpdGVzIGZ1bGwgYmFja3VwcyB0byBTMy1jb21wYXRpYmxlIG9yIEF6dXJlLWNvbXBhdGlibGUgb2JqZWN0IHN0b3JhZ2UuIFBvaW50LWluLXRpbWUgcmVjb3ZlcnkgcnVucyBhIGJpbmxvZy1jb2xsZWN0b3IgcG9kIHRoYXQgc3RyZWFtcyBiaW5hcnkgbG9ncyB0byB0aGUgc2FtZSBvYmplY3Qgc3RvcmFnZTsgYSByZXN0b3JlIHJlcGxheXMgdGhlbSBvbnRvIHRoZSBuZWFyZXN0IGZ1bGwgYmFja3VwLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJweGM0aCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6Izk0YTNiOCIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iMzYiIHk9IjQwIiB3aWR0aD0iMTkwIiBoZWlnaHQ9IjQ2IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjEzMSIgeT0iNjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTJweCI+UkRTIGJhY2t1cHM8L3RleHQ+Cjx0ZXh0IHg9IjEzMSIgeT0iNzgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjMzM0MTU1OyBmb250LXNpemU6OS41cHgiPmJhY2t1cF93aW5kb3cgwrcgcmV0ZW50aW9uPC90ZXh0Pgo8bGluZSB4MT0iMjI2IiB5MT0iNjMiIHgyPSIyODIiIHkyPSI2MyIgc3Ryb2tlLXdpZHRoPSIxLjgiIG1hcmtlci1lbmQ9InVybCgjcHhjNGgpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iMjU0IiB5PSI1NSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC13ZWlnaHQ6NzAwIj5jb25maWd1cmU8L3RleHQ+CjxyZWN0IHg9IjI4NiIgeT0iNDAiIHdpZHRoPSIyNTAiIGhlaWdodD0iNDYiIHJ4PSIxMCIgc3Ryb2tlLXdpZHRoPSIxLjYiIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iNDExIiB5PSI2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTc7IGZvbnQtc2l6ZToxMS41cHgiPnNjaGVkdWxlZCBiYWNrdXAgb2JqZWN0PC90ZXh0Pgo8dGV4dCB4PSI0MTEiIHk9Ijc4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij5QZXJjb25hWHRyYURCQ2x1c3RlckJhY2t1cDwvdGV4dD4KPGxpbmUgeDE9IjUzNiIgeTE9IjYzIiB4Mj0iNTkyIiB5Mj0iNjMiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItZW5kPSJ1cmwoI3B4YzRoKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxyZWN0IHg9IjU5NiIgeT0iNDAiIHdpZHRoPSIyMDQiIGhlaWdodD0iNDYiIHJ4PSIxMCIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iNjk4IiB5PSI2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMnB4Ij5vYmplY3Qgc3RvcmFnZTwvdGV4dD4KPHRleHQgeD0iNjk4IiB5PSI3OCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPlMzIC8gQXp1cmUtY29tcGF0aWJsZTwvdGV4dD4KPHJlY3QgeD0iMzYiIHk9IjExOCIgd2lkdGg9Ijc2NCIgaGVpZ2h0PSI1MiIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI0MTgiIHk9IjE0MCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTc7IGZvbnQtc2l6ZToxMS41cHgiPlBvaW50LWluLXRpbWUgcmVjb3Zlcnk8L3RleHQ+Cjx0ZXh0IHg9IjQxOCIgeT0iMTU4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij5hIGJpbmxvZy1jb2xsZWN0b3IgcG9kIHN0cmVhbXMgYmluYXJ5IGxvZ3MgdG8gdGhlIHNhbWUgc3RvcmFnZTsgYSByZXN0b3JlIHJlcGxheXMgdGhlbSBvbnRvIHRoZSBuZWFyZXN0IGZ1bGwgYmFja3VwPC90ZXh0Pgo8L3N2Zz4=) ![RDS backup settings become Percona operator backup configuration. The operator writes full backups to S3-compatible or Azure-compatible object storage. Point-in-time recovery runs a binlog-collector pod that streams binary logs to the same object storage; a restore replays them onto the nearest full backup.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTk2IiB2aWV3Qm94PSIwIDAgODM2IDE5NiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJSRFMgYmFja3VwIHNldHRpbmdzIGJlY29tZSBQZXJjb25hIG9wZXJhdG9yIGJhY2t1cCBjb25maWd1cmF0aW9uLiBUaGUgb3BlcmF0b3Igd3JpdGVzIGZ1bGwgYmFja3VwcyB0byBTMy1jb21wYXRpYmxlIG9yIEF6dXJlLWNvbXBhdGlibGUgb2JqZWN0IHN0b3JhZ2UuIFBvaW50LWluLXRpbWUgcmVjb3ZlcnkgcnVucyBhIGJpbmxvZy1jb2xsZWN0b3IgcG9kIHRoYXQgc3RyZWFtcyBiaW5hcnkgbG9ncyB0byB0aGUgc2FtZSBvYmplY3Qgc3RvcmFnZTsgYSByZXN0b3JlIHJlcGxheXMgdGhlbSBvbnRvIHRoZSBuZWFyZXN0IGZ1bGwgYmFja3VwLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJweGM0aCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6IzY0NzQ4YiIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iMzYiIHk9IjQwIiB3aWR0aD0iMTkwIiBoZWlnaHQ9IjQ2IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjEzMSIgeT0iNjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTJweCI+UkRTIGJhY2t1cHM8L3RleHQ+Cjx0ZXh0IHg9IjEzMSIgeT0iNzgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjY2JkNWUxOyBmb250LXNpemU6OS41cHgiPmJhY2t1cF93aW5kb3cgwrcgcmV0ZW50aW9uPC90ZXh0Pgo8bGluZSB4MT0iMjI2IiB5MT0iNjMiIHgyPSIyODIiIHkyPSI2MyIgc3Ryb2tlLXdpZHRoPSIxLjgiIG1hcmtlci1lbmQ9InVybCgjcHhjNGgpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iMjU0IiB5PSI1NSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC13ZWlnaHQ6NzAwIj5jb25maWd1cmU8L3RleHQ+CjxyZWN0IHg9IjI4NiIgeT0iNDAiIHdpZHRoPSIyNTAiIGhlaWdodD0iNDYiIHJ4PSIxMCIgc3Ryb2tlLXdpZHRoPSIxLjYiIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iNDExIiB5PSI2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3Yjc7IGZvbnQtc2l6ZToxMS41cHgiPnNjaGVkdWxlZCBiYWNrdXAgb2JqZWN0PC90ZXh0Pgo8dGV4dCB4PSI0MTEiIHk9Ijc4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij5QZXJjb25hWHRyYURCQ2x1c3RlckJhY2t1cDwvdGV4dD4KPGxpbmUgeDE9IjUzNiIgeTE9IjYzIiB4Mj0iNTkyIiB5Mj0iNjMiIHN0cm9rZS13aWR0aD0iMS44IiBtYXJrZXItZW5kPSJ1cmwoI3B4YzRoKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxyZWN0IHg9IjU5NiIgeT0iNDAiIHdpZHRoPSIyMDQiIGhlaWdodD0iNDYiIHJ4PSIxMCIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iNjk4IiB5PSI2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMnB4Ij5vYmplY3Qgc3RvcmFnZTwvdGV4dD4KPHRleHQgeD0iNjk4IiB5PSI3OCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPlMzIC8gQXp1cmUtY29tcGF0aWJsZTwvdGV4dD4KPHJlY3QgeD0iMzYiIHk9IjExOCIgd2lkdGg9Ijc2NCIgaGVpZ2h0PSI1MiIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSI0MTgiIHk9IjE0MCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3Yjc7IGZvbnQtc2l6ZToxMS41cHgiPlBvaW50LWluLXRpbWUgcmVjb3Zlcnk8L3RleHQ+Cjx0ZXh0IHg9IjQxOCIgeT0iMTU4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij5hIGJpbmxvZy1jb2xsZWN0b3IgcG9kIHN0cmVhbXMgYmluYXJ5IGxvZ3MgdG8gdGhlIHNhbWUgc3RvcmFnZTsgYSByZXN0b3JlIHJlcGxheXMgdGhlbSBvbnRvIHRoZSBuZWFyZXN0IGZ1bGwgYmFja3VwPC90ZXh0Pgo8L3N2Zz4=) The Percona operator schedules full backups and collects binary logs for point-in-time recovery. #### Parameters, pooling, and the RDS extras The cluster takes MySQL settings such as `innodb_buffer_pool_size` and `max_connections` in its `spec.pxc.configuration`; the reusable parameter-group object and RDS-only parameters have no counterpart. A declared `aws_db_parameter_group` is not kept: the deployment removes it and reports a warning, so the cluster starts with Percona's default values. Add the settings you need to the cluster configuration. Later parameter changes made through the RDS API, such as `ModifyDBParameterGroup`, are translated to the cluster configuration where they map. 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. ![A parameter group is not kept; you set the cluster's MySQL configuration yourself. HAProxy routes MySQL connections but does not pool them like RDS Proxy. IAM database authentication, S3 and Lambda integration SQL, Enhanced Monitoring and the RDS-managed CA certificate have no counterpart.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjEwIiB2aWV3Qm94PSIwIDAgODM2IDIxMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJBIHBhcmFtZXRlciBncm91cCBpcyBub3Qga2VwdDsgeW91IHNldCB0aGUgY2x1c3RlcidzIE15U1FMIGNvbmZpZ3VyYXRpb24geW91cnNlbGYuIEhBUHJveHkgcm91dGVzIE15U1FMIGNvbm5lY3Rpb25zIGJ1dCBkb2VzIG5vdCBwb29sIHRoZW0gbGlrZSBSRFMgUHJveHkuIElBTSBkYXRhYmFzZSBhdXRoZW50aWNhdGlvbiwgUzMgYW5kIExhbWJkYSBpbnRlZ3JhdGlvbiBTUUwsIEVuaGFuY2VkIE1vbml0b3JpbmcgYW5kIHRoZSBSRFMtbWFuYWdlZCBDQSBjZXJ0aWZpY2F0ZSBoYXZlIG5vIGNvdW50ZXJwYXJ0LiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJweGM1aCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6Izk0YTNiOCIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iNDQiIHk9IjQwIiB3aWR0aD0iMzAwIiBoZWlnaHQ9IjQ2IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjYwIiB5PSI2MiIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICMzMzQxNTU7IGZvbnQtc2l6ZToxMC41cHgiPnBhcmFtZXRlciBncm91cDwvdGV4dD4KPHRleHQgeD0iNjAiIHk9Ijc4IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+aW5ub2RiXyogwrcgbWF4X2Nvbm5lY3Rpb25zPC90ZXh0Pgo8bGluZSB4MT0iMzQ4IiB5MT0iNjMiIHgyPSI0NzAiIHkyPSI2MyIgc3Ryb2tlLXdpZHRoPSIxLjgiIG1hcmtlci1lbmQ9InVybCgjcHhjNWgpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHJlY3QgeD0iNDc0IiB5PSI0MCIgd2lkdGg9IjMxOCIgaGVpZ2h0PSI0NiIgcng9IjEwIiBzdHJva2Utd2lkdGg9IjEuNiIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI0OTAiIHk9IjYyIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNiNDUzMDk7IGZvbnQtd2VpZ2h0OjcwMCI+bm90IGNhcnJpZWQ7IHNldCBteS5jbmYgeW91cnNlbGY8L3RleHQ+Cjx0ZXh0IHg9IjQ5MCIgeT0iNzgiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5yZW1vdmVkIHdpdGggYSB3YXJuaW5nPC90ZXh0Pgo8cmVjdCB4PSI0NCIgeT0iOTgiIHdpZHRoPSIzMDAiIGhlaWdodD0iNDYiIHJ4PSIxMCIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iNjAiIHk9IjEyMCIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICMzMzQxNTU7IGZvbnQtc2l6ZToxMC41cHgiPlJEUyBQcm94eTwvdGV4dD4KPHRleHQgeD0iNjAiIHk9IjEzNiIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPmNvbm5lY3Rpb24gcG9vbGluZzwvdGV4dD4KPGxpbmUgeDE9IjM0OCIgeTE9IjEyMSIgeDI9IjQ3MCIgeTI9IjEyMSIgc3Ryb2tlLXdpZHRoPSIxLjgiIG1hcmtlci1lbmQ9InVybCgjcHhjNWgpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHJlY3QgeD0iNDc0IiB5PSI5OCIgd2lkdGg9IjMxOCIgaGVpZ2h0PSI0NiIgcng9IjEwIiBzdHJva2Utd2lkdGg9IjEuNiIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI0OTAiIHk9IjEyMCIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC13ZWlnaHQ6NzAwIj5IQVByb3h5IGVuZHBvaW50PC90ZXh0Pgo8dGV4dCB4PSI0OTAiIHk9IjEzNiIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZpbGw6IzA0Nzg1NyI+cm91dGluZyBvbmx5OyBubyBwb29saW5nPC90ZXh0Pgo8cmVjdCB4PSI0NCIgeT0iMTU4IiB3aWR0aD0iNzQ4IiBoZWlnaHQ9IjM4IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS40IiBzdHlsZT0iZmlsbDojZmZmYmViO3N0cm9rZTojZmRlNjhhIi8+Cjx0ZXh0IHg9IjQxOCIgeT0iMTgxIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNiNDUzMDkiPk5vIGFuYWxvZzogSUFNIGRhdGFiYXNlIGF1dGggwrcgUzMgLyBMYW1iZGEgaW50ZWdyYXRpb24gU1FMIMK3IEVuaGFuY2VkIE1vbml0b3JpbmcgwrcgUkRTLW1hbmFnZWQgQ0EgY2VydGlmaWNhdGU8L3RleHQ+Cjwvc3ZnPg==) ![A parameter group is not kept; you set the cluster's MySQL configuration yourself. HAProxy routes MySQL connections but does not pool them like RDS Proxy. IAM database authentication, S3 and Lambda integration SQL, Enhanced Monitoring and the RDS-managed CA certificate have no counterpart.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjEwIiB2aWV3Qm94PSIwIDAgODM2IDIxMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJBIHBhcmFtZXRlciBncm91cCBpcyBub3Qga2VwdDsgeW91IHNldCB0aGUgY2x1c3RlcidzIE15U1FMIGNvbmZpZ3VyYXRpb24geW91cnNlbGYuIEhBUHJveHkgcm91dGVzIE15U1FMIGNvbm5lY3Rpb25zIGJ1dCBkb2VzIG5vdCBwb29sIHRoZW0gbGlrZSBSRFMgUHJveHkuIElBTSBkYXRhYmFzZSBhdXRoZW50aWNhdGlvbiwgUzMgYW5kIExhbWJkYSBpbnRlZ3JhdGlvbiBTUUwsIEVuaGFuY2VkIE1vbml0b3JpbmcgYW5kIHRoZSBSRFMtbWFuYWdlZCBDQSBjZXJ0aWZpY2F0ZSBoYXZlIG5vIGNvdW50ZXJwYXJ0LiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJweGM1aCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNi41IiBtYXJrZXJIZWlnaHQ9IjYuNSIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6IzY0NzQ4YiIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iNDQiIHk9IjQwIiB3aWR0aD0iMzAwIiBoZWlnaHQ9IjQ2IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjYwIiB5PSI2MiIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICNjYmQ1ZTE7IGZvbnQtc2l6ZToxMC41cHgiPnBhcmFtZXRlciBncm91cDwvdGV4dD4KPHRleHQgeD0iNjAiIHk9Ijc4IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+aW5ub2RiXyogwrcgbWF4X2Nvbm5lY3Rpb25zPC90ZXh0Pgo8bGluZSB4MT0iMzQ4IiB5MT0iNjMiIHgyPSI0NzAiIHkyPSI2MyIgc3Ryb2tlLXdpZHRoPSIxLjgiIG1hcmtlci1lbmQ9InVybCgjcHhjNWgpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHJlY3QgeD0iNDc0IiB5PSI0MCIgd2lkdGg9IjMxOCIgaGVpZ2h0PSI0NiIgcng9IjEwIiBzdHJva2Utd2lkdGg9IjEuNiIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSI0OTAiIHk9IjYyIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmYmJmMjQ7IGZvbnQtd2VpZ2h0OjcwMCI+bm90IGNhcnJpZWQ7IHNldCBteS5jbmYgeW91cnNlbGY8L3RleHQ+Cjx0ZXh0IHg9IjQ5MCIgeT0iNzgiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5yZW1vdmVkIHdpdGggYSB3YXJuaW5nPC90ZXh0Pgo8cmVjdCB4PSI0NCIgeT0iOTgiIHdpZHRoPSIzMDAiIGhlaWdodD0iNDYiIHJ4PSIxMCIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iNjAiIHk9IjEyMCIgc3R5bGU9ImZvbnQ6IDExcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICNjYmQ1ZTE7IGZvbnQtc2l6ZToxMC41cHgiPlJEUyBQcm94eTwvdGV4dD4KPHRleHQgeD0iNjAiIHk9IjEzNiIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPmNvbm5lY3Rpb24gcG9vbGluZzwvdGV4dD4KPGxpbmUgeDE9IjM0OCIgeTE9IjEyMSIgeDI9IjQ3MCIgeTI9IjEyMSIgc3Ryb2tlLXdpZHRoPSIxLjgiIG1hcmtlci1lbmQ9InVybCgjcHhjNWgpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHJlY3QgeD0iNDc0IiB5PSI5OCIgd2lkdGg9IjMxOCIgaGVpZ2h0PSI0NiIgcng9IjEwIiBzdHJva2Utd2lkdGg9IjEuNiIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSI0OTAiIHk9IjEyMCIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC13ZWlnaHQ6NzAwIj5IQVByb3h5IGVuZHBvaW50PC90ZXh0Pgo8dGV4dCB4PSI0OTAiIHk9IjEzNiIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZpbGw6IzZlZTdiNyI+cm91dGluZyBvbmx5OyBubyBwb29saW5nPC90ZXh0Pgo8cmVjdCB4PSI0NCIgeT0iMTU4IiB3aWR0aD0iNzQ4IiBoZWlnaHQ9IjM4IiByeD0iMTAiIHN0cm9rZS13aWR0aD0iMS40IiBzdHlsZT0iZmlsbDojNDIyMDA2O3N0cm9rZTojOTI0MDBlIi8+Cjx0ZXh0IHg9IjQxOCIgeT0iMTgxIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmYmJmMjQiPk5vIGFuYWxvZzogSUFNIGRhdGFiYXNlIGF1dGggwrcgUzMgLyBMYW1iZGEgaW50ZWdyYXRpb24gU1FMIMK3IEVuaGFuY2VkIE1vbml0b3JpbmcgwrcgUkRTLW1hbmFnZWQgQ0EgY2VydGlmaWNhdGU8L3RleHQ+Cjwvc3ZnPg==) Parameter groups are not kept, HAProxy routes without pooling, and several RDS features 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. Management calls keep RDS request and response formats, and Tensor9 performs them on the Percona operator's resources. Moving existing data and operating the cluster are separate tasks. ![RDS Multi-AZ is AWS-operated with an availability SLA. The Percona XtraDB Cluster is a self-operated Galera quorum on Kubernetes with no vendor SLA, and cross-region reads need a second cluster.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTY4IiB2aWV3Qm94PSIwIDAgODM2IDE2OCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJSRFMgTXVsdGktQVogaXMgQVdTLW9wZXJhdGVkIHdpdGggYW4gYXZhaWxhYmlsaXR5IFNMQS4gVGhlIFBlcmNvbmEgWHRyYURCIENsdXN0ZXIgaXMgYSBzZWxmLW9wZXJhdGVkIEdhbGVyYSBxdW9ydW0gb24gS3ViZXJuZXRlcyB3aXRoIG5vIHZlbmRvciBTTEEsIGFuZCBjcm9zcy1yZWdpb24gcmVhZHMgbmVlZCBhIHNlY29uZCBjbHVzdGVyLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8cmVjdCB4PSIyNiIgeT0iMzAiIHdpZHRoPSIzNjAiIGhlaWdodD0iMTA0IiByeD0iMTMiIHN0cm9rZS13aWR0aD0iMS40IiBzdHlsZT0iZmlsbDojZjhmYWZjO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjIwNiIgeT0iNTgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTIuNXB4Ij5SRFMgTXVsdGktQVo8L3RleHQ+Cjx0ZXh0IHg9IjIwNiIgeT0iODIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5BV1Mgb3BlcmF0ZXMgSEEsIGJhY2t1cHMsIHBhdGNoaW5nPC90ZXh0Pgo8dGV4dCB4PSIyMDYiIHk9IjEwNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPjk5Ljk1JSAvIDk5Ljk5JSBhdmFpbGFiaWxpdHkgU0xBPC90ZXh0Pgo8bGluZSB4MT0iMzkyIiB5MT0iODIiIHgyPSI0NDYiIHkyPSI4MiIgc3Ryb2tlLXdpZHRoPSIyIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHJlY3QgeD0iNDUwIiB5PSIzMCIgd2lkdGg9IjM2MCIgaGVpZ2h0PSIxMDQiIHJ4PSIxMyIgc3Ryb2tlLXdpZHRoPSIxLjYiIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iNjMwIiB5PSI1OCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTc7IGZvbnQtc2l6ZToxMi41cHgiPlBlcmNvbmEgWHRyYURCIENsdXN0ZXI8L3RleHQ+Cjx0ZXh0IHg9IjYzMCIgeT0iODIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPkdhbGVyYSBxdW9ydW0sIHNlbGYtb3BlcmF0ZWQ8L3RleHQ+Cjx0ZXh0IHg9IjYzMCIgeT0iMTA2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNiNDUzMDkiPm5vIHZlbmRvciBTTEEgwrcgb25lIGNsdXN0ZXIgcGVyIHJlZ2lvbjwvdGV4dD4KPC9zdmc+) ![RDS Multi-AZ is AWS-operated with an availability SLA. The Percona XtraDB Cluster is a self-operated Galera quorum on Kubernetes with no vendor SLA, and cross-region reads need a second cluster.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTY4IiB2aWV3Qm94PSIwIDAgODM2IDE2OCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJSRFMgTXVsdGktQVogaXMgQVdTLW9wZXJhdGVkIHdpdGggYW4gYXZhaWxhYmlsaXR5IFNMQS4gVGhlIFBlcmNvbmEgWHRyYURCIENsdXN0ZXIgaXMgYSBzZWxmLW9wZXJhdGVkIEdhbGVyYSBxdW9ydW0gb24gS3ViZXJuZXRlcyB3aXRoIG5vIHZlbmRvciBTTEEsIGFuZCBjcm9zcy1yZWdpb24gcmVhZHMgbmVlZCBhIHNlY29uZCBjbHVzdGVyLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8cmVjdCB4PSIyNiIgeT0iMzAiIHdpZHRoPSIzNjAiIGhlaWdodD0iMTA0IiByeD0iMTMiIHN0cm9rZS13aWR0aD0iMS40IiBzdHlsZT0iZmlsbDojMGYxNzJhO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjIwNiIgeT0iNTgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTIuNXB4Ij5SRFMgTXVsdGktQVo8L3RleHQ+Cjx0ZXh0IHg9IjIwNiIgeT0iODIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5BV1Mgb3BlcmF0ZXMgSEEsIGJhY2t1cHMsIHBhdGNoaW5nPC90ZXh0Pgo8dGV4dCB4PSIyMDYiIHk9IjEwNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPjk5Ljk1JSAvIDk5Ljk5JSBhdmFpbGFiaWxpdHkgU0xBPC90ZXh0Pgo8bGluZSB4MT0iMzkyIiB5MT0iODIiIHgyPSI0NDYiIHkyPSI4MiIgc3Ryb2tlLXdpZHRoPSIyIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHJlY3QgeD0iNDUwIiB5PSIzMCIgd2lkdGg9IjM2MCIgaGVpZ2h0PSIxMDQiIHJ4PSIxMyIgc3Ryb2tlLXdpZHRoPSIxLjYiIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iNjMwIiB5PSI1OCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3Yjc7IGZvbnQtc2l6ZToxMi41cHgiPlBlcmNvbmEgWHRyYURCIENsdXN0ZXI8L3RleHQ+Cjx0ZXh0IHg9IjYzMCIgeT0iODIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPkdhbGVyYSBxdW9ydW0sIHNlbGYtb3BlcmF0ZWQ8L3RleHQ+Cjx0ZXh0IHg9IjYzMCIgeT0iMTA2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmYmJmMjQiPm5vIHZlbmRvciBTTEEgwrcgb25lIGNsdXN0ZXIgcGVyIHJlZ2lvbjwvdGV4dD4KPC9zdmc+) 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 Where RDS for MySQL and Percona XtraDB Cluster differ * **A vendor availability SLA is not available.** The cluster is self-operated on Kubernetes, so availability depends on how your team runs it, not on a cloud vendor's SLA as with RDS Multi-AZ. * **Cross-region read scale-out is not supported.** The Cloud Adapter deployment runs one cluster. Live cross-region reads or a standby region need a second cluster and a replication link. * **Writes behave differently: a majority must stay connected.** Three nodes tolerate one unavailable node. Losing the majority interrupts normal database service until quorum is restored. * **Commits behave differently: each one is certified across the cluster.** Write-set certification adds coordination to every commit. Test throughput on the cluster before cutting over a write-heavy workload tuned for a single RDS writer. * **Capacity behaves differently: it is bound to the cluster.** Each pod must fit a Kubernetes node, and each PersistentVolumeClaim is sized on its StorageClass. There is no instance-type catalog and no storage autoscaling as usage grows. * **Declared parameter groups are dropped at deployment.** The deployment removes the group with a warning. Put the MySQL settings you need in the cluster configuration. * **RDS-only features are not supported.** IAM database authentication, S3 and Lambda integration SQL, Enhanced Monitoring and the RDS-managed CA certificate have no counterpart; the cluster uses native MySQL accounts and Kubernetes monitoring. #### 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. #### Example monthly charges This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include. ##### RDS MySQL · Primary allocated compute Feature: RDS MySQL. Estimated monthly service charges by Primary allocated compute. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. ![RDS MySQL · Primary allocated compute: monthly service charges by Primary allocated compute. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/9704297fda37ad699d29ac5b78198512ff4b23a26e62fff857d683d1abdb660b-light.svg) ![RDS MySQL · Primary allocated compute: monthly service charges by Primary allocated compute. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/bceefa065c8d1d4c6510b1b717774df24e3c31cf6132244e6c3342c3b5b4eff1-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Primary allocated compute (vCPU-hours/month) | RDS MySQL | Target scenario | Percona XtraDB Cluster (MySQL) | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | Percona XtraDB Cluster (MySQL) (one copy) | 80.90 | 80.90 | | 0 | 0.00 | Percona XtraDB Cluster (MySQL) (two copies) | 161.79 | 161.79 | | 1,460 | 124.83 | Percona XtraDB Cluster (MySQL) (one copy) | 80.90 | -43.93 | | 1,460 | 124.83 | Percona XtraDB Cluster (MySQL) (two copies) | 161.79 | 36.96 | | 2,920 | 249.66 | Percona XtraDB Cluster (MySQL) (one copy) | 151.79 | -97.87 | | 2,920 | 249.66 | Percona XtraDB Cluster (MySQL) (two copies) | 303.58 | 53.92 | | 5,840 | 499.32 | Percona XtraDB Cluster (MySQL) (one copy) | 293.58 | -205.74 | | 5,840 | 499.32 | Percona XtraDB Cluster (MySQL) (two copies) | 587.17 | 87.85 | | 11,680 | 998.64 | Percona XtraDB Cluster (MySQL) (one copy) | 577.17 | -421.47 | | 11,680 | 998.64 | Percona XtraDB Cluster (MySQL) (two copies) | 1,154.34 | 155.70 | | 23,360 | 1,997.28 | Percona XtraDB Cluster (MySQL) (one copy) | 1,144.34 | -852.94 | | 23,360 | 1,997.28 | Percona XtraDB Cluster (MySQL) (two copies) | 2,288.68 | 291.40 | | 46,720 | 3,994.56 | Percona XtraDB Cluster (MySQL) (one copy) | 2,278.68 | -1,715.88 | | 46,720 | 3,994.56 | Percona XtraDB Cluster (MySQL) (two copies) | 4,557.35 | 562.79 | Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 vCPU-hours/month to 64 vCPU, 256 GiB memory and 100 GiB SSD at 46,720 vCPU-hours/month. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | Percona XtraDB Cluster (MySQL) (one copy) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Percona XtraDB Cluster (MySQL) (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Percona XtraDB Cluster (MySQL) (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (one copy) | Origin list price · Database reads | 0 | USD/operations | | Percona XtraDB Cluster (MySQL) (one copy) | Origin list price · Database writes | 0 | USD/operations | | Percona XtraDB Cluster (MySQL) (one copy) | Target CPU / source CPU | 1 | multiplier | | Percona XtraDB Cluster (MySQL) (one copy) | Target RAM / source RAM | 1 | multiplier | | Percona XtraDB Cluster (MySQL) (one copy) | Target disk / source disk | 1 | multiplier | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · read | 0 | USD/read | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · write | 0 | USD/write | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | Percona XtraDB Cluster (MySQL) (one copy) | Target list price · GiB-month | 0.1 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Percona XtraDB Cluster (MySQL) (one copy) | Target list price · network GiB | 0.12 | USD/network GiB | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Percona XtraDB Cluster (MySQL) (one copy) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour | | Percona XtraDB Cluster (MySQL) (one copy) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · input token | 0 | USD/input token | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · output token | 0 | USD/output token | | Percona XtraDB Cluster (MySQL) (one copy) | Target monthly base charge | 0 | USD/month | | Percona XtraDB Cluster (MySQL) (one copy) | Approximate target service minimum | 0 | USD/month | | Percona XtraDB Cluster (MySQL) (one copy) | Minimum primary CPU | 2 | vCPU | | Percona XtraDB Cluster (MySQL) (one copy) | Minimum primary RAM | 8 | GiB | | Percona XtraDB Cluster (MySQL) (one copy) | Minimum primary disk | 100 | GiB | | Percona XtraDB Cluster (MySQL) (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | Percona XtraDB Cluster (MySQL) (one copy) | Allocated share of provisioned cost | 1 | fraction | | Percona XtraDB Cluster (MySQL) (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Percona XtraDB Cluster (MySQL) (one copy) | Planning peak / mean work | 2 | multiplier | | Percona XtraDB Cluster (MySQL) (one copy) | Planning primary CPU utilization | 0.7 | fraction | | Percona XtraDB Cluster (MySQL) (one copy) | Resident state reserved in RAM | 0.1 | fraction | | Percona XtraDB Cluster (MySQL) (one copy) | Planning disk utilization | 0.8 | fraction | | Percona XtraDB Cluster (MySQL) (one copy) | Maintenance and log disk reserve | 20 | GiB | | Percona XtraDB Cluster (MySQL) (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Percona XtraDB Cluster (MySQL) (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Percona XtraDB Cluster (MySQL) (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | Percona XtraDB Cluster (MySQL) (two copies) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Percona XtraDB Cluster (MySQL) (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Percona XtraDB Cluster (MySQL) (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (two copies) | Origin list price · Database reads | 0 | USD/operations | | Percona XtraDB Cluster (MySQL) (two copies) | Origin list price · Database writes | 0 | USD/operations | | Percona XtraDB Cluster (MySQL) (two copies) | Target CPU / source CPU | 1 | multiplier | | Percona XtraDB Cluster (MySQL) (two copies) | Target RAM / source RAM | 1 | multiplier | | Percona XtraDB Cluster (MySQL) (two copies) | Target disk / source disk | 1 | multiplier | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · read | 0 | USD/read | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · write | 0 | USD/write | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | Percona XtraDB Cluster (MySQL) (two copies) | Target list price · GiB-month | 0.1 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Percona XtraDB Cluster (MySQL) (two copies) | Target list price · network GiB | 0.12 | USD/network GiB | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Percona XtraDB Cluster (MySQL) (two copies) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour | | Percona XtraDB Cluster (MySQL) (two copies) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · input token | 0 | USD/input token | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · output token | 0 | USD/output token | | Percona XtraDB Cluster (MySQL) (two copies) | Target monthly base charge | 0 | USD/month | | Percona XtraDB Cluster (MySQL) (two copies) | Approximate target service minimum | 0 | USD/month | | Percona XtraDB Cluster (MySQL) (two copies) | Minimum primary CPU | 2 | vCPU | | Percona XtraDB Cluster (MySQL) (two copies) | Minimum primary RAM | 8 | GiB | | Percona XtraDB Cluster (MySQL) (two copies) | Minimum primary disk | 100 | GiB | | Percona XtraDB Cluster (MySQL) (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | Percona XtraDB Cluster (MySQL) (two copies) | Allocated share of provisioned cost | 1 | fraction | | Percona XtraDB Cluster (MySQL) (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Percona XtraDB Cluster (MySQL) (two copies) | Planning peak / mean work | 2 | multiplier | | Percona XtraDB Cluster (MySQL) (two copies) | Planning primary CPU utilization | 0.7 | fraction | | Percona XtraDB Cluster (MySQL) (two copies) | Resident state reserved in RAM | 0.1 | fraction | | Percona XtraDB Cluster (MySQL) (two copies) | Planning disk utilization | 0.8 | fraction | | Percona XtraDB Cluster (MySQL) (two copies) | Maintenance and log disk reserve | 20 | GiB | | Percona XtraDB Cluster (MySQL) (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Percona XtraDB Cluster (MySQL) (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Percona XtraDB Cluster (MySQL) (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * CPU allocation does not imply an achieved transaction rate. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements. * Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month. * Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded. * Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied. * Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Self-hosted target: Percona Operator for MySQL (Apache-2.0, [https://github.com/percona/percona-server-mysql-operator/blob/main/LICENSE](https://github.com/percona/percona-server-mysql-operator/blob/main/LICENSE)) with Percona Server for MySQL (GPLv2). Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer's Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: Compute Engine n2-highmem-128 has 128 vCPUs and 864 GB ([https://docs.cloud.google.com/compute/docs/general-purpose-machines](https://docs.cloud.google.com/compute/docs/general-purpose-machines)); a Persistent Disk volume holds up to 64 TiB ([https://docs.cloud.google.com/compute/docs/disks/persistent-disks](https://docs.cloud.google.com/compute/docs/disks/persistent-disks)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonRDS offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json) * Compute Engine general-purpose machine pricing: [https://cloud.google.com/products/compute/pricing/general-purpose](https://cloud.google.com/products/compute/pricing/general-purpose) * Disk and image pricing: [https://cloud.google.com/compute/disks-image-pricing](https://cloud.google.com/compute/disks-image-pricing) * Network pricing: [https://cloud.google.com/vpc/network-pricing](https://cloud.google.com/vpc/network-pricing) Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. List prices read: 2026-10-22. Model: `plan-86c8dfa5bdc4a23be3e057a087872f347e864a44` / `2026-10-22.planning.2`. Curve: `workload-1`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Compute Engine general-purpose machine pricing](https://cloud.google.com/products/compute/pricing/general-purpose), [Disk and image pricing](https://cloud.google.com/compute/disks-image-pricing), [Network pricing](https://cloud.google.com/vpc/network-pricing). ##### RDS MySQL · Stored data Feature: RDS MySQL. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. ![RDS MySQL · Stored data: monthly service charges by Stored data. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/ce5671074221ed1427c1c541659dc02bd627db70e18cd014fb83dcf40ea81225-light.svg) ![RDS MySQL · Stored data: monthly service charges by Stored data. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/edf793cfb91fb4502e2d5580f8c51fdc3019257e41f28b423bea4ad998c3d78e-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Stored data (GiB-month) | RDS MySQL | Target scenario | Percona XtraDB Cluster (MySQL) | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | Percona XtraDB Cluster (MySQL) (one copy) | 80.90 | 80.90 | | 0 | 0.00 | Percona XtraDB Cluster (MySQL) (two copies) | 161.79 | 161.79 | | 10 | 1.15 | Percona XtraDB Cluster (MySQL) (one copy) | 80.90 | 79.75 | | 10 | 1.15 | Percona XtraDB Cluster (MySQL) (two copies) | 161.79 | 160.64 | | 100 | 11.50 | Percona XtraDB Cluster (MySQL) (one copy) | 85.90 | 74.40 | | 100 | 11.50 | Percona XtraDB Cluster (MySQL) (two copies) | 171.79 | 160.29 | | 1,000 | 115.00 | Percona XtraDB Cluster (MySQL) (one copy) | 198.40 | 83.40 | | 1,000 | 115.00 | Percona XtraDB Cluster (MySQL) (two copies) | 396.79 | 281.79 | | 10,000 | 1,150.00 | Percona XtraDB Cluster (MySQL) (one copy) | 1,323.40 | 173.40 | | 10,000 | 1,150.00 | Percona XtraDB Cluster (MySQL) (two copies) | 2,646.79 | 1,496.79 | | 100,000 | 11,500.00 | Percona XtraDB Cluster (MySQL) (one copy) | Unpriced | Unavailable | | 100,000 | 11,500.00 | Percona XtraDB Cluster (MySQL) (two copies) | Unpriced | Unavailable | Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 GiB-month to 2 vCPU, 8 GiB memory and 12,525 GiB SSD at 10,000 GiB-month. From 100,000 GiB-month the workload exceeds the planning range and the target is unpriced. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | Percona XtraDB Cluster (MySQL) (one copy) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Percona XtraDB Cluster (MySQL) (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Percona XtraDB Cluster (MySQL) (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (one copy) | Origin list price · Database reads | 0 | USD/operations | | Percona XtraDB Cluster (MySQL) (one copy) | Origin list price · Database writes | 0 | USD/operations | | Percona XtraDB Cluster (MySQL) (one copy) | Target CPU / source CPU | 1 | multiplier | | Percona XtraDB Cluster (MySQL) (one copy) | Target RAM / source RAM | 1 | multiplier | | Percona XtraDB Cluster (MySQL) (one copy) | Target disk / source disk | 1 | multiplier | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · read | 0 | USD/read | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · write | 0 | USD/write | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | Percona XtraDB Cluster (MySQL) (one copy) | Target list price · GiB-month | 0.1 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Percona XtraDB Cluster (MySQL) (one copy) | Target list price · network GiB | 0.12 | USD/network GiB | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Percona XtraDB Cluster (MySQL) (one copy) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour | | Percona XtraDB Cluster (MySQL) (one copy) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · input token | 0 | USD/input token | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · output token | 0 | USD/output token | | Percona XtraDB Cluster (MySQL) (one copy) | Target monthly base charge | 0 | USD/month | | Percona XtraDB Cluster (MySQL) (one copy) | Approximate target service minimum | 0 | USD/month | | Percona XtraDB Cluster (MySQL) (one copy) | Minimum primary CPU | 2 | vCPU | | Percona XtraDB Cluster (MySQL) (one copy) | Minimum primary RAM | 8 | GiB | | Percona XtraDB Cluster (MySQL) (one copy) | Minimum primary disk | 100 | GiB | | Percona XtraDB Cluster (MySQL) (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | Percona XtraDB Cluster (MySQL) (one copy) | Allocated share of provisioned cost | 1 | fraction | | Percona XtraDB Cluster (MySQL) (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Percona XtraDB Cluster (MySQL) (one copy) | Planning peak / mean work | 2 | multiplier | | Percona XtraDB Cluster (MySQL) (one copy) | Planning primary CPU utilization | 0.7 | fraction | | Percona XtraDB Cluster (MySQL) (one copy) | Resident state reserved in RAM | 0.1 | fraction | | Percona XtraDB Cluster (MySQL) (one copy) | Planning disk utilization | 0.8 | fraction | | Percona XtraDB Cluster (MySQL) (one copy) | Maintenance and log disk reserve | 20 | GiB | | Percona XtraDB Cluster (MySQL) (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Percona XtraDB Cluster (MySQL) (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Percona XtraDB Cluster (MySQL) (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | Percona XtraDB Cluster (MySQL) (two copies) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Percona XtraDB Cluster (MySQL) (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Percona XtraDB Cluster (MySQL) (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (two copies) | Origin list price · Database reads | 0 | USD/operations | | Percona XtraDB Cluster (MySQL) (two copies) | Origin list price · Database writes | 0 | USD/operations | | Percona XtraDB Cluster (MySQL) (two copies) | Target CPU / source CPU | 1 | multiplier | | Percona XtraDB Cluster (MySQL) (two copies) | Target RAM / source RAM | 1 | multiplier | | Percona XtraDB Cluster (MySQL) (two copies) | Target disk / source disk | 1 | multiplier | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · read | 0 | USD/read | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · write | 0 | USD/write | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | Percona XtraDB Cluster (MySQL) (two copies) | Target list price · GiB-month | 0.1 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Percona XtraDB Cluster (MySQL) (two copies) | Target list price · network GiB | 0.12 | USD/network GiB | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Percona XtraDB Cluster (MySQL) (two copies) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour | | Percona XtraDB Cluster (MySQL) (two copies) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · input token | 0 | USD/input token | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · output token | 0 | USD/output token | | Percona XtraDB Cluster (MySQL) (two copies) | Target monthly base charge | 0 | USD/month | | Percona XtraDB Cluster (MySQL) (two copies) | Approximate target service minimum | 0 | USD/month | | Percona XtraDB Cluster (MySQL) (two copies) | Minimum primary CPU | 2 | vCPU | | Percona XtraDB Cluster (MySQL) (two copies) | Minimum primary RAM | 8 | GiB | | Percona XtraDB Cluster (MySQL) (two copies) | Minimum primary disk | 100 | GiB | | Percona XtraDB Cluster (MySQL) (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | Percona XtraDB Cluster (MySQL) (two copies) | Allocated share of provisioned cost | 1 | fraction | | Percona XtraDB Cluster (MySQL) (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Percona XtraDB Cluster (MySQL) (two copies) | Planning peak / mean work | 2 | multiplier | | Percona XtraDB Cluster (MySQL) (two copies) | Planning primary CPU utilization | 0.7 | fraction | | Percona XtraDB Cluster (MySQL) (two copies) | Resident state reserved in RAM | 0.1 | fraction | | Percona XtraDB Cluster (MySQL) (two copies) | Planning disk utilization | 0.8 | fraction | | Percona XtraDB Cluster (MySQL) (two copies) | Maintenance and log disk reserve | 20 | GiB | | Percona XtraDB Cluster (MySQL) (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Percona XtraDB Cluster (MySQL) (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Percona XtraDB Cluster (MySQL) (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * Request meters remain at their independently authored defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements. * Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month. * Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded. * Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied. * Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Self-hosted target: Percona Operator for MySQL (Apache-2.0, [https://github.com/percona/percona-server-mysql-operator/blob/main/LICENSE](https://github.com/percona/percona-server-mysql-operator/blob/main/LICENSE)) with Percona Server for MySQL (GPLv2). Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer's Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: Compute Engine n2-highmem-128 has 128 vCPUs and 864 GB ([https://docs.cloud.google.com/compute/docs/general-purpose-machines](https://docs.cloud.google.com/compute/docs/general-purpose-machines)); a Persistent Disk volume holds up to 64 TiB ([https://docs.cloud.google.com/compute/docs/disks/persistent-disks](https://docs.cloud.google.com/compute/docs/disks/persistent-disks)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonRDS offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json) * Compute Engine general-purpose machine pricing: [https://cloud.google.com/products/compute/pricing/general-purpose](https://cloud.google.com/products/compute/pricing/general-purpose) * Disk and image pricing: [https://cloud.google.com/compute/disks-image-pricing](https://cloud.google.com/compute/disks-image-pricing) * Network pricing: [https://cloud.google.com/vpc/network-pricing](https://cloud.google.com/vpc/network-pricing) Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. List prices read: 2026-10-22. Model: `plan-86c8dfa5bdc4a23be3e057a087872f347e864a44` / `2026-10-22.planning.2`. Curve: `workload-2`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Compute Engine general-purpose machine pricing](https://cloud.google.com/products/compute/pricing/general-purpose), [Disk and image pricing](https://cloud.google.com/compute/disks-image-pricing), [Network pricing](https://cloud.google.com/vpc/network-pricing). ##### RDS MySQL · Database writes Feature: RDS MySQL. Estimated monthly service charges by Database writes. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. ![RDS MySQL · Database writes: monthly service charges by Database writes. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/d5b62f2670aa890b62b87f2d26246ab65a16255ea66f1d96d941a4ab0815f7d8-light.svg) ![RDS MySQL · Database writes: monthly service charges by Database writes. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/0141d3110ef56d1673cd85346bbb669b7090846f492521dbd4243ffc9e4d6dc2-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Database writes (per second) | RDS MySQL | Target scenario | Percona XtraDB Cluster (MySQL) | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | Percona XtraDB Cluster (MySQL) (one copy) | 80.90 | 80.90 | | 0 | 0.00 | Percona XtraDB Cluster (MySQL) (two copies) | 161.79 | 161.79 | | 1 | 0.00 | Percona XtraDB Cluster (MySQL) (one copy) | 80.90 | 80.90 | | 1 | 0.00 | Percona XtraDB Cluster (MySQL) (two copies) | 161.79 | 161.79 | | 10 | 0.00 | Percona XtraDB Cluster (MySQL) (one copy) | 80.90 | 80.90 | | 10 | 0.00 | Percona XtraDB Cluster (MySQL) (two copies) | 161.79 | 161.79 | | 100 | 0.00 | Percona XtraDB Cluster (MySQL) (one copy) | 80.90 | 80.90 | | 100 | 0.00 | Percona XtraDB Cluster (MySQL) (two copies) | 161.79 | 161.79 | | 1,000 | 0.00 | Percona XtraDB Cluster (MySQL) (one copy) | 80.90 | 80.90 | | 1,000 | 0.00 | Percona XtraDB Cluster (MySQL) (two copies) | 161.79 | 161.79 | | 10,000 | 0.00 | Percona XtraDB Cluster (MySQL) (one copy) | 80.90 | 80.90 | | 10,000 | 0.00 | Percona XtraDB Cluster (MySQL) (two copies) | 161.79 | 161.79 | Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | Percona XtraDB Cluster (MySQL) (one copy) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Percona XtraDB Cluster (MySQL) (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Percona XtraDB Cluster (MySQL) (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (one copy) | Origin list price · Database reads | 0 | USD/operations | | Percona XtraDB Cluster (MySQL) (one copy) | Origin list price · Database writes | 0 | USD/operations | | Percona XtraDB Cluster (MySQL) (one copy) | Target CPU / source CPU | 1 | multiplier | | Percona XtraDB Cluster (MySQL) (one copy) | Target RAM / source RAM | 1 | multiplier | | Percona XtraDB Cluster (MySQL) (one copy) | Target disk / source disk | 1 | multiplier | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · read | 0 | USD/read | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · write | 0 | USD/write | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | Percona XtraDB Cluster (MySQL) (one copy) | Target list price · GiB-month | 0.1 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Percona XtraDB Cluster (MySQL) (one copy) | Target list price · network GiB | 0.12 | USD/network GiB | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Percona XtraDB Cluster (MySQL) (one copy) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour | | Percona XtraDB Cluster (MySQL) (one copy) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · input token | 0 | USD/input token | | Percona XtraDB Cluster (MySQL) (one copy) | Target price guess · output token | 0 | USD/output token | | Percona XtraDB Cluster (MySQL) (one copy) | Target monthly base charge | 0 | USD/month | | Percona XtraDB Cluster (MySQL) (one copy) | Approximate target service minimum | 0 | USD/month | | Percona XtraDB Cluster (MySQL) (one copy) | Minimum primary CPU | 2 | vCPU | | Percona XtraDB Cluster (MySQL) (one copy) | Minimum primary RAM | 8 | GiB | | Percona XtraDB Cluster (MySQL) (one copy) | Minimum primary disk | 100 | GiB | | Percona XtraDB Cluster (MySQL) (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | Percona XtraDB Cluster (MySQL) (one copy) | Allocated share of provisioned cost | 1 | fraction | | Percona XtraDB Cluster (MySQL) (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Percona XtraDB Cluster (MySQL) (one copy) | Planning peak / mean work | 2 | multiplier | | Percona XtraDB Cluster (MySQL) (one copy) | Planning primary CPU utilization | 0.7 | fraction | | Percona XtraDB Cluster (MySQL) (one copy) | Resident state reserved in RAM | 0.1 | fraction | | Percona XtraDB Cluster (MySQL) (one copy) | Planning disk utilization | 0.8 | fraction | | Percona XtraDB Cluster (MySQL) (one copy) | Maintenance and log disk reserve | 20 | GiB | | Percona XtraDB Cluster (MySQL) (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Percona XtraDB Cluster (MySQL) (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Percona XtraDB Cluster (MySQL) (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | Percona XtraDB Cluster (MySQL) (two copies) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Percona XtraDB Cluster (MySQL) (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Percona XtraDB Cluster (MySQL) (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (two copies) | Origin list price · Database reads | 0 | USD/operations | | Percona XtraDB Cluster (MySQL) (two copies) | Origin list price · Database writes | 0 | USD/operations | | Percona XtraDB Cluster (MySQL) (two copies) | Target CPU / source CPU | 1 | multiplier | | Percona XtraDB Cluster (MySQL) (two copies) | Target RAM / source RAM | 1 | multiplier | | Percona XtraDB Cluster (MySQL) (two copies) | Target disk / source disk | 1 | multiplier | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · read | 0 | USD/read | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · write | 0 | USD/write | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | Percona XtraDB Cluster (MySQL) (two copies) | Target list price · GiB-month | 0.1 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Percona XtraDB Cluster (MySQL) (two copies) | Target list price · network GiB | 0.12 | USD/network GiB | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Percona XtraDB Cluster (MySQL) (two copies) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour | | Percona XtraDB Cluster (MySQL) (two copies) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · input token | 0 | USD/input token | | Percona XtraDB Cluster (MySQL) (two copies) | Target price guess · output token | 0 | USD/output token | | Percona XtraDB Cluster (MySQL) (two copies) | Target monthly base charge | 0 | USD/month | | Percona XtraDB Cluster (MySQL) (two copies) | Approximate target service minimum | 0 | USD/month | | Percona XtraDB Cluster (MySQL) (two copies) | Minimum primary CPU | 2 | vCPU | | Percona XtraDB Cluster (MySQL) (two copies) | Minimum primary RAM | 8 | GiB | | Percona XtraDB Cluster (MySQL) (two copies) | Minimum primary disk | 100 | GiB | | Percona XtraDB Cluster (MySQL) (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | Percona XtraDB Cluster (MySQL) (two copies) | Allocated share of provisioned cost | 1 | fraction | | Percona XtraDB Cluster (MySQL) (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Percona XtraDB Cluster (MySQL) (two copies) | Planning peak / mean work | 2 | multiplier | | Percona XtraDB Cluster (MySQL) (two copies) | Planning primary CPU utilization | 0.7 | fraction | | Percona XtraDB Cluster (MySQL) (two copies) | Resident state reserved in RAM | 0.1 | fraction | | Percona XtraDB Cluster (MySQL) (two copies) | Planning disk utilization | 0.8 | fraction | | Percona XtraDB Cluster (MySQL) (two copies) | Maintenance and log disk reserve | 20 | GiB | | Percona XtraDB Cluster (MySQL) (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Percona XtraDB Cluster (MySQL) (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Percona XtraDB Cluster (MySQL) (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Percona XtraDB Cluster (MySQL) (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * Source compute and stored data remain independent; a throughput view needs explicit workload inputs. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements. * Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month. * Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded. * Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied. * Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Self-hosted target: Percona Operator for MySQL (Apache-2.0, [https://github.com/percona/percona-server-mysql-operator/blob/main/LICENSE](https://github.com/percona/percona-server-mysql-operator/blob/main/LICENSE)) with Percona Server for MySQL (GPLv2). Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer's Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: Compute Engine n2-highmem-128 has 128 vCPUs and 864 GB ([https://docs.cloud.google.com/compute/docs/general-purpose-machines](https://docs.cloud.google.com/compute/docs/general-purpose-machines)); a Persistent Disk volume holds up to 64 TiB ([https://docs.cloud.google.com/compute/docs/disks/persistent-disks](https://docs.cloud.google.com/compute/docs/disks/persistent-disks)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonRDS offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json) * Compute Engine general-purpose machine pricing: [https://cloud.google.com/products/compute/pricing/general-purpose](https://cloud.google.com/products/compute/pricing/general-purpose) * Disk and image pricing: [https://cloud.google.com/compute/disks-image-pricing](https://cloud.google.com/compute/disks-image-pricing) * Network pricing: [https://cloud.google.com/vpc/network-pricing](https://cloud.google.com/vpc/network-pricing) Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. List prices read: 2026-10-22. Model: `plan-86c8dfa5bdc4a23be3e057a087872f347e864a44` / `2026-10-22.planning.2`. Curve: `workload-3`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Compute Engine general-purpose machine pricing](https://cloud.google.com/products/compute/pricing/general-purpose), [Disk and image pricing](https://cloud.google.com/compute/disks-image-pricing), [Network pricing](https://cloud.google.com/vpc/network-pricing). **RDS MySQL → Percona XtraDB Cluster (MySQL): Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD. | Monthly component | USD | | - | -: | | Origin: Primary compute | 0.00 | | Origin: Primary memory | 0.00 | | Origin: Primary provisioned storage | 0.00 | | Origin: Database reads | 0.00 | | Origin: Database writes | 0.00 | | Target: Provisioned primary CPU | 46.15 | | Target: Provisioned primary RAM | 24.74 | | Target: Provisioned primary disk | 10.00 | | Target: Selected billable network | 0.00 | | Target: Independent provisioned resources | 0.00 | | Target: Independent managed resources | 0.00 | | **Origin service subtotal** | **0.00** | | **Target service subtotal** | **80.90** | Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. **Scenario assumptions** | Input | Value | Unit | | - | -: | - | | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Origin list price · Primary memory | 0 | USD/GiB-hours | | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Origin list price · Database reads | 0 | USD/operations | | Origin list price · Database writes | 0 | USD/operations | | Target CPU / source CPU | 1 | multiplier | | Target RAM / source RAM | 1 | multiplier | | Target disk / source disk | 1 | multiplier | | Target price guess · read | 0 | USD/read | | Target price guess · write | 0 | USD/write | | Target price guess · provider operation | 0 | USD/provider operation | | Target list price · GiB-month | 0.1 | USD/GiB-month | | Target price guess · published GiB | 0 | USD/published GiB | | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Target list price · network GiB | 0.12 | USD/network GiB | | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour | | Target list price · GiB-hour | 0.004237 | USD/GiB-hour | | Target price guess · resource-hour | 0 | USD/resource-hour | | Target price guess · resource-month | 0 | USD/resource-month | | Target price guess · input token | 0 | USD/input token | | Target price guess · output token | 0 | USD/output token | | Target monthly base charge | 0 | USD/month | | Approximate target service minimum | 0 | USD/month | | Minimum primary CPU | 2 | vCPU | | Minimum primary RAM | 8 | GiB | | Minimum primary disk | 100 | GiB | | Additional full-price standby copy | 0 | 0 or 1 | | Allocated share of provisioned cost | 1 | fraction | | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Planning peak / mean work | 2 | multiplier | | Planning primary CPU utilization | 0.7 | fraction | | Resident state reserved in RAM | 0.1 | fraction | | Planning disk utilization | 0.8 | fraction | | Maintenance and log disk reserve | 20 | GiB | | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Dependent object sink write price guess | 0.000005 | USD/write | | Primary compute | 0 | vCPU-hours | | Primary memory | 0 | GiB-hours | | Primary provisioned storage | 0 | GiB-month | | Database reads | 0 | operations | | Database writes | 0 | operations | * Translated reads: 0 operations. * Translated writes: 0 operations. * Translated resident physical data: 0 GiB-month. * Native provider operations: 0 operations. * Published payload: 0 GiB. * Delivered payload: 0 GiB. * Allocated execution CPU: 0 vCPU-hour. * Allocated execution RAM: 0 GiB-hour. * Independent resource allocation: 0 resource-hour. * Independent inventory: 0 resource-month. * Input tokens: 0 tokens. * Output tokens: 0 tokens. * Billable network: 0 GiB. * Dependent object sink retained data: 0 GiB-month. * Dependent object sink writes: 0 writes. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Self-hosted target: Percona Operator for MySQL (Apache-2.0, [https://github.com/percona/percona-server-mysql-operator/blob/main/LICENSE](https://github.com/percona/percona-server-mysql-operator/blob/main/LICENSE)) with Percona Server for MySQL (GPLv2). Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer's Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: Compute Engine n2-highmem-128 has 128 vCPUs and 864 GB ([https://docs.cloud.google.com/compute/docs/general-purpose-machines](https://docs.cloud.google.com/compute/docs/general-purpose-machines)); a Persistent Disk volume holds up to 64 TiB ([https://docs.cloud.google.com/compute/docs/disks/persistent-disks](https://docs.cloud.google.com/compute/docs/disks/persistent-disks)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. List prices read: 2026-10-22. Model: `plan-86c8dfa5bdc4a23be3e057a087872f347e864a44` / `2026-10-22.planning.2`. Scenario: `planning-example`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Compute Engine general-purpose machine pricing](https://cloud.google.com/products/compute/pricing/general-purpose), [Disk and image pricing](https://cloud.google.com/compute/disks-image-pricing), [Network pricing](https://cloud.google.com/vpc/network-pricing). ## On Scaleway ### Scaleway Managed Database for MySQL | Operation | Area | Support | Depth | Notes | | - | - | - | - | - | | Admin credentials | Access | Partial | Common | The mapping does not copy your master username or password from the origin. The emitted instance provisions its own admin user and takes the password from a sensitive terraform variable -- no plaintext password is ever written into the terraform your customer applies, by policy. If your application reads the origin username from an output it would otherwise connect as a user that does not exist, so the emitted username is exposed where the origin's was. | | IAM database authentication | Access | Out of scope | Most usage | If your instance authenticates clients with IAM database auth, your application holds no password at all -- it asks AWS IAM for a short-lived token and uses that. A Scaleway Cloud Adapter deployment is not in AWS IAM and nothing answers that call, so the application cannot get a credential and never connects. The database itself comes up healthy, which is what makes this worth reading twice: the failure lands on your application after cutover, beside a green database. | | Non-default port | Engine | Partial | Most usage | An origin listening on a non-standard port is surfaced rather than silently moved -- Scaleway MySQL listens where MySQL listens. | | The database | Engine | Supported | Common | Your MySQL instance becomes a Scaleway Managed Database for MySQL, operated by Scaleway rather than self-hosted on your customer's cluster. | | Backups | Operations | Partial | Common | Retention and the preferred backup window do not project. Scaleway Managed Database takes scheduled backups on its own controls, so the schedule you declared is not the schedule you get -- set it on the Scaleway side. | | Encryption at rest | Security | Partial | Common | Encryption is on, but a customer-managed key does not project: Scaleway exposes encryption at rest as a toggle with Scaleway-managed keys and has no customer-managed-key option here. If your compliance position depends on holding the key, this is the row to read. | #### How it works When your product is deployed into the customer's Scaleway environment, Tensor9 compiles the RDS MySQL database instance your stack declares into a Scaleway Managed Database for MySQL instance. The instance class selects a Scaleway node type, the allocated storage becomes a block storage volume, and the database lands on MySQL 8, the only MySQL version Scaleway offers. A Multi-AZ instance becomes a high-availability instance with a hot standby. Your application's MySQL driver connects directly to the Scaleway instance. Tensor9 adds no proxy, translation or latency to your queries. Scaleway operates the database, including patching, backups and failover to the standby. This mapping covers the infrastructure only. Runtime RDS management calls, such as snapshots, restores, replicas, failover and parameter changes, are not supported on Scaleway. Manage the running database through Scaleway's console, CLI or API. ![Database requests (SQL over the MySQL protocol) connect directly to Scaleway Managed DB. Tensor9 compiles the RDS MySQL database instance into Scaleway Managed DB at deployment; there is no management API at runtime.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgdGhlIE15U1FMIHByb3RvY29sKSBjb25uZWN0IGRpcmVjdGx5IHRvIFNjYWxld2F5IE1hbmFnZWQgREIuIFRlbnNvcjkgY29tcGlsZXMgdGhlIFJEUyBNeVNRTCBkYXRhYmFzZSBpbnN0YW5jZSBpbnRvIFNjYWxld2F5IE1hbmFnZWQgREIgYXQgZGVwbG95bWVudDsgdGhlcmUgaXMgbm8gbWFuYWdlbWVudCBBUEkgYXQgcnVudGltZS4iPjxzdHlsZT50ZXh0e2ZvbnQtZmFtaWx5OkludGVyLC1hcHBsZS1zeXN0ZW0sQmxpbmtNYWNTeXN0ZW1Gb250LCdTZWdvZSBVSScsUm9ib3RvLCdIZWx2ZXRpY2EgTmV1ZScsQXJpYWwsc2Fucy1zZXJpZjtmaWxsOiMzMzQxNTV9PC9zdHlsZT4KPGRlZnM+PG1hcmtlciBpZD0iYWhkLWRlcGxveS1zY2FsZXdheS1tYW5hZ2VkLWRiIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM5NGEzYjgiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjgiIHk9IjM0IiB3aWR0aD0iODIwIiBoZWlnaHQ9IjIwNiIgcng9IjE2IiBzdHJva2Utd2lkdGg9IjEuNCIgc3Ryb2tlLWRhc2hhcnJheT0iNSA1IiBzdHlsZT0iZmlsbDojZjhmYWZjO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjI2IiB5PSI1NCIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjg7IGZpbGw6IzA0Nzg1NyI+T04gU0NBTEVXQVk8L3RleHQ+CjxzdmcgeD0iNzkyIiB5PSIzNiIgd2lkdGg9IjE2IiBoZWlnaHQ9IjE2IiB2aWV3Qm94PSIwIDAgMTYgMTYiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiIGZpbGw9Im5vbmUiPjxwYXRoIGQ9Ik04LjM3IDMuNjY2SDUuNzM2QTEuMTgyIDEuMTgyIDAgMCAwIDQuNjkgNC43OXYzLjgxYzAgLjI1Ny4xLjQ4LjI2Ny42NDcuMTY2LjE2Ny4zODkuMjY3LjY0NC4yNjcuNSAwIC45MTItLjQxMi45MTItLjkxM1Y2LjE4NGMwLS4zNzkuMzExLS42OTEuNjktLjY5MWgxLjE4OWMuMjU1IDAgLjQ3OC0uMS42NDQtLjI2N2EuOTI3LjkyNyAwIDAgMCAuMjY3LS42NThjMC0uNTAxLS40MzMtLjkwMi0uOTM0LS45MDJaTTcuMTgxIDEyLjM1N2gyLjYzNWExLjE4MSAxLjE4MSAwIDAgMCAxLjA0NS0xLjEyNnYtMy44MWEuOS45IDAgMCAwLS4yNjctLjY0Ny44OTcuODk3IDAgMCAwLS42NDUtLjI2N2MtLjUgMC0uOTEyLjQxMi0uOTEyLjkxNHYyLjQxN2MwIC4zOC0uMzEuNjkxLS42ODkuNjkxaC0xLjE5Yy0uMjU1IDAtLjQ3Ny4xLS42NDQuMjY4YS45MjcuOTI3IDAgMCAwLS4yNjcuNjU3LjkzNC45MzQgMCAwIDAgLjkzNC45MDJaIiBmaWxsPSIjQkY5NUY5Ii8+IDxwYXRoIGZpbGwtcnVsZT0iZXZlbm9kZCIgY2xpcC1ydWxlPSJldmVub2RkIiBkPSJNNC4wMjQgMGg0Ljc5MWE1LjY4MyA1LjY4MyAwIDAgMSA1LjY5MiA1LjcxNnY3LjU4OEEzLjAyNyAzLjAyNyAwIDAgMSAxMS43NSAxNkg2LjcwM0MzLjU1NyAxNiAxIDEzLjQzNyAxIDEwLjI4NFYzLjAzMUEzLjAzIDMuMDMgMCAwIDEgNC4wMjQgMFptOC42NyA1LjcxNmMwLTIuMTQtMS43NDQtMy44ODktMy44NzktMy44ODloLTQuNzhjLS42NjcgMC0xLjIuNTM1LTEuMiAxLjIwNHY3LjI1M2EzLjg4IDMuODggMCAwIDAgMy44OCAzLjg4OWg0Ljk1N2ExLjE5MyAxLjE5MyAwIDAgMCAxLjAyMy0uOThWNS43MTVaIiBmaWxsPSIjQkY5NUY5Ii8+PC9zdmc+CjxyZWN0IHg9IjI2IiB5PSI3NiIgd2lkdGg9IjEyOCIgaGVpZ2h0PSI2NCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSI5MCIgeT0iMTAwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjEzcHgiPllvdXIgYXBwPC90ZXh0Pgo8dGV4dCB4PSI5MCIgeT0iMTE3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+TXlTUUwgZHJpdmVyPC90ZXh0Pgo8dGV4dCB4PSI5MCIgeT0iMTMyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPnVuY2hhbmdlZDwvdGV4dD4KPHRleHQgeD0iMjAwIiB5PSI4MiIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjg7IGZpbGw6IzA0Nzg1NyI+REFUQUJBU0UgUkVRVUVTVFMgwrcgRElSRUNUIENPTk5FQ1RJT048L3RleHQ+CjxsaW5lIHgxPSIxNTQiIHkxPSIxMDgiIHgyPSI2MTAiIHkyPSIxMDgiIHN0cm9rZS13aWR0aD0iMi4yIiBtYXJrZXItZW5kPSJ1cmwoI2FoZC1kZXBsb3ktc2NhbGV3YXktbWFuYWdlZC1kYikiIHN0eWxlPSJzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSIzODIiIHk9IjEwMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZpbGw6IzA0Nzg1NyI+U1FMIG92ZXIgdGhlIE15U1FMIHByb3RvY29sPC90ZXh0Pgo8cmVjdCB4PSI2MTQiIHk9Ijc2IiB3aWR0aD0iMTk2IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+CjxzdmcgeD0iNzg2IiB5PSI1NiIgd2lkdGg9IjIwIiBoZWlnaHQ9IjIwIiB2aWV3Qm94PSIwIDAgMjQgMjQiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiPjx0aXRsZT5NeVNRTDwvdGl0bGU+PHBhdGggZD0iTTE2LjQwNSA1LjUwMWMtLjExNSAwLS4xOTMuMDE0LS4yNzQuMDMzdi4wMTNoLjAxNGMuMDU0LjEwNC4xNDYuMTguMjE0LjI3My4wNTQuMTA3LjEuMjE0LjE1NC4zMmwuMDE0LS4wMTVjLjA5NC0uMDY2LjE0LS4xNzIuMTQtLjMzMy0uMDQtLjA0Ny0uMDQ2LS4wOTQtLjA4LS4xNC0uMDQtLjA2Ny0uMTI2LS4xLS4xOC0uMTUzek01Ljc3IDE4LjY5NWgtLjkyN2E1MC44NTQgNTAuODU0IDAgMDAtLjI3LTQuNDFoLS4wMDhsLTEuNDEgNC40MUgyLjQ1bC0xLjQtNC40MWgtLjAxYTcyLjg5MiA3Mi44OTIgMCAwMC0uMTk1IDQuNDFIMGMuMDU1LTEuOTY2LjE5Mi0zLjgxLjQxLTUuNTNoMS4xNWwxLjMzNSA0LjA2NGguMDA4bDEuMzQ3LTQuMDY0aDEuMDk1Yy4yNDIgMi4wMTUuMzg0IDMuODYuNDI4IDUuNTN6bTQuMDE3LTQuMDhjLS4zNzggMi4wNDUtLjg3NiAzLjUzMy0xLjQ5MiA0LjQ2LS40ODIuNzE2LTEuMDEgMS4wNzMtMS41ODMgMS4wNzMtLjE1MyAwLS4zNC0uMDQ2LS41NjYtLjEzOHYtLjQ5NGMuMTEuMDE3LjI0LjAyNi4zODYuMDI2LjI2OCAwIC40ODMtLjA3NS42NDctLjIyMi4xOTctLjE4LjI5NS0uMzgyLjI5NS0uNjA1IDAtLjE1NS0uMDc3LS40Ny0uMjMtLjk0NEw2LjIzIDE0LjYxNWguOTFsLjcyNyAyLjM2Yy4xNjQuNTM2LjIzMy45MS4yMDUgMS4xMjMuNC0xLjA2NC42NzgtMi4yMjcuODM1LTMuNDgzem0xMi4zMjUgNC4wOGgtMi42M3YtNS41M2guODg1djQuODVoMS43NDV6bS0zLjMyLjEzNWwtMS4wMTYtLjVjLjA5LS4wNzYuMTc3LS4xNTguMjU1LS4yNS40MzMtLjUwNi42NDgtMS4yNTguNjQ4LTIuMjUzIDAtMS44My0uNzE4LTIuNzQ2LTIuMTU1LTIuNzQ2LS43MDQgMC0xLjI1NC4yMzItMS42NS42OTctLjQzLjUwOC0uNjQ2IDEuMjU2LS42NDYgMi4yNDUgMCAuOTcyLjE5IDEuNjg2LjU3NCAyLjE0LjM1LjQxLjg3Ny42MTUgMS41ODMuNjE1LjI2NCAwIC41MDYtLjAzMy43MjUtLjA5OGwxLjMyNS43NzIuMzYtLjYyMnpNMTUuNSAxNy41ODhjLS4yMjUtLjM2LS4zMzctLjk0LS4zMzctMS43MzYgMC0xLjM5My40MjQtMi4wOSAxLjI3LTIuMDkuNDQzIDAgLjc3LjE2Ny45NzcuNS4yMjQuMzYyLjMzNi45MzYuMzM2IDEuNzIzIDAgMS40MDQtLjQyNCAyLjEwOC0xLjI3IDIuMTA4LS40NDUgMC0uNzctLjE2Ny0uOTc4LS41em0tMS42NTgtLjQyNWMwIC40Ny0uMTcyLjg1Ni0uNTE2IDEuMTU2LS4zNDQuMy0uODAzLjQ1LTEuMzg0LjQ1LS41NDMgMC0xLjA2NC0uMTcyLTEuNTczLS41MTVsLjIzNy0uNDc2Yy40MzguMjIuODMzLjMyOCAxLjE5LjMyOC4zMzIgMCAuNTkzLS4wNzMuNzgzLS4yMmEuNzU0Ljc1NCAwIDAwLjMtLjYxNWMwLS4zMy0uMjMtLjYxLS42NDgtLjg0NS0uMzg4LS4yMTMtMS4xNjMtLjY1Ny0xLjE2My0uNjU3LS40MjItLjMwNy0uNjMyLS42MzYtLjYzMi0xLjE3NyAwLS40NS4xNTctLjgxLjQ3LTEuMDg1LjMxNS0uMjc4LjcyLS40MTUgMS4yMi0uNDE1LjUxMiAwIC45OC4xMzYgMS40LjQxbC0uMjEzLjQ3NmEyLjcyNiAyLjcyNiAwIDAwLTEuMDY0LS4yM2MtLjI4MyAwLS41MDIuMDY4LS42NTQuMjA2YS42ODUuNjg1IDAgMDAtLjI0OC41MjRjMCAuMzI4LjIzNC42MS42NjYuODUuMzkzLjIxNSAxLjE4Ny42NyAxLjE4Ny42Ny40MzMuMzA1LjY0OC42My42NDggMS4xNjh6bTkuMzgyLTUuODUyYy0uNTM1LS4wMTQtLjk1LjA0LTEuMjk3LjE4OC0uMS4wNC0uMjYuMDQtLjI3NC4xNjcuMDU1LjA1My4wNjMuMTQuMTEuMjE0LjA4LjEzNC4yMTguMzEzLjM0Ni40MDcuMTQuMTEuMjguMjE2LjQyNy4zMS4yNi4xNi41NTUuMjU1LjgxLjQxNi4xNDUuMDk0LjI5My4yMTMuNDQuMzEzLjA3My4wNS4xMi4xNC4yMTQuMTcydi0uMDJjLS4wNDYtLjA2LS4wNi0uMTQ3LS4xMDUtLjIxNC0uMDY3LS4wNjctLjEzNC0uMTI3LS4yLS4xOTNhMy4yMjMgMy4yMjMgMCAwMC0uNjk1LS42NzVjLS4yMTQtLjE0Ni0uNjgyLS4zNS0uNzctLjU5NWwtLjAxMy0uMDE0Yy4xNDYtLjAxMy4zMi0uMDY2LjQ2LS4xMDYuMjI3LS4wNi40MzUtLjA0Ny42Ny0uMTA2LjEwNi0uMDI3LjIxMy0uMDYuMzItLjA5NHYtLjA2Yy0uMTItLjEyLS4yMS0uMjgzLS4zMzQtLjM5NWE4Ljg2NyA4Ljg2NyAwIDAwLTEuMTA0LS44MjNjLS4yMS0uMTM0LS40NzYtLjIyLS42OTctLjMzNC0uMDgtLjA0LS4yMTQtLjA2LS4yNi0uMTI3LS4xMi0uMTQ2LS4xOS0uMzQtLjI3NS0uNTE0YTE3LjY5IDE3LjY5IDAgMDEtLjU0Ny0xLjE2M2MtLjEyLS4yNjItLjE5My0uNTIzLS4zNC0uNzYzLS42OS0xLjEzNy0xLjQzNy0xLjgyNi0yLjU4Ni0yLjUtLjI0Ny0uMTQtLjU0My0uMi0uODU2LS4yNzQtLjE2Ny0uMDA4LS4zMzQtLjAyLS41LS4wMjctLjExLS4wNDctLjIxNi0uMTc0LS4zMS0uMjM1LS4zOC0uMjQtMS4zNjQtLjc2LTEuNjQ0LS4wNzItLjE4LjQzNC4yNjcuODYyLjQyMiAxLjA4Mi4xMTUuMTUzLjI2LjMyOC4zNC41LjA0Ny4xMTYuMDYuMjM1LjEwNy4zNTYuMTA2LjI5NC4yMDcuNjIyLjM0Ny44OTcuMDczLjE0LjE1My4yODcuMjQ3LjQxMy4wNTQuMDczLjE0Ni4xMDcuMTY3LjIyNy0uMDk0LjEzNi0uMS4zMzQtLjE1NC41LS4yNC43NTctLjE0NiAxLjY5My4xOTQgMi4yNS4xMDcuMTY2LjM2Mi41MzQuNzAzLjM5My4zLS4xMi4yMzQtLjUuMzItLjgzNS4wMi0uMDguMDA3LS4xMzMuMDQ4LS4xODd2LjAxNWMuMDk0LjE4OC4xODguMzY3LjI3NC41NTUuMjA2LjMyOC41NjYuNjY4Ljg2Ny44OTUuMTYuMTIuMjg3LjMyOC40ODcuNDAydi0uMDJoLS4wMTVjLS4wNDMtLjA1OC0uMS0uMDg2LS4xNTQtLjEzM2EzLjQ0NSAzLjQ0NSAwIDAxLS4zNS0uNCA4Ljc2IDguNzYgMCAwMS0uNzQ3LTEuMjE4Yy0uMTEtLjIxLS4yMDItLjQzNi0uMjktLjY0My0uMDQtLjA4LS4wNC0uMi0uMTA3LS4yNC0uMS4xNDYtLjI0Ny4yNzMtLjMyLjQ1My0uMTI3LjI4OC0uMTQuNjQyLS4xODggMS4wMS0uMDI3LjAwNy0uMDE0IDAtLjAyNy4wMTQtLjIxNC0uMDUyLS4yODctLjI3NC0uMzY3LS40Ni0uMi0uNDc1LS4yMzMtMS4yMzgtLjA2LTEuNzg1LjA0Ny0uMTQuMjQ3LS41ODIuMTY3LS43MTYtLjA0Mi0uMTI3LS4xNzQtLjItLjI0Ny0uMzAzYTIuNDc4IDIuNDc4IDAgMDEtLjI0LS40MjdjLS4xNi0uMzc0LS4yNC0uNzg4LS40MTQtMS4xNjItLjA4LS4xNzMtLjIyLS4zNTQtLjMzNC0uNTEzLS4xMjctLjE4LS4yNjctLjMwNy0uMzY4LS41Mi0uMDMzLS4wNzMtLjA4LS4xOTQtLjAyNy0uMjc0LjAxNC0uMDU0LjA0Mi0uMDc1LjA5NC0uMDkuMDg4LS4wNzIuMzM1LjAyMi40MjIuMDYyLjI0Ny4xLjQ1NS4xOTQuNjYyLjMzNC4wOTQuMDY2LjE5NS4xOTMuMzE1LjIyNmguMTRjLjIxNC4wNDcuNDU1LjAxNC42NTUuMDczLjM1NS4xMTQuNjc1LjI4Ljk2Mi40NmE1Ljk1MyA1Ljk1MyAwIDAxMi4wODUgMi4yODZjLjA4LjE1NC4xMTUuMjk1LjE4OC40NTUuMTQuMzMuMzEzLjY2My40NTUuOTgyLjE0LjMxNS4yNzUuNjM2LjQ3Ni44OTcuMS4xNC41MDIuMjEzLjY4Mi4yODYuMTMzLjA2LjM0LjExNS40Ni4xODguMjMuMTQuNDU0LjMuNjcuNDU0LjExLjA3Ni40NDMuMjQzLjQ2My4zNzh6Ii8+PC9zdmc+Cjx0ZXh0IHg9IjcxMiIgeT0iMTAzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjEycHgiPlNjYWxld2F5IE1hbmFnZWQgREI8L3RleHQ+Cjx0ZXh0IHg9IjcxMiIgeT0iMTIyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+TXlTUUwgZW5naW5lPC90ZXh0Pgo8dGV4dCB4PSIyMDAiIHk9IjE1OCIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjgiPkFUIERFUExPWU1FTlQgwrcgVklBIFRFTlNPUjk8L3RleHQ+CjxyZWN0IHg9IjI2IiB5PSIxNjQiIHdpZHRoPSIxMjgiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iOTAiIHk9IjE4NiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMnB4Ij5Zb3VyIHN0YWNrPC90ZXh0Pgo8dGV4dCB4PSI5MCIgeT0iMjAzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+UkRTIE15U1FMPC90ZXh0Pgo8dGV4dCB4PSI5MCIgeT0iMjE4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+ZGF0YWJhc2UgaW5zdGFuY2U8L3RleHQ+CjxsaW5lIHgxPSIxNTQiIHkxPSIxOTYiIHgyPSIzMDAiIHkyPSIxOTYiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtZGVwbG95LXNjYWxld2F5LW1hbmFnZWQtZGIpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iMjI3IiB5PSIxODgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiIj5kZWNsYXJhdGlvbjwvdGV4dD4KPHJlY3QgeD0iMzA0IiB5PSIxNjQiIHdpZHRoPSIxODAiIGhlaWdodD0iNjYiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iMzk0IiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSIzOTQiIHk9IjIwOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+Y29tcGlsZXMgb25jZTwvdGV4dD4KPHBhdGggZD0iTTQ4NCwxOTYgTDcxMiwxOTYgTDcxMiwxNDYiIGZpbGw9Im5vbmUiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtZGVwbG95LXNjYWxld2F5LW1hbmFnZWQtZGIpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iNTk4IiB5PSIxODgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiIj5wcm92aXNpb25zIHRoZSBpbnN0YW5jZTwvdGV4dD4KPHRleHQgeD0iNTk4IiB5PSIyMjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5ubyBSRFMgbWFuYWdlbWVudCBBUEkgYXQgcnVudGltZTwvdGV4dD4KPC9zdmc+) ![Database requests (SQL over the MySQL protocol) connect directly to Scaleway Managed DB. Tensor9 compiles the RDS MySQL database instance into Scaleway Managed DB at deployment; there is no management API at runtime.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgdGhlIE15U1FMIHByb3RvY29sKSBjb25uZWN0IGRpcmVjdGx5IHRvIFNjYWxld2F5IE1hbmFnZWQgREIuIFRlbnNvcjkgY29tcGlsZXMgdGhlIFJEUyBNeVNRTCBkYXRhYmFzZSBpbnN0YW5jZSBpbnRvIFNjYWxld2F5IE1hbmFnZWQgREIgYXQgZGVwbG95bWVudDsgdGhlcmUgaXMgbm8gbWFuYWdlbWVudCBBUEkgYXQgcnVudGltZS4iPjxzdHlsZT50ZXh0e2ZvbnQtZmFtaWx5OkludGVyLC1hcHBsZS1zeXN0ZW0sQmxpbmtNYWNTeXN0ZW1Gb250LCdTZWdvZSBVSScsUm9ib3RvLCdIZWx2ZXRpY2EgTmV1ZScsQXJpYWwsc2Fucy1zZXJpZjtmaWxsOiNjYmQ1ZTF9PC9zdHlsZT4KPGRlZnM+PG1hcmtlciBpZD0iYWhkLWRlcGxveS1zY2FsZXdheS1tYW5hZ2VkLWRiIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM2NDc0OGIiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjgiIHk9IjM0IiB3aWR0aD0iODIwIiBoZWlnaHQ9IjIwNiIgcng9IjE2IiBzdHJva2Utd2lkdGg9IjEuNCIgc3Ryb2tlLWRhc2hhcnJheT0iNSA1IiBzdHlsZT0iZmlsbDojMGYxNzJhO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjI2IiB5PSI1NCIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGI7IGZpbGw6IzZlZTdiNyI+T04gU0NBTEVXQVk8L3RleHQ+CjxzdmcgeD0iNzkyIiB5PSIzNiIgd2lkdGg9IjE2IiBoZWlnaHQ9IjE2IiB2aWV3Qm94PSIwIDAgMTYgMTYiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiIGZpbGw9Im5vbmUiPjxwYXRoIGQ9Ik04LjM3IDMuNjY2SDUuNzM2QTEuMTgyIDEuMTgyIDAgMCAwIDQuNjkgNC43OXYzLjgxYzAgLjI1Ny4xLjQ4LjI2Ny42NDcuMTY2LjE2Ny4zODkuMjY3LjY0NC4yNjcuNSAwIC45MTItLjQxMi45MTItLjkxM1Y2LjE4NGMwLS4zNzkuMzExLS42OTEuNjktLjY5MWgxLjE4OWMuMjU1IDAgLjQ3OC0uMS42NDQtLjI2N2EuOTI3LjkyNyAwIDAgMCAuMjY3LS42NThjMC0uNTAxLS40MzMtLjkwMi0uOTM0LS45MDJaTTcuMTgxIDEyLjM1N2gyLjYzNWExLjE4MSAxLjE4MSAwIDAgMCAxLjA0NS0xLjEyNnYtMy44MWEuOS45IDAgMCAwLS4yNjctLjY0Ny44OTcuODk3IDAgMCAwLS42NDUtLjI2N2MtLjUgMC0uOTEyLjQxMi0uOTEyLjkxNHYyLjQxN2MwIC4zOC0uMzEuNjkxLS42ODkuNjkxaC0xLjE5Yy0uMjU1IDAtLjQ3Ny4xLS42NDQuMjY4YS45MjcuOTI3IDAgMCAwLS4yNjcuNjU3LjkzNC45MzQgMCAwIDAgLjkzNC45MDJaIiBmaWxsPSIjQkY5NUY5Ii8+IDxwYXRoIGZpbGwtcnVsZT0iZXZlbm9kZCIgY2xpcC1ydWxlPSJldmVub2RkIiBkPSJNNC4wMjQgMGg0Ljc5MWE1LjY4MyA1LjY4MyAwIDAgMSA1LjY5MiA1LjcxNnY3LjU4OEEzLjAyNyAzLjAyNyAwIDAgMSAxMS43NSAxNkg2LjcwM0MzLjU1NyAxNiAxIDEzLjQzNyAxIDEwLjI4NFYzLjAzMUEzLjAzIDMuMDMgMCAwIDEgNC4wMjQgMFptOC42NyA1LjcxNmMwLTIuMTQtMS43NDQtMy44ODktMy44NzktMy44ODloLTQuNzhjLS42NjcgMC0xLjIuNTM1LTEuMiAxLjIwNHY3LjI1M2EzLjg4IDMuODggMCAwIDAgMy44OCAzLjg4OWg0Ljk1N2ExLjE5MyAxLjE5MyAwIDAgMCAxLjAyMy0uOThWNS43MTVaIiBmaWxsPSIjQkY5NUY5Ii8+PC9zdmc+CjxyZWN0IHg9IjI2IiB5PSI3NiIgd2lkdGg9IjEyOCIgaGVpZ2h0PSI2NCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSI5MCIgeT0iMTAwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjEzcHgiPllvdXIgYXBwPC90ZXh0Pgo8dGV4dCB4PSI5MCIgeT0iMTE3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+TXlTUUwgZHJpdmVyPC90ZXh0Pgo8dGV4dCB4PSI5MCIgeT0iMTMyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPnVuY2hhbmdlZDwvdGV4dD4KPHRleHQgeD0iMjAwIiB5PSI4MiIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGI7IGZpbGw6IzZlZTdiNyI+REFUQUJBU0UgUkVRVUVTVFMgwrcgRElSRUNUIENPTk5FQ1RJT048L3RleHQ+CjxsaW5lIHgxPSIxNTQiIHkxPSIxMDgiIHgyPSI2MTAiIHkyPSIxMDgiIHN0cm9rZS13aWR0aD0iMi4yIiBtYXJrZXItZW5kPSJ1cmwoI2FoZC1kZXBsb3ktc2NhbGV3YXktbWFuYWdlZC1kYikiIHN0eWxlPSJzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSIzODIiIHk9IjEwMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZpbGw6IzZlZTdiNyI+U1FMIG92ZXIgdGhlIE15U1FMIHByb3RvY29sPC90ZXh0Pgo8cmVjdCB4PSI2MTQiIHk9Ijc2IiB3aWR0aD0iMTk2IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+CjxzdmcgeD0iNzg2IiB5PSI1NiIgd2lkdGg9IjIwIiBoZWlnaHQ9IjIwIiB2aWV3Qm94PSIwIDAgMjQgMjQiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiPjx0aXRsZT5NeVNRTDwvdGl0bGU+PHBhdGggZD0iTTE2LjQwNSA1LjUwMWMtLjExNSAwLS4xOTMuMDE0LS4yNzQuMDMzdi4wMTNoLjAxNGMuMDU0LjEwNC4xNDYuMTguMjE0LjI3My4wNTQuMTA3LjEuMjE0LjE1NC4zMmwuMDE0LS4wMTVjLjA5NC0uMDY2LjE0LS4xNzIuMTQtLjMzMy0uMDQtLjA0Ny0uMDQ2LS4wOTQtLjA4LS4xNC0uMDQtLjA2Ny0uMTI2LS4xLS4xOC0uMTUzek01Ljc3IDE4LjY5NWgtLjkyN2E1MC44NTQgNTAuODU0IDAgMDAtLjI3LTQuNDFoLS4wMDhsLTEuNDEgNC40MUgyLjQ1bC0xLjQtNC40MWgtLjAxYTcyLjg5MiA3Mi44OTIgMCAwMC0uMTk1IDQuNDFIMGMuMDU1LTEuOTY2LjE5Mi0zLjgxLjQxLTUuNTNoMS4xNWwxLjMzNSA0LjA2NGguMDA4bDEuMzQ3LTQuMDY0aDEuMDk1Yy4yNDIgMi4wMTUuMzg0IDMuODYuNDI4IDUuNTN6bTQuMDE3LTQuMDhjLS4zNzggMi4wNDUtLjg3NiAzLjUzMy0xLjQ5MiA0LjQ2LS40ODIuNzE2LTEuMDEgMS4wNzMtMS41ODMgMS4wNzMtLjE1MyAwLS4zNC0uMDQ2LS41NjYtLjEzOHYtLjQ5NGMuMTEuMDE3LjI0LjAyNi4zODYuMDI2LjI2OCAwIC40ODMtLjA3NS42NDctLjIyMi4xOTctLjE4LjI5NS0uMzgyLjI5NS0uNjA1IDAtLjE1NS0uMDc3LS40Ny0uMjMtLjk0NEw2LjIzIDE0LjYxNWguOTFsLjcyNyAyLjM2Yy4xNjQuNTM2LjIzMy45MS4yMDUgMS4xMjMuNC0xLjA2NC42NzgtMi4yMjcuODM1LTMuNDgzem0xMi4zMjUgNC4wOGgtMi42M3YtNS41M2guODg1djQuODVoMS43NDV6bS0zLjMyLjEzNWwtMS4wMTYtLjVjLjA5LS4wNzYuMTc3LS4xNTguMjU1LS4yNS40MzMtLjUwNi42NDgtMS4yNTguNjQ4LTIuMjUzIDAtMS44My0uNzE4LTIuNzQ2LTIuMTU1LTIuNzQ2LS43MDQgMC0xLjI1NC4yMzItMS42NS42OTctLjQzLjUwOC0uNjQ2IDEuMjU2LS42NDYgMi4yNDUgMCAuOTcyLjE5IDEuNjg2LjU3NCAyLjE0LjM1LjQxLjg3Ny42MTUgMS41ODMuNjE1LjI2NCAwIC41MDYtLjAzMy43MjUtLjA5OGwxLjMyNS43NzIuMzYtLjYyMnpNMTUuNSAxNy41ODhjLS4yMjUtLjM2LS4zMzctLjk0LS4zMzctMS43MzYgMC0xLjM5My40MjQtMi4wOSAxLjI3LTIuMDkuNDQzIDAgLjc3LjE2Ny45NzcuNS4yMjQuMzYyLjMzNi45MzYuMzM2IDEuNzIzIDAgMS40MDQtLjQyNCAyLjEwOC0xLjI3IDIuMTA4LS40NDUgMC0uNzctLjE2Ny0uOTc4LS41em0tMS42NTgtLjQyNWMwIC40Ny0uMTcyLjg1Ni0uNTE2IDEuMTU2LS4zNDQuMy0uODAzLjQ1LTEuMzg0LjQ1LS41NDMgMC0xLjA2NC0uMTcyLTEuNTczLS41MTVsLjIzNy0uNDc2Yy40MzguMjIuODMzLjMyOCAxLjE5LjMyOC4zMzIgMCAuNTkzLS4wNzMuNzgzLS4yMmEuNzU0Ljc1NCAwIDAwLjMtLjYxNWMwLS4zMy0uMjMtLjYxLS42NDgtLjg0NS0uMzg4LS4yMTMtMS4xNjMtLjY1Ny0xLjE2My0uNjU3LS40MjItLjMwNy0uNjMyLS42MzYtLjYzMi0xLjE3NyAwLS40NS4xNTctLjgxLjQ3LTEuMDg1LjMxNS0uMjc4LjcyLS40MTUgMS4yMi0uNDE1LjUxMiAwIC45OC4xMzYgMS40LjQxbC0uMjEzLjQ3NmEyLjcyNiAyLjcyNiAwIDAwLTEuMDY0LS4yM2MtLjI4MyAwLS41MDIuMDY4LS42NTQuMjA2YS42ODUuNjg1IDAgMDAtLjI0OC41MjRjMCAuMzI4LjIzNC42MS42NjYuODUuMzkzLjIxNSAxLjE4Ny42NyAxLjE4Ny42Ny40MzMuMzA1LjY0OC42My42NDggMS4xNjh6bTkuMzgyLTUuODUyYy0uNTM1LS4wMTQtLjk1LjA0LTEuMjk3LjE4OC0uMS4wNC0uMjYuMDQtLjI3NC4xNjcuMDU1LjA1My4wNjMuMTQuMTEuMjE0LjA4LjEzNC4yMTguMzEzLjM0Ni40MDcuMTQuMTEuMjguMjE2LjQyNy4zMS4yNi4xNi41NTUuMjU1LjgxLjQxNi4xNDUuMDk0LjI5My4yMTMuNDQuMzEzLjA3My4wNS4xMi4xNC4yMTQuMTcydi0uMDJjLS4wNDYtLjA2LS4wNi0uMTQ3LS4xMDUtLjIxNC0uMDY3LS4wNjctLjEzNC0uMTI3LS4yLS4xOTNhMy4yMjMgMy4yMjMgMCAwMC0uNjk1LS42NzVjLS4yMTQtLjE0Ni0uNjgyLS4zNS0uNzctLjU5NWwtLjAxMy0uMDE0Yy4xNDYtLjAxMy4zMi0uMDY2LjQ2LS4xMDYuMjI3LS4wNi40MzUtLjA0Ny42Ny0uMTA2LjEwNi0uMDI3LjIxMy0uMDYuMzItLjA5NHYtLjA2Yy0uMTItLjEyLS4yMS0uMjgzLS4zMzQtLjM5NWE4Ljg2NyA4Ljg2NyAwIDAwLTEuMTA0LS44MjNjLS4yMS0uMTM0LS40NzYtLjIyLS42OTctLjMzNC0uMDgtLjA0LS4yMTQtLjA2LS4yNi0uMTI3LS4xMi0uMTQ2LS4xOS0uMzQtLjI3NS0uNTE0YTE3LjY5IDE3LjY5IDAgMDEtLjU0Ny0xLjE2M2MtLjEyLS4yNjItLjE5My0uNTIzLS4zNC0uNzYzLS42OS0xLjEzNy0xLjQzNy0xLjgyNi0yLjU4Ni0yLjUtLjI0Ny0uMTQtLjU0My0uMi0uODU2LS4yNzQtLjE2Ny0uMDA4LS4zMzQtLjAyLS41LS4wMjctLjExLS4wNDctLjIxNi0uMTc0LS4zMS0uMjM1LS4zOC0uMjQtMS4zNjQtLjc2LTEuNjQ0LS4wNzItLjE4LjQzNC4yNjcuODYyLjQyMiAxLjA4Mi4xMTUuMTUzLjI2LjMyOC4zNC41LjA0Ny4xMTYuMDYuMjM1LjEwNy4zNTYuMTA2LjI5NC4yMDcuNjIyLjM0Ny44OTcuMDczLjE0LjE1My4yODcuMjQ3LjQxMy4wNTQuMDczLjE0Ni4xMDcuMTY3LjIyNy0uMDk0LjEzNi0uMS4zMzQtLjE1NC41LS4yNC43NTctLjE0NiAxLjY5My4xOTQgMi4yNS4xMDcuMTY2LjM2Mi41MzQuNzAzLjM5My4zLS4xMi4yMzQtLjUuMzItLjgzNS4wMi0uMDguMDA3LS4xMzMuMDQ4LS4xODd2LjAxNWMuMDk0LjE4OC4xODguMzY3LjI3NC41NTUuMjA2LjMyOC41NjYuNjY4Ljg2Ny44OTUuMTYuMTIuMjg3LjMyOC40ODcuNDAydi0uMDJoLS4wMTVjLS4wNDMtLjA1OC0uMS0uMDg2LS4xNTQtLjEzM2EzLjQ0NSAzLjQ0NSAwIDAxLS4zNS0uNCA4Ljc2IDguNzYgMCAwMS0uNzQ3LTEuMjE4Yy0uMTEtLjIxLS4yMDItLjQzNi0uMjktLjY0My0uMDQtLjA4LS4wNC0uMi0uMTA3LS4yNC0uMS4xNDYtLjI0Ny4yNzMtLjMyLjQ1My0uMTI3LjI4OC0uMTQuNjQyLS4xODggMS4wMS0uMDI3LjAwNy0uMDE0IDAtLjAyNy4wMTQtLjIxNC0uMDUyLS4yODctLjI3NC0uMzY3LS40Ni0uMi0uNDc1LS4yMzMtMS4yMzgtLjA2LTEuNzg1LjA0Ny0uMTQuMjQ3LS41ODIuMTY3LS43MTYtLjA0Mi0uMTI3LS4xNzQtLjItLjI0Ny0uMzAzYTIuNDc4IDIuNDc4IDAgMDEtLjI0LS40MjdjLS4xNi0uMzc0LS4yNC0uNzg4LS40MTQtMS4xNjItLjA4LS4xNzMtLjIyLS4zNTQtLjMzNC0uNTEzLS4xMjctLjE4LS4yNjctLjMwNy0uMzY4LS41Mi0uMDMzLS4wNzMtLjA4LS4xOTQtLjAyNy0uMjc0LjAxNC0uMDU0LjA0Mi0uMDc1LjA5NC0uMDkuMDg4LS4wNzIuMzM1LjAyMi40MjIuMDYyLjI0Ny4xLjQ1NS4xOTQuNjYyLjMzNC4wOTQuMDY2LjE5NS4xOTMuMzE1LjIyNmguMTRjLjIxNC4wNDcuNDU1LjAxNC42NTUuMDczLjM1NS4xMTQuNjc1LjI4Ljk2Mi40NmE1Ljk1MyA1Ljk1MyAwIDAxMi4wODUgMi4yODZjLjA4LjE1NC4xMTUuMjk1LjE4OC40NTUuMTQuMzMuMzEzLjY2My40NTUuOTgyLjE0LjMxNS4yNzUuNjM2LjQ3Ni44OTcuMS4xNC41MDIuMjEzLjY4Mi4yODYuMTMzLjA2LjM0LjExNS40Ni4xODguMjMuMTQuNDU0LjMuNjcuNDU0LjExLjA3Ni40NDMuMjQzLjQ2My4zNzh6Ii8+PC9zdmc+Cjx0ZXh0IHg9IjcxMiIgeT0iMTAzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjEycHgiPlNjYWxld2F5IE1hbmFnZWQgREI8L3RleHQ+Cjx0ZXh0IHg9IjcxMiIgeT0iMTIyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+TXlTUUwgZW5naW5lPC90ZXh0Pgo8dGV4dCB4PSIyMDAiIHk9IjE1OCIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGIiPkFUIERFUExPWU1FTlQgwrcgVklBIFRFTlNPUjk8L3RleHQ+CjxyZWN0IHg9IjI2IiB5PSIxNjQiIHdpZHRoPSIxMjgiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iOTAiIHk9IjE4NiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMnB4Ij5Zb3VyIHN0YWNrPC90ZXh0Pgo8dGV4dCB4PSI5MCIgeT0iMjAzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+UkRTIE15U1FMPC90ZXh0Pgo8dGV4dCB4PSI5MCIgeT0iMjE4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+ZGF0YWJhc2UgaW5zdGFuY2U8L3RleHQ+CjxsaW5lIHgxPSIxNTQiIHkxPSIxOTYiIHgyPSIzMDAiIHkyPSIxOTYiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtZGVwbG95LXNjYWxld2F5LW1hbmFnZWQtZGIpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iMjI3IiB5PSIxODgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4Ij5kZWNsYXJhdGlvbjwvdGV4dD4KPHJlY3QgeD0iMzA0IiB5PSIxNjQiIHdpZHRoPSIxODAiIGhlaWdodD0iNjYiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iMzk0IiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSIzOTQiIHk9IjIwOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+Y29tcGlsZXMgb25jZTwvdGV4dD4KPHBhdGggZD0iTTQ4NCwxOTYgTDcxMiwxOTYgTDcxMiwxNDYiIGZpbGw9Im5vbmUiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtZGVwbG95LXNjYWxld2F5LW1hbmFnZWQtZGIpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iNTk4IiB5PSIxODgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4Ij5wcm92aXNpb25zIHRoZSBpbnN0YW5jZTwvdGV4dD4KPHRleHQgeD0iNTk4IiB5PSIyMjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5ubyBSRFMgbWFuYWdlbWVudCBBUEkgYXQgcnVudGltZTwvdGV4dD4KPC9zdmc+) Queries reach the database directly; Tensor9 acts only when the product is deployed. #### Database connections Scaleway runs standard MySQL, so your SQL, drivers, object-relational mappers (ORMs), prepared statements, data types and transaction semantics remain unchanged. Connection strings change: Scaleway assigns the endpoint and its port, and Tensor9 puts them in your application's configuration. Credentials change as well. The instance gets its own admin user, and its password arrives through a sensitive deployment variable; no plaintext password is written into the infrastructure code the customer applies. Anything that reads the master username from an output receives the provisioned user instead. IAM database authentication is not supported on this backend. An application that requests short-lived tokens from AWS IAM cannot obtain a credential on Scaleway and fails to connect, even though the database itself is healthy. Switch such clients to a password-based database user before cutover. #### Database management Tensor9 reads the database instance your stack declares and writes the matching Scaleway resources once, when the product is deployed. Settings with a direct equivalent are kept. Settings that Scaleway handles differently are translated and called out. Settings with no equivalent are removed, and the deployment reports each one instead of dropping it silently. After deployment there is no RDS management API on this backend. Day-to-day operations, such as resizing the node or volume, adding read replicas, changing backup frequency and retention, restoring a backup and editing engine settings, use Scaleway's console, CLI or API against the customer's own Scaleway project. ![What each YOUR RDS MYSQL DECLARATION setting becomes on ON SCALEWAY when Tensor9 deploys the product.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMzQwIiB2aWV3Qm94PSIwIDAgODM2IDM0MCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJXaGF0IGVhY2ggWU9VUiBSRFMgTVlTUUwgREVDTEFSQVRJT04gc2V0dGluZyBiZWNvbWVzIG9uIE9OIFNDQUxFV0FZIHdoZW4gVGVuc29yOSBkZXBsb3lzIHRoZSBwcm9kdWN0LiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaHQteW91ci1yZHMtbXlzcWwtZGVjbGFyYXRpb24tb24tc2NhbGV3YXkiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjYiIG1hcmtlckhlaWdodD0iNiIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6Izk0YTNiOCIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iMTYiIHk9IjIwIiB3aWR0aD0iODA0IiBoZWlnaHQ9IjMxMiIgcng9IjEyIiBmaWxsPSJub25lIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9InN0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjMyIiB5PSI0NCIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjgiPllPVVIgUkRTIE1ZU1FMIERFQ0xBUkFUSU9OPC90ZXh0Pgo8dGV4dCB4PSIzODQiIHk9IjQ0IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzk0YTNiODsgZmlsbDojMDQ3ODU3Ij5PTiBTQ0FMRVdBWTwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjU4IiB3aWR0aD0iODA0IiBoZWlnaHQ9IjMwIiBzdHlsZT0iZmlsbDojZmZmZmZmIi8+Cjx0ZXh0IHg9IjMyIiB5PSI3NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+SW5zdGFuY2UgY2xhc3M8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSI3MyIgeDI9IjM2OCIgeTI9IjczIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtbXlzcWwtZGVjbGFyYXRpb24tb24tc2NhbGV3YXkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iMzg0IiB5PSI3NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+R2VuZXJhbC1wdXJwb3NlIG5vZGUsIDItOCB2Q1BVPC90ZXh0Pgo8cmVjdCB4PSI3MDQiIHk9IjY0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNiNDUzMDkiLz4KPHRleHQgeD0iNzU0IiB5PSI3NyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZpbGw6I2I0NTMwOSI+Y2hhbmdlZDwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9Ijg4IiB3aWR0aD0iODA0IiBoZWlnaHQ9IjMwIiBzdHlsZT0iZmlsbDojZjhmYWZjIi8+Cjx0ZXh0IHg9IjMyIiB5PSIxMDciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiOyBmb250LXNpemU6MTJweDtmaWxsOiMwZjE3MmEiPk11bHRpLUFaPC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMTAzIiB4Mj0iMzY4IiB5Mj0iMTAzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtbXlzcWwtZGVjbGFyYXRpb24tb24tc2NhbGV3YXkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iMzg0IiB5PSIxMDciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiOyBmb250LXNpemU6MTJweDtmaWxsOiMwZjE3MmEiPkhvdCBzdGFuZGJ5IGluIHRoZSBzYW1lIGRhdGEgY2VudGVyPC90ZXh0Pgo8cmVjdCB4PSI3MDQiIHk9Ijk0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNiNDUzMDkiLz4KPHRleHQgeD0iNzU0IiB5PSIxMDciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiNiNDUzMDkiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIxMTgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiNmZmZmZmYiLz4KPHRleHQgeD0iMzIiIHk9IjEzNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+QWxsb2NhdGVkIHN0b3JhZ2U8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIxMzMiIHgyPSIzNjgiIHkyPSIxMzMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLXJkcy1teXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8dGV4dCB4PSIzODQiIHk9IjEzNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+QmxvY2sgc3RvcmFnZSB2b2x1bWUsIDUtMTAsMDAwIEdCPC90ZXh0Pgo8cmVjdCB4PSI3MDQiIHk9IjEyNCIgd2lkdGg9IjEwMCIgaGVpZ2h0PSIxOCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9Ijc1NCIgeT0iMTM3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YjsgZmlsbDojMDQ3ODU3Ij5tYXBwZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIxNDgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiNmOGZhZmMiLz4KPHRleHQgeD0iMzIiIHk9IjE2NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+TXlTUUwgZW5naW5lIHZlcnNpb248L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIxNjMiIHgyPSIzNjgiIHkyPSIxNjMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLXJkcy1teXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8dGV4dCB4PSIzODQiIHk9IjE2NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+TXlTUUwgOCwgdGhlIG9ubHkgdmVyc2lvbiBTY2FsZXdheSBvZmZlcnM8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMTU0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNiNDUzMDkiLz4KPHRleHQgeD0iNzU0IiB5PSIxNjciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiNiNDUzMDkiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIxNzgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiNmZmZmZmYiLz4KPHRleHQgeD0iMzIiIHk9IjE5NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+TWFzdGVyIHVzZXJuYW1lIGFuZCBwYXNzd29yZDwvdGV4dD4KPGxpbmUgeDE9IjMxOCIgeTE9IjE5MyIgeDI9IjM2OCIgeTI9IjE5MyIgc3Ryb2tlLXdpZHRoPSIxLjYiIG1hcmtlci1lbmQ9InVybCgjYWh0LXlvdXItcmRzLW15c3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjM4NCIgeT0iMTk3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjEycHg7ZmlsbDojMGYxNzJhIj5Qcm92aXNpb25lZCBhZG1pbiB1c2VyLCBwYXNzd29yZCB2aWEgdmFyaWFibGU8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMTg0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNiNDUzMDkiLz4KPHRleHQgeD0iNzU0IiB5PSIxOTciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiNiNDUzMDkiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIyMDgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiNmOGZhZmMiLz4KPHRleHQgeD0iMzIiIHk9IjIyNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+SUFNIGRhdGFiYXNlIGF1dGhlbnRpY2F0aW9uPC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMjIzIiB4Mj0iMzY4IiB5Mj0iMjIzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtbXlzcWwtZGVjbGFyYXRpb24tb24tc2NhbGV3YXkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iMzg0IiB5PSIyMjciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiOyBmb250LXNpemU6MTJweDtmaWxsOiMwZjE3MmEiPk5vIGVxdWl2YWxlbnQ7IGNsaWVudHMgY2Fubm90IGNvbm5lY3Q8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMjE0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNkYzI2MjYiLz4KPHRleHQgeD0iNzU0IiB5PSIyMjciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiNkYzI2MjYiPm9taXR0ZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIyMzgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiNmZmZmZmYiLz4KPHRleHQgeD0iMzIiIHk9IjI1NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+QmFja3VwIHJldGVudGlvbiBhbmQgd2luZG93PC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMjUzIiB4Mj0iMzY4IiB5Mj0iMjUzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtbXlzcWwtZGVjbGFyYXRpb24tb24tc2NhbGV3YXkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iMzg0IiB5PSIyNTciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiOyBmb250LXNpemU6MTJweDtmaWxsOiMwZjE3MmEiPlNjYWxld2F5J3Mgb3duIGJhY2t1cCBzY2hlZHVsZTwvdGV4dD4KPHJlY3QgeD0iNzA0IiB5PSIyNDQiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTgiIHJ4PSI5IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2I0NTMwOSIvPgo8dGV4dCB4PSI3NTQiIHk9IjI1NyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZpbGw6I2I0NTMwOSI+Y2hhbmdlZDwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjI2OCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzMCIgc3R5bGU9ImZpbGw6I2Y4ZmFmYyIvPgo8dGV4dCB4PSIzMiIgeT0iMjg3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjEycHg7ZmlsbDojMGYxNzJhIj5DdXN0b21lci1tYW5hZ2VkIEtNUyBrZXk8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIyODMiIHgyPSIzNjgiIHkyPSIyODMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLXJkcy1teXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8dGV4dCB4PSIzODQiIHk9IjI4NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+U2NhbGV3YXktbWFuYWdlZCBlbmNyeXB0aW9uIGF0IHJlc3Q8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMjc0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNiNDUzMDkiLz4KPHRleHQgeD0iNzU0IiB5PSIyODciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiNiNDUzMDkiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIyOTgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiNmZmZmZmYiLz4KPHRleHQgeD0iMzIiIHk9IjMxNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+UGFyYW1ldGVyIGFuZCBvcHRpb24gZ3JvdXBzPC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMzEzIiB4Mj0iMzY4IiB5Mj0iMzEzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtbXlzcWwtZGVjbGFyYXRpb24tb24tc2NhbGV3YXkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iMzg0IiB5PSIzMTciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiOyBmb250LXNpemU6MTJweDtmaWxsOiMwZjE3MmEiPlJlbW92ZWQ7IHNldCBlbmdpbmUgc2V0dGluZ3Mgb24gdGhlIGluc3RhbmNlPC90ZXh0Pgo8cmVjdCB4PSI3MDQiIHk9IjMwNCIgd2lkdGg9IjEwMCIgaGVpZ2h0PSIxOCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojZGMyNjI2Ii8+Cjx0ZXh0IHg9Ijc1NCIgeT0iMzE3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YjsgZmlsbDojZGMyNjI2Ij5vbWl0dGVkPC90ZXh0Pgo8L3N2Zz4=) ![What each YOUR RDS MYSQL DECLARATION setting becomes on ON SCALEWAY when Tensor9 deploys the product.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMzQwIiB2aWV3Qm94PSIwIDAgODM2IDM0MCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJXaGF0IGVhY2ggWU9VUiBSRFMgTVlTUUwgREVDTEFSQVRJT04gc2V0dGluZyBiZWNvbWVzIG9uIE9OIFNDQUxFV0FZIHdoZW4gVGVuc29yOSBkZXBsb3lzIHRoZSBwcm9kdWN0LiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaHQteW91ci1yZHMtbXlzcWwtZGVjbGFyYXRpb24tb24tc2NhbGV3YXkiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjYiIG1hcmtlckhlaWdodD0iNiIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6IzY0NzQ4YiIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iMTYiIHk9IjIwIiB3aWR0aD0iODA0IiBoZWlnaHQ9IjMxMiIgcng9IjEyIiBmaWxsPSJub25lIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9InN0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjMyIiB5PSI0NCIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGIiPllPVVIgUkRTIE1ZU1FMIERFQ0xBUkFUSU9OPC90ZXh0Pgo8dGV4dCB4PSIzODQiIHk9IjQ0IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzY0NzQ4YjsgZmlsbDojNmVlN2I3Ij5PTiBTQ0FMRVdBWTwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjU4IiB3aWR0aD0iODA0IiBoZWlnaHQ9IjMwIiBzdHlsZT0iZmlsbDojMWUyOTNiIi8+Cjx0ZXh0IHg9IjMyIiB5PSI3NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+SW5zdGFuY2UgY2xhc3M8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSI3MyIgeDI9IjM2OCIgeTI9IjczIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtbXlzcWwtZGVjbGFyYXRpb24tb24tc2NhbGV3YXkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iMzg0IiB5PSI3NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+R2VuZXJhbC1wdXJwb3NlIG5vZGUsIDItOCB2Q1BVPC90ZXh0Pgo8cmVjdCB4PSI3MDQiIHk9IjY0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiNmYmJmMjQiLz4KPHRleHQgeD0iNzU0IiB5PSI3NyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZpbGw6I2ZiYmYyNCI+Y2hhbmdlZDwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9Ijg4IiB3aWR0aD0iODA0IiBoZWlnaHQ9IjMwIiBzdHlsZT0iZmlsbDojMGYxNzJhIi8+Cjx0ZXh0IHg9IjMyIiB5PSIxMDciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4OyBmb250LXNpemU6MTJweDtmaWxsOiNmMWY1ZjkiPk11bHRpLUFaPC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMTAzIiB4Mj0iMzY4IiB5Mj0iMTAzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtbXlzcWwtZGVjbGFyYXRpb24tb24tc2NhbGV3YXkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iMzg0IiB5PSIxMDciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4OyBmb250LXNpemU6MTJweDtmaWxsOiNmMWY1ZjkiPkhvdCBzdGFuZGJ5IGluIHRoZSBzYW1lIGRhdGEgY2VudGVyPC90ZXh0Pgo8cmVjdCB4PSI3MDQiIHk9Ijk0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiNmYmJmMjQiLz4KPHRleHQgeD0iNzU0IiB5PSIxMDciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiNmYmJmMjQiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIxMTgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiMxZTI5M2IiLz4KPHRleHQgeD0iMzIiIHk9IjEzNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+QWxsb2NhdGVkIHN0b3JhZ2U8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIxMzMiIHgyPSIzNjgiIHkyPSIxMzMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLXJkcy1teXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8dGV4dCB4PSIzODQiIHk9IjEzNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+QmxvY2sgc3RvcmFnZSB2b2x1bWUsIDUtMTAsMDAwIEdCPC90ZXh0Pgo8cmVjdCB4PSI3MDQiIHk9IjEyNCIgd2lkdGg9IjEwMCIgaGVpZ2h0PSIxOCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9Ijc1NCIgeT0iMTM3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiODsgZmlsbDojNmVlN2I3Ij5tYXBwZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIxNDgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiMwZjE3MmEiLz4KPHRleHQgeD0iMzIiIHk9IjE2NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+TXlTUUwgZW5naW5lIHZlcnNpb248L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIxNjMiIHgyPSIzNjgiIHkyPSIxNjMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLXJkcy1teXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8dGV4dCB4PSIzODQiIHk9IjE2NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+TXlTUUwgOCwgdGhlIG9ubHkgdmVyc2lvbiBTY2FsZXdheSBvZmZlcnM8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMTU0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiNmYmJmMjQiLz4KPHRleHQgeD0iNzU0IiB5PSIxNjciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiNmYmJmMjQiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIxNzgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiMxZTI5M2IiLz4KPHRleHQgeD0iMzIiIHk9IjE5NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+TWFzdGVyIHVzZXJuYW1lIGFuZCBwYXNzd29yZDwvdGV4dD4KPGxpbmUgeDE9IjMxOCIgeTE9IjE5MyIgeDI9IjM2OCIgeTI9IjE5MyIgc3Ryb2tlLXdpZHRoPSIxLjYiIG1hcmtlci1lbmQ9InVybCgjYWh0LXlvdXItcmRzLW15c3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjM4NCIgeT0iMTk3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjEycHg7ZmlsbDojZjFmNWY5Ij5Qcm92aXNpb25lZCBhZG1pbiB1c2VyLCBwYXNzd29yZCB2aWEgdmFyaWFibGU8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMTg0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiNmYmJmMjQiLz4KPHRleHQgeD0iNzU0IiB5PSIxOTciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiNmYmJmMjQiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIyMDgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiMwZjE3MmEiLz4KPHRleHQgeD0iMzIiIHk9IjIyNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+SUFNIGRhdGFiYXNlIGF1dGhlbnRpY2F0aW9uPC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMjIzIiB4Mj0iMzY4IiB5Mj0iMjIzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtbXlzcWwtZGVjbGFyYXRpb24tb24tc2NhbGV3YXkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iMzg0IiB5PSIyMjciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4OyBmb250LXNpemU6MTJweDtmaWxsOiNmMWY1ZjkiPk5vIGVxdWl2YWxlbnQ7IGNsaWVudHMgY2Fubm90IGNvbm5lY3Q8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMjE0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiNmODcxNzEiLz4KPHRleHQgeD0iNzU0IiB5PSIyMjciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiNmODcxNzEiPm9taXR0ZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIyMzgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiMxZTI5M2IiLz4KPHRleHQgeD0iMzIiIHk9IjI1NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+QmFja3VwIHJldGVudGlvbiBhbmQgd2luZG93PC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMjUzIiB4Mj0iMzY4IiB5Mj0iMjUzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtbXlzcWwtZGVjbGFyYXRpb24tb24tc2NhbGV3YXkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iMzg0IiB5PSIyNTciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4OyBmb250LXNpemU6MTJweDtmaWxsOiNmMWY1ZjkiPlNjYWxld2F5J3Mgb3duIGJhY2t1cCBzY2hlZHVsZTwvdGV4dD4KPHJlY3QgeD0iNzA0IiB5PSIyNDQiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTgiIHJ4PSI5IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6I2ZiYmYyNCIvPgo8dGV4dCB4PSI3NTQiIHk9IjI1NyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZpbGw6I2ZiYmYyNCI+Y2hhbmdlZDwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjI2OCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzMCIgc3R5bGU9ImZpbGw6IzBmMTcyYSIvPgo8dGV4dCB4PSIzMiIgeT0iMjg3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjEycHg7ZmlsbDojZjFmNWY5Ij5DdXN0b21lci1tYW5hZ2VkIEtNUyBrZXk8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIyODMiIHgyPSIzNjgiIHkyPSIyODMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLXJkcy1teXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8dGV4dCB4PSIzODQiIHk9IjI4NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+U2NhbGV3YXktbWFuYWdlZCBlbmNyeXB0aW9uIGF0IHJlc3Q8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMjc0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiNmYmJmMjQiLz4KPHRleHQgeD0iNzU0IiB5PSIyODciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiNmYmJmMjQiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIyOTgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiMxZTI5M2IiLz4KPHRleHQgeD0iMzIiIHk9IjMxNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+UGFyYW1ldGVyIGFuZCBvcHRpb24gZ3JvdXBzPC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMzEzIiB4Mj0iMzY4IiB5Mj0iMzEzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtbXlzcWwtZGVjbGFyYXRpb24tb24tc2NhbGV3YXkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iMzg0IiB5PSIzMTciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4OyBmb250LXNpemU6MTJweDtmaWxsOiNmMWY1ZjkiPlJlbW92ZWQ7IHNldCBlbmdpbmUgc2V0dGluZ3Mgb24gdGhlIGluc3RhbmNlPC90ZXh0Pgo8cmVjdCB4PSI3MDQiIHk9IjMwNCIgd2lkdGg9IjEwMCIgaGVpZ2h0PSIxOCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojZjg3MTcxIi8+Cjx0ZXh0IHg9Ijc1NCIgeT0iMzE3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiODsgZmlsbDojZjg3MTcxIj5vbWl0dGVkPC90ZXh0Pgo8L3N2Zz4=) Tensor9 applies this translation once, when the product is deployed. #### Limitations Where RDS MySQL and Scaleway differ * **MySQL versions other than 8 are not supported.** Scaleway offers only MySQL 8. A MySQL 5.7 origin is upgraded during deployment, and 5.7 to 8 is not transparent: default character sets and collations change, the default SQL mode is stricter, and new reserved words can break existing queries. Test the application on MySQL 8 before cutover. * **Instance sizes behave differently: they stop at 8 vCPU.** Instance classes map to Scaleway's general-purpose node types from 2 vCPU / 3 GB to 8 vCPU / 29 GB. A larger class maps to the largest of these, with less memory than the origin; size the workload before migrating. * **Availability SLAs behave differently: these node types have none.** Scaleway's SLA (99.95% for high availability, 99.5% standalone) covers only its POP2 node types, which this mapping does not select. * **High availability behaves differently: the standby shares a data center.** Scaleway replicates synchronously to a hot standby in a separate rack of the same data center. It protects against a node or rack failure, not the loss of a whole availability zone. * **Backups behave differently: they follow Scaleway's own schedule.** Backup retention and the preferred backup window are not preserved; set Scaleway's backup frequency and retention after deployment. * **Customer-managed KMS keys are not supported.** Encryption at rest is on, with Scaleway-managed keys. * **Parameter and option groups are not supported.** Engine settings are configured on the Scaleway instance itself; option groups have no equivalent. * **The runtime RDS API is not supported.** Snapshots, restores, failover, replicas, the Data API and event subscriptions are not available through RDS calls on this backend. #### Other considerations **Migration.** Moving the data is a one-time step: a logical dump and restore, or replication for a short cutover. Check IAM database authentication and the instance size first. **Operations.** The customer owns the database in their Scaleway project: maintenance windows, quotas and pricing are Scaleway's. Scaleway's availability SLA covers only its POP2 node types, so the general-purpose node types this mapping selects have no Scaleway availability commitment. **Features and capacity.** The comparison table on this page lists feature and high-availability differences. #### Example monthly charges This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include. **Native or deployment mapping.** 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. Cost estimates describe the selected service resources; operation coverage remains separate. ##### RDS MySQL · Primary allocated compute Feature: RDS MySQL. Estimated monthly service charges by Primary allocated compute. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: fr-par; currency: USD. ![RDS MySQL · Primary allocated compute: monthly service charges by Primary allocated compute. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/041245482db263ed46478c2418d207899d8ad2732faacbc78b286dd846f85508-light.svg) ![RDS MySQL · Primary allocated compute: monthly service charges by Primary allocated compute. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/62eb623e73e65d8c26748ac5bb832f2e3cfd2411b84d294d689827381e625840-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Primary allocated compute (vCPU-hours/month) | RDS MySQL | Target scenario | Scaleway Managed Database for MySQL | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | Scaleway Managed Database for MySQL (one copy) | 101.10 | 101.10 | | 0 | 0.00 | Scaleway Managed Database for MySQL (two copies) | 154.69 | 154.69 | | 1,460 | 124.83 | Scaleway Managed Database for MySQL (one copy) | 101.10 | -23.73 | | 1,460 | 124.83 | Scaleway Managed Database for MySQL (two copies) | 154.69 | 29.86 | | 2,920 | 249.66 | Scaleway Managed Database for MySQL (one copy) | 191.08 | -58.58 | | 2,920 | 249.66 | Scaleway Managed Database for MySQL (two copies) | 292.35 | 42.69 | | 5,840 | 499.32 | Scaleway Managed Database for MySQL (one copy) | 371.03 | -128.29 | | 5,840 | 499.32 | Scaleway Managed Database for MySQL (two copies) | 567.68 | 68.36 | | 11,680 | 998.64 | Scaleway Managed Database for MySQL (one copy) | 730.94 | -267.70 | | 11,680 | 998.64 | Scaleway Managed Database for MySQL (two copies) | 1,118.33 | 119.69 | | 23,360 | 1,997.28 | Scaleway Managed Database for MySQL (one copy) | 1,450.74 | -546.54 | | 23,360 | 1,997.28 | Scaleway Managed Database for MySQL (two copies) | 2,219.64 | 222.36 | | 46,720 | 3,994.56 | Scaleway Managed Database for MySQL (one copy) | Unpriced | Unavailable | | 46,720 | 3,994.56 | Scaleway Managed Database for MySQL (two copies) | Unpriced | Unavailable | Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 vCPU-hours/month to 32 vCPU, 128 GiB memory and 100 GiB SSD at 23,360 vCPU-hours/month. From 46,720 vCPU-hours/month the workload exceeds the planning range and the target is unpriced. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | Scaleway Managed Database for MySQL (one copy) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Scaleway Managed Database for MySQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Scaleway Managed Database for MySQL (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Scaleway Managed Database for MySQL (one copy) | Origin list price · Database reads | 0 | USD/operations | | Scaleway Managed Database for MySQL (one copy) | Origin list price · Database writes | 0 | USD/operations | | Scaleway Managed Database for MySQL (one copy) | Target CPU / source CPU | 1 | multiplier | | Scaleway Managed Database for MySQL (one copy) | Target RAM / source RAM | 1 | multiplier | | Scaleway Managed Database for MySQL (one copy) | Target disk / source disk | 1 | multiplier | | Scaleway Managed Database for MySQL (one copy) | Target price guess · read | 0 | USD/read | | Scaleway Managed Database for MySQL (one copy) | Target price guess · write | 0 | USD/write | | Scaleway Managed Database for MySQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | Scaleway Managed Database for MySQL (one copy) | Target list price · GiB-month | 0.111266 | USD/GiB-month | | Scaleway Managed Database for MySQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | Scaleway Managed Database for MySQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Scaleway Managed Database for MySQL (one copy) | Target price guess · network GiB | 0 | USD/network GiB | | Scaleway Managed Database for MySQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Scaleway Managed Database for MySQL (one copy) | Target list price · vCPU-hour | 0.0367275 | USD/vCPU-hour | | Scaleway Managed Database for MySQL (one copy) | Target list price · GiB-hour | 0.006225 | USD/GiB-hour | | Scaleway Managed Database for MySQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | Scaleway Managed Database for MySQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | Scaleway Managed Database for MySQL (one copy) | Target price guess · input token | 0 | USD/input token | | Scaleway Managed Database for MySQL (one copy) | Target price guess · output token | 0 | USD/output token | | Scaleway Managed Database for MySQL (one copy) | Target monthly base charge | 0 | USD/month | | Scaleway Managed Database for MySQL (one copy) | Target service minimum | 89.9762 | USD/month | | Scaleway Managed Database for MySQL (one copy) | Minimum primary CPU | 2 | vCPU | | Scaleway Managed Database for MySQL (one copy) | Minimum primary RAM | 8 | GiB | | Scaleway Managed Database for MySQL (one copy) | Minimum primary disk | 100 | GiB | | Scaleway Managed Database for MySQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | Scaleway Managed Database for MySQL (one copy) | Allocated share of provisioned cost | 1 | fraction | | Scaleway Managed Database for MySQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Scaleway Managed Database for MySQL (one copy) | Planning peak / mean work | 2 | multiplier | | Scaleway Managed Database for MySQL (one copy) | Planning primary CPU utilization | 0.7 | fraction | | Scaleway Managed Database for MySQL (one copy) | Resident state reserved in RAM | 0.1 | fraction | | Scaleway Managed Database for MySQL (one copy) | Planning disk utilization | 0.8 | fraction | | Scaleway Managed Database for MySQL (one copy) | Maintenance and log disk reserve | 20 | GiB | | Scaleway Managed Database for MySQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Scaleway Managed Database for MySQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Scaleway Managed Database for MySQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Scaleway Managed Database for MySQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Scaleway Managed Database for MySQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | Scaleway Managed Database for MySQL (two copies) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Scaleway Managed Database for MySQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Scaleway Managed Database for MySQL (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Scaleway Managed Database for MySQL (two copies) | Origin list price · Database reads | 0 | USD/operations | | Scaleway Managed Database for MySQL (two copies) | Origin list price · Database writes | 0 | USD/operations | | Scaleway Managed Database for MySQL (two copies) | Target CPU / source CPU | 1 | multiplier | | Scaleway Managed Database for MySQL (two copies) | Target RAM / source RAM | 1 | multiplier | | Scaleway Managed Database for MySQL (two copies) | Target disk / source disk | 1 | multiplier | | Scaleway Managed Database for MySQL (two copies) | Target price guess · read | 0 | USD/read | | Scaleway Managed Database for MySQL (two copies) | Target price guess · write | 0 | USD/write | | Scaleway Managed Database for MySQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | Scaleway Managed Database for MySQL (two copies) | Target list price · GiB-month | 0.111266 | USD/GiB-month | | Scaleway Managed Database for MySQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | Scaleway Managed Database for MySQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Scaleway Managed Database for MySQL (two copies) | Target price guess · network GiB | 0 | USD/network GiB | | Scaleway Managed Database for MySQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Scaleway Managed Database for MySQL (two copies) | Target list price · vCPU-hour | 0.0367275 | USD/vCPU-hour | | Scaleway Managed Database for MySQL (two copies) | Target list price · GiB-hour | 0.006225 | USD/GiB-hour | | Scaleway Managed Database for MySQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | Scaleway Managed Database for MySQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | Scaleway Managed Database for MySQL (two copies) | Target price guess · input token | 0 | USD/input token | | Scaleway Managed Database for MySQL (two copies) | Target price guess · output token | 0 | USD/output token | | Scaleway Managed Database for MySQL (two copies) | Target monthly base charge | 0 | USD/month | | Scaleway Managed Database for MySQL (two copies) | Target service minimum | 89.9762 | USD/month | | Scaleway Managed Database for MySQL (two copies) | Minimum primary CPU | 2 | vCPU | | Scaleway Managed Database for MySQL (two copies) | Minimum primary RAM | 8 | GiB | | Scaleway Managed Database for MySQL (two copies) | Minimum primary disk | 100 | GiB | | Scaleway Managed Database for MySQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | Scaleway Managed Database for MySQL (two copies) | Allocated share of provisioned cost | 1 | fraction | | Scaleway Managed Database for MySQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Scaleway Managed Database for MySQL (two copies) | Planning peak / mean work | 2 | multiplier | | Scaleway Managed Database for MySQL (two copies) | Planning primary CPU utilization | 0.7 | fraction | | Scaleway Managed Database for MySQL (two copies) | Resident state reserved in RAM | 0.1 | fraction | | Scaleway Managed Database for MySQL (two copies) | Planning disk utilization | 0.8 | fraction | | Scaleway Managed Database for MySQL (two copies) | Maintenance and log disk reserve | 20 | GiB | | Scaleway Managed Database for MySQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Scaleway Managed Database for MySQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Scaleway Managed Database for MySQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Scaleway Managed Database for MySQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Scaleway Managed Database for MySQL (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * CPU allocation does not imply an achieved transaction rate. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements. * Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → fr-par, USD/month. * Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded. * Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied. * Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Native/deployment comparison scope: 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. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Scaleway Managed Database for MySQL at Production Optimized (PRO2) prices in EUR converted at the ECB reference rate. A high-availability or replica node bills Scaleway's 'Additional nodes' price, EUR 0.0583 per hour for PRO2-XXS, 53% of the main node. Scaleway lists no egress charge for Managed Databases, so selected network is not charged. Cost Optimized ranges (DB-DEV-S from EUR 0.0156 per hour), Block Storage 15K and backups (EUR 0.03 per GB-month) are not selected. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: DB-PRO2-L has 32 vCPUs and 128 GB ([https://www.scaleway.com/en/pricing/managed-databases/](https://www.scaleway.com/en/pricing/managed-databases/)); a volume grows up to 15 TB ([https://www.scaleway.com/en/docs/managed-databases-for-postgresql-and-mysql/concepts/](https://www.scaleway.com/en/docs/managed-databases-for-postgresql-and-mysql/concepts/)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonRDS offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json) * Scaleway Managed Databases pricing: [https://www.scaleway.com/en/pricing/managed-databases/](https://www.scaleway.com/en/pricing/managed-databases/) Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. List prices read: 2026-10-22. Model: `plan-b25b6012b5ed1e8ec2e2a6387ae4012ad5692fbe` / `2026-10-22.planning.2`. Curve: `workload-1`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Scaleway Managed Databases pricing](https://www.scaleway.com/en/pricing/managed-databases/). ##### RDS MySQL · Stored data Feature: RDS MySQL. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: fr-par; currency: USD. ![RDS MySQL · Stored data: monthly service charges by Stored data. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/615711cc213812e7fab2abe552770e662878041955dd5c19205c711b2aab2ecc-light.svg) ![RDS MySQL · Stored data: monthly service charges by Stored data. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/800e5307d80e08cb063f03282b2e27ae0ce52eb4a52ed32b6c1df84e219aaaf0-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Stored data (GiB-month) | RDS MySQL | Target scenario | Scaleway Managed Database for MySQL | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | Scaleway Managed Database for MySQL (one copy) | 101.10 | 101.10 | | 0 | 0.00 | Scaleway Managed Database for MySQL (two copies) | 154.69 | 154.69 | | 10 | 1.15 | Scaleway Managed Database for MySQL (one copy) | 101.10 | 99.95 | | 10 | 1.15 | Scaleway Managed Database for MySQL (two copies) | 154.69 | 153.54 | | 100 | 11.50 | Scaleway Managed Database for MySQL (one copy) | 106.67 | 95.17 | | 100 | 11.50 | Scaleway Managed Database for MySQL (two copies) | 163.20 | 151.70 | | 1,000 | 115.00 | Scaleway Managed Database for MySQL (one copy) | 231.84 | 116.84 | | 1,000 | 115.00 | Scaleway Managed Database for MySQL (two copies) | 354.71 | 239.71 | | 10,000 | 1,150.00 | Scaleway Managed Database for MySQL (one copy) | 1,483.58 | 333.58 | | 10,000 | 1,150.00 | Scaleway Managed Database for MySQL (two copies) | 2,269.87 | 1,119.87 | | 100,000 | 11,500.00 | Scaleway Managed Database for MySQL (one copy) | Unpriced | Unavailable | | 100,000 | 11,500.00 | Scaleway Managed Database for MySQL (two copies) | Unpriced | Unavailable | Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 GiB-month to 2 vCPU, 8 GiB memory and 12,525 GiB SSD at 10,000 GiB-month. From 100,000 GiB-month the workload exceeds the planning range and the target is unpriced. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | Scaleway Managed Database for MySQL (one copy) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Scaleway Managed Database for MySQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Scaleway Managed Database for MySQL (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Scaleway Managed Database for MySQL (one copy) | Origin list price · Database reads | 0 | USD/operations | | Scaleway Managed Database for MySQL (one copy) | Origin list price · Database writes | 0 | USD/operations | | Scaleway Managed Database for MySQL (one copy) | Target CPU / source CPU | 1 | multiplier | | Scaleway Managed Database for MySQL (one copy) | Target RAM / source RAM | 1 | multiplier | | Scaleway Managed Database for MySQL (one copy) | Target disk / source disk | 1 | multiplier | | Scaleway Managed Database for MySQL (one copy) | Target price guess · read | 0 | USD/read | | Scaleway Managed Database for MySQL (one copy) | Target price guess · write | 0 | USD/write | | Scaleway Managed Database for MySQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | Scaleway Managed Database for MySQL (one copy) | Target list price · GiB-month | 0.111266 | USD/GiB-month | | Scaleway Managed Database for MySQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | Scaleway Managed Database for MySQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Scaleway Managed Database for MySQL (one copy) | Target price guess · network GiB | 0 | USD/network GiB | | Scaleway Managed Database for MySQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Scaleway Managed Database for MySQL (one copy) | Target list price · vCPU-hour | 0.0367275 | USD/vCPU-hour | | Scaleway Managed Database for MySQL (one copy) | Target list price · GiB-hour | 0.006225 | USD/GiB-hour | | Scaleway Managed Database for MySQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | Scaleway Managed Database for MySQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | Scaleway Managed Database for MySQL (one copy) | Target price guess · input token | 0 | USD/input token | | Scaleway Managed Database for MySQL (one copy) | Target price guess · output token | 0 | USD/output token | | Scaleway Managed Database for MySQL (one copy) | Target monthly base charge | 0 | USD/month | | Scaleway Managed Database for MySQL (one copy) | Target service minimum | 89.9762 | USD/month | | Scaleway Managed Database for MySQL (one copy) | Minimum primary CPU | 2 | vCPU | | Scaleway Managed Database for MySQL (one copy) | Minimum primary RAM | 8 | GiB | | Scaleway Managed Database for MySQL (one copy) | Minimum primary disk | 100 | GiB | | Scaleway Managed Database for MySQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | Scaleway Managed Database for MySQL (one copy) | Allocated share of provisioned cost | 1 | fraction | | Scaleway Managed Database for MySQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Scaleway Managed Database for MySQL (one copy) | Planning peak / mean work | 2 | multiplier | | Scaleway Managed Database for MySQL (one copy) | Planning primary CPU utilization | 0.7 | fraction | | Scaleway Managed Database for MySQL (one copy) | Resident state reserved in RAM | 0.1 | fraction | | Scaleway Managed Database for MySQL (one copy) | Planning disk utilization | 0.8 | fraction | | Scaleway Managed Database for MySQL (one copy) | Maintenance and log disk reserve | 20 | GiB | | Scaleway Managed Database for MySQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Scaleway Managed Database for MySQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Scaleway Managed Database for MySQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Scaleway Managed Database for MySQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Scaleway Managed Database for MySQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | Scaleway Managed Database for MySQL (two copies) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Scaleway Managed Database for MySQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Scaleway Managed Database for MySQL (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Scaleway Managed Database for MySQL (two copies) | Origin list price · Database reads | 0 | USD/operations | | Scaleway Managed Database for MySQL (two copies) | Origin list price · Database writes | 0 | USD/operations | | Scaleway Managed Database for MySQL (two copies) | Target CPU / source CPU | 1 | multiplier | | Scaleway Managed Database for MySQL (two copies) | Target RAM / source RAM | 1 | multiplier | | Scaleway Managed Database for MySQL (two copies) | Target disk / source disk | 1 | multiplier | | Scaleway Managed Database for MySQL (two copies) | Target price guess · read | 0 | USD/read | | Scaleway Managed Database for MySQL (two copies) | Target price guess · write | 0 | USD/write | | Scaleway Managed Database for MySQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | Scaleway Managed Database for MySQL (two copies) | Target list price · GiB-month | 0.111266 | USD/GiB-month | | Scaleway Managed Database for MySQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | Scaleway Managed Database for MySQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Scaleway Managed Database for MySQL (two copies) | Target price guess · network GiB | 0 | USD/network GiB | | Scaleway Managed Database for MySQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Scaleway Managed Database for MySQL (two copies) | Target list price · vCPU-hour | 0.0367275 | USD/vCPU-hour | | Scaleway Managed Database for MySQL (two copies) | Target list price · GiB-hour | 0.006225 | USD/GiB-hour | | Scaleway Managed Database for MySQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | Scaleway Managed Database for MySQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | Scaleway Managed Database for MySQL (two copies) | Target price guess · input token | 0 | USD/input token | | Scaleway Managed Database for MySQL (two copies) | Target price guess · output token | 0 | USD/output token | | Scaleway Managed Database for MySQL (two copies) | Target monthly base charge | 0 | USD/month | | Scaleway Managed Database for MySQL (two copies) | Target service minimum | 89.9762 | USD/month | | Scaleway Managed Database for MySQL (two copies) | Minimum primary CPU | 2 | vCPU | | Scaleway Managed Database for MySQL (two copies) | Minimum primary RAM | 8 | GiB | | Scaleway Managed Database for MySQL (two copies) | Minimum primary disk | 100 | GiB | | Scaleway Managed Database for MySQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | Scaleway Managed Database for MySQL (two copies) | Allocated share of provisioned cost | 1 | fraction | | Scaleway Managed Database for MySQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Scaleway Managed Database for MySQL (two copies) | Planning peak / mean work | 2 | multiplier | | Scaleway Managed Database for MySQL (two copies) | Planning primary CPU utilization | 0.7 | fraction | | Scaleway Managed Database for MySQL (two copies) | Resident state reserved in RAM | 0.1 | fraction | | Scaleway Managed Database for MySQL (two copies) | Planning disk utilization | 0.8 | fraction | | Scaleway Managed Database for MySQL (two copies) | Maintenance and log disk reserve | 20 | GiB | | Scaleway Managed Database for MySQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Scaleway Managed Database for MySQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Scaleway Managed Database for MySQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Scaleway Managed Database for MySQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Scaleway Managed Database for MySQL (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * Request meters remain at their independently authored defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements. * Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → fr-par, USD/month. * Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded. * Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied. * Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Native/deployment comparison scope: 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. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Scaleway Managed Database for MySQL at Production Optimized (PRO2) prices in EUR converted at the ECB reference rate. A high-availability or replica node bills Scaleway's 'Additional nodes' price, EUR 0.0583 per hour for PRO2-XXS, 53% of the main node. Scaleway lists no egress charge for Managed Databases, so selected network is not charged. Cost Optimized ranges (DB-DEV-S from EUR 0.0156 per hour), Block Storage 15K and backups (EUR 0.03 per GB-month) are not selected. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: DB-PRO2-L has 32 vCPUs and 128 GB ([https://www.scaleway.com/en/pricing/managed-databases/](https://www.scaleway.com/en/pricing/managed-databases/)); a volume grows up to 15 TB ([https://www.scaleway.com/en/docs/managed-databases-for-postgresql-and-mysql/concepts/](https://www.scaleway.com/en/docs/managed-databases-for-postgresql-and-mysql/concepts/)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonRDS offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json) * Scaleway Managed Databases pricing: [https://www.scaleway.com/en/pricing/managed-databases/](https://www.scaleway.com/en/pricing/managed-databases/) Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. List prices read: 2026-10-22. Model: `plan-b25b6012b5ed1e8ec2e2a6387ae4012ad5692fbe` / `2026-10-22.planning.2`. Curve: `workload-2`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Scaleway Managed Databases pricing](https://www.scaleway.com/en/pricing/managed-databases/). ##### RDS MySQL · Database writes Feature: RDS MySQL. Estimated monthly service charges by Database writes. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: fr-par; currency: USD. ![RDS MySQL · Database writes: monthly service charges by Database writes. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/8bc19332f57f4701943024548d5f271c0e1578c2e160713cd9ef6e38d3a84c08-light.svg) ![RDS MySQL · Database writes: monthly service charges by Database writes. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/7d67b359b90ef5abbb5dbe2c4a0489d482e1942aa07250ef287348e58ae5cce5-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Database writes (per second) | RDS MySQL | Target scenario | Scaleway Managed Database for MySQL | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | Scaleway Managed Database for MySQL (one copy) | 101.10 | 101.10 | | 0 | 0.00 | Scaleway Managed Database for MySQL (two copies) | 154.69 | 154.69 | | 1 | 0.00 | Scaleway Managed Database for MySQL (one copy) | 101.10 | 101.10 | | 1 | 0.00 | Scaleway Managed Database for MySQL (two copies) | 154.69 | 154.69 | | 10 | 0.00 | Scaleway Managed Database for MySQL (one copy) | 101.10 | 101.10 | | 10 | 0.00 | Scaleway Managed Database for MySQL (two copies) | 154.69 | 154.69 | | 100 | 0.00 | Scaleway Managed Database for MySQL (one copy) | 101.10 | 101.10 | | 100 | 0.00 | Scaleway Managed Database for MySQL (two copies) | 154.69 | 154.69 | | 1,000 | 0.00 | Scaleway Managed Database for MySQL (one copy) | 101.10 | 101.10 | | 1,000 | 0.00 | Scaleway Managed Database for MySQL (two copies) | 154.69 | 154.69 | | 10,000 | 0.00 | Scaleway Managed Database for MySQL (one copy) | 101.10 | 101.10 | | 10,000 | 0.00 | Scaleway Managed Database for MySQL (two copies) | 154.69 | 154.69 | Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample. **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | Scaleway Managed Database for MySQL (one copy) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Scaleway Managed Database for MySQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Scaleway Managed Database for MySQL (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Scaleway Managed Database for MySQL (one copy) | Origin list price · Database reads | 0 | USD/operations | | Scaleway Managed Database for MySQL (one copy) | Origin list price · Database writes | 0 | USD/operations | | Scaleway Managed Database for MySQL (one copy) | Target CPU / source CPU | 1 | multiplier | | Scaleway Managed Database for MySQL (one copy) | Target RAM / source RAM | 1 | multiplier | | Scaleway Managed Database for MySQL (one copy) | Target disk / source disk | 1 | multiplier | | Scaleway Managed Database for MySQL (one copy) | Target price guess · read | 0 | USD/read | | Scaleway Managed Database for MySQL (one copy) | Target price guess · write | 0 | USD/write | | Scaleway Managed Database for MySQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | Scaleway Managed Database for MySQL (one copy) | Target list price · GiB-month | 0.111266 | USD/GiB-month | | Scaleway Managed Database for MySQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | Scaleway Managed Database for MySQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Scaleway Managed Database for MySQL (one copy) | Target price guess · network GiB | 0 | USD/network GiB | | Scaleway Managed Database for MySQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Scaleway Managed Database for MySQL (one copy) | Target list price · vCPU-hour | 0.0367275 | USD/vCPU-hour | | Scaleway Managed Database for MySQL (one copy) | Target list price · GiB-hour | 0.006225 | USD/GiB-hour | | Scaleway Managed Database for MySQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | Scaleway Managed Database for MySQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | Scaleway Managed Database for MySQL (one copy) | Target price guess · input token | 0 | USD/input token | | Scaleway Managed Database for MySQL (one copy) | Target price guess · output token | 0 | USD/output token | | Scaleway Managed Database for MySQL (one copy) | Target monthly base charge | 0 | USD/month | | Scaleway Managed Database for MySQL (one copy) | Target service minimum | 89.9762 | USD/month | | Scaleway Managed Database for MySQL (one copy) | Minimum primary CPU | 2 | vCPU | | Scaleway Managed Database for MySQL (one copy) | Minimum primary RAM | 8 | GiB | | Scaleway Managed Database for MySQL (one copy) | Minimum primary disk | 100 | GiB | | Scaleway Managed Database for MySQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | Scaleway Managed Database for MySQL (one copy) | Allocated share of provisioned cost | 1 | fraction | | Scaleway Managed Database for MySQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Scaleway Managed Database for MySQL (one copy) | Planning peak / mean work | 2 | multiplier | | Scaleway Managed Database for MySQL (one copy) | Planning primary CPU utilization | 0.7 | fraction | | Scaleway Managed Database for MySQL (one copy) | Resident state reserved in RAM | 0.1 | fraction | | Scaleway Managed Database for MySQL (one copy) | Planning disk utilization | 0.8 | fraction | | Scaleway Managed Database for MySQL (one copy) | Maintenance and log disk reserve | 20 | GiB | | Scaleway Managed Database for MySQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Scaleway Managed Database for MySQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Scaleway Managed Database for MySQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Scaleway Managed Database for MySQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Scaleway Managed Database for MySQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | Scaleway Managed Database for MySQL (two copies) | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Scaleway Managed Database for MySQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Scaleway Managed Database for MySQL (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Scaleway Managed Database for MySQL (two copies) | Origin list price · Database reads | 0 | USD/operations | | Scaleway Managed Database for MySQL (two copies) | Origin list price · Database writes | 0 | USD/operations | | Scaleway Managed Database for MySQL (two copies) | Target CPU / source CPU | 1 | multiplier | | Scaleway Managed Database for MySQL (two copies) | Target RAM / source RAM | 1 | multiplier | | Scaleway Managed Database for MySQL (two copies) | Target disk / source disk | 1 | multiplier | | Scaleway Managed Database for MySQL (two copies) | Target price guess · read | 0 | USD/read | | Scaleway Managed Database for MySQL (two copies) | Target price guess · write | 0 | USD/write | | Scaleway Managed Database for MySQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | Scaleway Managed Database for MySQL (two copies) | Target list price · GiB-month | 0.111266 | USD/GiB-month | | Scaleway Managed Database for MySQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | Scaleway Managed Database for MySQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Scaleway Managed Database for MySQL (two copies) | Target price guess · network GiB | 0 | USD/network GiB | | Scaleway Managed Database for MySQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Scaleway Managed Database for MySQL (two copies) | Target list price · vCPU-hour | 0.0367275 | USD/vCPU-hour | | Scaleway Managed Database for MySQL (two copies) | Target list price · GiB-hour | 0.006225 | USD/GiB-hour | | Scaleway Managed Database for MySQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | Scaleway Managed Database for MySQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | Scaleway Managed Database for MySQL (two copies) | Target price guess · input token | 0 | USD/input token | | Scaleway Managed Database for MySQL (two copies) | Target price guess · output token | 0 | USD/output token | | Scaleway Managed Database for MySQL (two copies) | Target monthly base charge | 0 | USD/month | | Scaleway Managed Database for MySQL (two copies) | Target service minimum | 89.9762 | USD/month | | Scaleway Managed Database for MySQL (two copies) | Minimum primary CPU | 2 | vCPU | | Scaleway Managed Database for MySQL (two copies) | Minimum primary RAM | 8 | GiB | | Scaleway Managed Database for MySQL (two copies) | Minimum primary disk | 100 | GiB | | Scaleway Managed Database for MySQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | Scaleway Managed Database for MySQL (two copies) | Allocated share of provisioned cost | 1 | fraction | | Scaleway Managed Database for MySQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Scaleway Managed Database for MySQL (two copies) | Planning peak / mean work | 2 | multiplier | | Scaleway Managed Database for MySQL (two copies) | Planning primary CPU utilization | 0.7 | fraction | | Scaleway Managed Database for MySQL (two copies) | Resident state reserved in RAM | 0.1 | fraction | | Scaleway Managed Database for MySQL (two copies) | Planning disk utilization | 0.8 | fraction | | Scaleway Managed Database for MySQL (two copies) | Maintenance and log disk reserve | 20 | GiB | | Scaleway Managed Database for MySQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Scaleway Managed Database for MySQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Scaleway Managed Database for MySQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Scaleway Managed Database for MySQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Scaleway Managed Database for MySQL (two copies) | Dependent object sink write price guess | 0.000005 | USD/write | * Source compute and stored data remain independent; a throughput view needs explicit workload inputs. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements. * Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → fr-par, USD/month. * Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded. * Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied. * Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve's workload note. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Native/deployment comparison scope: 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. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Scaleway Managed Database for MySQL at Production Optimized (PRO2) prices in EUR converted at the ECB reference rate. A high-availability or replica node bills Scaleway's 'Additional nodes' price, EUR 0.0583 per hour for PRO2-XXS, 53% of the main node. Scaleway lists no egress charge for Managed Databases, so selected network is not charged. Cost Optimized ranges (DB-DEV-S from EUR 0.0156 per hour), Block Storage 15K and backups (EUR 0.03 per GB-month) are not selected. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: DB-PRO2-L has 32 vCPUs and 128 GB ([https://www.scaleway.com/en/pricing/managed-databases/](https://www.scaleway.com/en/pricing/managed-databases/)); a volume grows up to 15 TB ([https://www.scaleway.com/en/docs/managed-databases-for-postgresql-and-mysql/concepts/](https://www.scaleway.com/en/docs/managed-databases-for-postgresql-and-mysql/concepts/)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. * AWS Price List API, AmazonRDS offer: [https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json) * Scaleway Managed Databases pricing: [https://www.scaleway.com/en/pricing/managed-databases/](https://www.scaleway.com/en/pricing/managed-databases/) Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. List prices read: 2026-10-22. Model: `plan-b25b6012b5ed1e8ec2e2a6387ae4012ad5692fbe` / `2026-10-22.planning.2`. Curve: `workload-3`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Scaleway Managed Databases pricing](https://www.scaleway.com/en/pricing/managed-databases/). **RDS MySQL → Scaleway Managed Database for MySQL: Authored native-usage planning example.** Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: fr-par. Currency: USD. | Monthly component | USD | | - | -: | | Origin: Primary compute | 0.00 | | Origin: Primary memory | 0.00 | | Origin: Primary provisioned storage | 0.00 | | Origin: Database reads | 0.00 | | Origin: Database writes | 0.00 | | Target: Provisioned primary CPU | 53.62 | | Target: Provisioned primary RAM | 36.35 | | Target: Provisioned primary disk | 11.13 | | Target: Selected billable network | 0.00 | | Target: Independent provisioned resources | 0.00 | | Target: Independent managed resources | 0.00 | | **Origin service subtotal** | **0.00** | | **Target service subtotal** | **101.10** | Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features: * Additional network transfer, backups, KMS, one-time migration and operational labor unless an explicit meter includes them. * Destination application execution and separately billed downstream services; supply those allocations separately. * Aurora per-IO, serverless-capacity, backup and proxy charges; reserved/committed-use purchase options. * Taxes, discounts, credits and free-tier allowances not explicitly listed by this model. * Unmodeled dependent services, task execution and operations outside the selected workload family. **Scenario assumptions** | Input | Value | Unit | | - | -: | - | | Origin list price · Primary compute | 0.0855 | USD/vCPU-hours | | Origin list price · Primary memory | 0 | USD/GiB-hours | | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Origin list price · Database reads | 0 | USD/operations | | Origin list price · Database writes | 0 | USD/operations | | Target CPU / source CPU | 1 | multiplier | | Target RAM / source RAM | 1 | multiplier | | Target disk / source disk | 1 | multiplier | | Target price guess · read | 0 | USD/read | | Target price guess · write | 0 | USD/write | | Target price guess · provider operation | 0 | USD/provider operation | | Target list price · GiB-month | 0.111266 | USD/GiB-month | | Target price guess · published GiB | 0 | USD/published GiB | | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Target price guess · network GiB | 0 | USD/network GiB | | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Target list price · vCPU-hour | 0.0367275 | USD/vCPU-hour | | Target list price · GiB-hour | 0.006225 | USD/GiB-hour | | Target price guess · resource-hour | 0 | USD/resource-hour | | Target price guess · resource-month | 0 | USD/resource-month | | Target price guess · input token | 0 | USD/input token | | Target price guess · output token | 0 | USD/output token | | Target monthly base charge | 0 | USD/month | | Target service minimum | 89.9762 | USD/month | | Minimum primary CPU | 2 | vCPU | | Minimum primary RAM | 8 | GiB | | Minimum primary disk | 100 | GiB | | Additional full-price standby copy | 0 | 0 or 1 | | Allocated share of provisioned cost | 1 | fraction | | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Planning peak / mean work | 2 | multiplier | | Planning primary CPU utilization | 0.7 | fraction | | Resident state reserved in RAM | 0.1 | fraction | | Planning disk utilization | 0.8 | fraction | | Maintenance and log disk reserve | 20 | GiB | | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Dependent object sink write price guess | 0.000005 | USD/write | | Primary compute | 0 | vCPU-hours | | Primary memory | 0 | GiB-hours | | Primary provisioned storage | 0 | GiB-month | | Database reads | 0 | operations | | Database writes | 0 | operations | * Translated reads: 0 operations. * Translated writes: 0 operations. * Translated resident physical data: 0 GiB-month. * Native provider operations: 0 operations. * Published payload: 0 GiB. * Delivered payload: 0 GiB. * Allocated execution CPU: 0 vCPU-hour. * Allocated execution RAM: 0 GiB-hour. * Independent resource allocation: 0 resource-hour. * Independent inventory: 0 resource-month. * Input tokens: 0 tokens. * Output tokens: 0 tokens. * Billable network: 0 GiB. * Dependent object sink retained data: 0 GiB-month. * Dependent object sink writes: 0 writes. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Native/deployment comparison scope: 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. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Scaleway Managed Database for MySQL at Production Optimized (PRO2) prices in EUR converted at the ECB reference rate. A high-availability or replica node bills Scaleway's 'Additional nodes' price, EUR 0.0583 per hour for PRO2-XXS, 53% of the main node. Scaleway lists no egress charge for Managed Databases, so selected network is not charged. Cost Optimized ranges (DB-DEV-S from EUR 0.0156 per hour), Block Storage 15K and backups (EUR 0.03 per GB-month) are not selected. * Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1\_0\_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A. * Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing ([https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size](https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size)): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled. * Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full ([https://docs.cloud.google.com/sql/docs/postgres/instance-settings](https://docs.cloud.google.com/sql/docs/postgres/instance-settings)). The 20 GiB reserve exceeds PostgreSQL's 1 GB default max\_wal\_size; the remainder of that reserve is unmeasured. * CPU tiers double from 2 vCPUs to the target's largest node at 4 GiB per vCPU; each target's documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead. * No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load. * Node bounds: DB-PRO2-L has 32 vCPUs and 128 GB ([https://www.scaleway.com/en/pricing/managed-databases/](https://www.scaleway.com/en/pricing/managed-databases/)); a volume grows up to 15 TB ([https://www.scaleway.com/en/docs/managed-databases-for-postgresql-and-mysql/concepts/](https://www.scaleway.com/en/docs/managed-databases-for-postgresql-and-mysql/concepts/)). * Stored GiB already includes the origin family's physical footprint assumptions; no second storage amplification is applied. * The workload family already selected resource-hours; the throughput coefficient is not applied again. * Copies and allocation fractions change cost only; they do not increase modeled primary capacity. List prices read: 2026-10-22. Model: `plan-b25b6012b5ed1e8ec2e2a6387ae4012ad5692fbe` / `2026-10-22.planning.2`. Scenario: `planning-example`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Scaleway Managed Databases pricing](https://www.scaleway.com/en/pricing/managed-databases/). ## Costs Estimated monthly service charges for each backend with a published cost model, at one sampled workload from that model's cost curve. Adapter hosting and Tensor9 fees are excluded. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method, what the estimates include and how to read their qualifications. | Backend | Sampled workload | Price basis | Origin USD/month | Backend USD/month | Difference | Mapping | | - | - | - | -: | -: | -: | - | | Cloud SQL for MySQL | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 499.32 | 421.71 | -77.61 | Service adapter | | DigitalOcean Managed MySQL | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 499.32 | 531.50 | +32.18 | Service adapter | | MySQL Flexible Server | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 499.32 | 510.82 | +11.50 | Service adapter | | OCI MySQL Database (HeatWave) | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 499.32 | 217.74 | -281.58 | Service adapter | | Percona XtraDB Cluster (MySQL) | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 499.32 | 293.58 | -205.74 | Service adapter | | Scaleway Managed Database for MySQL | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 499.32 | 371.03 | -128.29 | Native or deployment | Difference means backend minus origin; a positive difference means the backend costs more. Workloads and target configurations differ by model, so compare each row's difference at its stated workload rather than charges across rows. Cost curves across workload sizes, with every assumption and exclusion: [Amazon RDS costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/rds.md). ## Service level agreements > [!WARNING] > > These tables show Tensor9's standard service levels and adapters whose standard terms are still being defined. Your signed agreement determines the SLAs, covered adapters and operations, limits, remedies and support terms that apply to your deployment. 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](https://docs.tensor9.com/cloud-adapter-early-access/support/service-adapter-slas.md), [measurement rules](https://docs.tensor9.com/cloud-adapter-early-access/support/service-levels.md), and [scaling conditions](https://docs.tensor9.com/cloud-adapter-early-access/support/scaling-and-limits.md). ### RDS MySQL to MySQL Flexible Server | SLA | Service level | What is covered | Conditions | | - | - | - | - | | Bounded database status responses adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `DescribeDBInstances`, `DescribeDBSnapshots` | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | | Database lifecycle request acceptance adapter-added latency | +30 ms monthly p99 | `aws::1.0.0::rds`: `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DescribeDBClusters`, `DescribeDBInstances`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance` | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | | Bounded database parameter requests adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | | Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::rds`: `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `DescribeDBInstances`, `DescribeDBSnapshots`, `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance`, `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | 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. | | Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. | | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | **Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. **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 (adapter-added).** `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 (adapter-added).** `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 (adapter-added).** `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. #### Endpoint reachability and request failures The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results. #### 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 | SLA | Service level | What is covered | Conditions | | - | - | - | - | | Bounded database status responses adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBInstances` | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | | Database lifecycle request acceptance adapter-added latency | +30 ms monthly p99 | `aws::1.0.0::rds`: `CreateDBInstance`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DeleteDBInstance`, `DescribeDBInstances`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime` | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | | Bounded database parameter requests adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | | Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::rds`: `DescribeDBInstances`, `CreateDBInstance`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DeleteDBInstance`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | 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. | | Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. | | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | **Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. **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 (adapter-added).** `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 (adapter-added).** `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 (adapter-added).** `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. #### Endpoint reachability and request failures The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results. #### 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 | SLA | Service level | What is covered | Conditions | | - | - | - | - | | Bounded database status responses adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `DescribeDBInstances`, `DescribeDBSnapshots` | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | | Database lifecycle request acceptance adapter-added latency | +30 ms monthly p99 | `aws::1.0.0::rds`: `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DescribeDBClusters`, `DescribeDBInstances`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance` | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | | Bounded database parameter requests adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | | Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::rds`: `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `DescribeDBInstances`, `DescribeDBSnapshots`, `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance`, `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | 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. | | Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. | | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | **Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. **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 (adapter-added).** `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 (adapter-added).** `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 (adapter-added).** `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. #### Endpoint reachability and request failures The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results. #### 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) | SLA | Service level | What is covered | Conditions | | - | - | - | - | | Bounded database status responses adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `DescribeDBInstances`, `DescribeDBSnapshots` | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | | Database lifecycle request acceptance adapter-added latency | +30 ms monthly p99 | `aws::1.0.0::rds`: `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DescribeDBClusters`, `DescribeDBInstances`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance` | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | | Bounded database parameter requests adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | | Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::rds`: `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `DescribeDBInstances`, `DescribeDBSnapshots`, `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance`, `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | 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. | | Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. | | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | **Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. **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 (adapter-added).** `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 (adapter-added).** `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 (adapter-added).** `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. #### Endpoint reachability and request failures The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results. #### 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) | SLA | Service level | What is covered | Conditions | | - | - | - | - | | Bounded database status responses adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `DescribeDBInstances`, `DescribeDBSnapshots` | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | | Database lifecycle request acceptance adapter-added latency | +30 ms monthly p99 | `aws::1.0.0::rds`: `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DescribeDBClusters`, `DescribeDBInstances`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance` | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | | Bounded database parameter requests adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | | Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::rds`: `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `DescribeDBInstances`, `DescribeDBSnapshots`, `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance`, `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | 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. | | Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. | | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | **Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. **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 (adapter-added).** `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 (adapter-added).** `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 (adapter-added).** `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. #### Endpoint reachability and request failures The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results. #### 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. ## Install and run The documentation and SLAs are public. Downloading and running the Cloud Adapter binary requires an entitled customer account. Set `T9_API_KEY` as described in [Install and Authenticate](https://docs.tensor9.com/cloud-adapter-early-access/getting-started/install-and-authenticate.md), then list the adapters your account may use with this origin: ```sh theme={null} tensor9 adapt svc list \ -origin aws::1.0.0::rds::mysql ``` The result is limited to directed mappings for this origin that your account is entitled to use. Use a returned backend identifier when configuring the adapter or investigating a request. Request binary access from [hello@tensor9.com](mailto:hello@tensor9.com) if your account does not yet include this direction. ## Existing data and credentials Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application's endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target. ## Configure, tune and debug Start with [setup](https://docs.tensor9.com/cloud-adapter-early-access/getting-started/overview.md) and [configuration](https://docs.tensor9.com/cloud-adapter-early-access/configuration/overview.md). Use [tuning](https://docs.tensor9.com/cloud-adapter-early-access/tuning/overview.md) to understand supported request tags, [debugging](https://docs.tensor9.com/cloud-adapter-early-access/debugging/overview.md) to investigate a request, and [High Fidelity Cloud Emulators](https://docs.tensor9.com/cloud-adapter-early-access/local-testing/overview.md) to validate a bounded reproduction. For requests that go through an entitled service adapter, use [tensor9 explain](https://docs.tensor9.com/cloud-adapter-early-access/debugging/explain.md) and [x-t9-explain](https://docs.tensor9.com/cloud-adapter-early-access/debugging/response-headers.md) to inspect the selected mapping. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.