> ## 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.

# Aurora PostgreSQL

> Aurora PostgreSQL APIs with Cloud Adapter.

This page describes how Aurora PostgreSQL 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 Aurora PostgreSQL with its adaptation on each backend.
A dash means this profile does not state the capability for that backend.

### Cloud Adapter

#### Runtime surface

| Capability | Aurora PostgreSQL | Azure | DigitalOcean | Google Cloud · Cloud SQL for PostgreSQL | Google Cloud · AlloyDB for PostgreSQL | Google Cloud · AlloyDB for PostgreSQL (RDS proxy) | OCI | Private Kubernetes and Scaleway · PostgreSQL (CloudNativePG) | Scaleway · Scaleway Managed Database for PostgreSQL |
| - | - | - | - | - | - | - | - | - | - |
| API coverage | full | high | high | high | high | high | high | high | partial |

#### Management surface

| Capability | Aurora PostgreSQL | Azure | DigitalOcean | Google Cloud · Cloud SQL for PostgreSQL | Google Cloud · AlloyDB for PostgreSQL | Google Cloud · AlloyDB for PostgreSQL (RDS proxy) | OCI | Private Kubernetes and Scaleway · PostgreSQL (CloudNativePG) | Scaleway · Scaleway Managed Database for PostgreSQL |
| - | - | - | - | - | - | - | - | - | - |
| Snapshot / restore + PITR | Yes | Yes | Partial - seven-day provider backup timeline; restore creates a new cluster | Yes | Partial - AlloyDB runs automated and continuous backups with native point-in-time recovery; the adapter does not translate RDS snapshot or restore requests | Partial - AlloyDB runs automated and continuous backups with native point-in-time recovery; the adapter does not translate RDS snapshot or restore requests | Partial - OCI supports point-in-time recovery with a configured policy, retained WAL and periodic backups, creating a new database system within the active recovery window; the documented adapter mapping does not promise AWS point-in-time restore translation | 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 | Partial - replicates to BigQuery (Datastream); Redshift itself is not served | 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 - each reader becomes an AlloyDB read pool instance | Yes - each reader becomes an AlloyDB read pool, and the proxy's reader endpoint spreads sessions across them | Yes | Yes | Partial - Scaleway offers asynchronous read replicas; Aurora readers are not translated into them, and reader traffic goes to the instance endpoint |
| Read replicas · cross-region | Yes | Yes | Partial - read-only node in another region; promotion ends replication from the original | Yes | Partial - AlloyDB offers cross-region secondary clusters natively; the adapter does not map Aurora cross-region readers or global databases onto them | Partial - AlloyDB offers cross-region secondary clusters natively; the adapter does not map Aurora cross-region readers or global databases onto them | No - OCI supports readable warm standby systems in up to three disaster recovery regions, using asynchronous replication; the documented adapter mapping does not promise AWS cross-region replica or Aurora global-cluster semantics | No | No - Scaleway read replicas stay within one region |
| Managed connection pooling · RDS Proxy | Yes | Yes | Partial - PgBouncer pools connections; AWS Proxy-specific authentication and routing are not equivalent | Yes | Partial - AlloyDB offers managed connection pooling natively; the adapter neither configures it nor serves the RDS Proxy APIs | Partial - the Tensor9 proxy adds IAM login and endpoint routing but keeps one AlloyDB connection per client session and serves no RDS Proxy APIs | Yes | Yes | No |
| Trusted Language Extensions · pg\_tle | Yes | No | - | No | No | No | No | Yes | No |
| Data API (HTTP SQL) · rds-data | Yes | Yes | - | Yes | No | No | Yes | Yes | No |
| Query performance insights · Performance Insights | Yes | Partial - the vendor can't access the Cloud Adapter deployment's cloud console | Partial - backend monitoring differs; customer controls access | Partial - the vendor can't access the Cloud Adapter deployment's cloud console | Partial - the vendor can't access the Cloud Adapter deployment's cloud console | Partial - the vendor can't access the Cloud Adapter deployment's cloud console | Partial - the vendor can't access the Cloud Adapter deployment's cloud console | Partial - the vendor can't access the Cloud Adapter deployment's cloud console | Partial - metrics and logs in Scaleway Cockpit; the vendor can't access the Cloud Adapter deployment's console |

#### Limits

| Capability | Aurora PostgreSQL | Azure | DigitalOcean | Google Cloud · Cloud SQL for PostgreSQL | Google Cloud · AlloyDB for PostgreSQL | Google Cloud · AlloyDB for PostgreSQL (RDS proxy) | OCI | Private Kubernetes and Scaleway · PostgreSQL (CloudNativePG) | Scaleway · Scaleway Managed Database for PostgreSQL |
| - | - | - | - | - | - | - | - | - | - |
| Maximum storage | 256 TiB | 64 TiB | - | 64 TiB | 128 TiB | 128 TiB | 32 TiB | limited by persistent volume capacity | 10,000 GB |
| vCPU range · smallest to largest instance | 2-192 | 1-192 | - | 1-128 | 2-96 | 2-96 | 2-128 (64 OCPU) | limited by Kubernetes node resources | 2-8 |
| Memory range · smallest to largest instance | 4-1,536 GiB | 2-1,832 GiB | - | 0.6-864 GiB | 16-768 GiB | 16-768 GiB | 16-1,024 GiB | limited by Kubernetes node resources | 3-29 GB |
| Storage autoscaling | Yes | Yes | - | 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

### PostgreSQL Flexible Server

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| AWS/Aurora-proprietary SQL: aws\_s3.*, aws\_lambda.invoke, Aurora ML (aws\_sagemaker / aws\_comprehend), aurora\_* / apg\_plan\_mgmt | SQL functions | Out of scope | Full surface | AWS and Aurora extension functions with no counterpart on vanilla PostgreSQL; a query calling them fails |
| pgwire protocol (application SQL) | Wire protocol | Supported | Common | wire-compatible PostgreSQL; application SQL is unchanged |

#### How it works

Your application's PostgreSQL driver connects directly to Azure Database for PostgreSQL Flexible Server. These database requests are the **data plane**. The driver and the PostgreSQL wire protocol stay the same, and Tensor9 adds no proxy, translation or latency to your queries.

Management requests, such as snapshots, restores, replicas, failover and configuration changes, are the **control plane**. Tensor9 runs the RDS API in the customer's Cloud Adapter deployment and translates each of these requests to the backend's management API. The sections below list which operations work and which return an error.

![Database requests (SQL over pgwire) connect directly to PostgreSQL Flexible Server. The Tensor9 service adapter translates RDS API management calls to Azure management API.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgcGd3aXJlKSBjb25uZWN0IGRpcmVjdGx5IHRvIFBvc3RncmVTUUwgRmxleGlibGUgU2VydmVyLiBUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgdHJhbnNsYXRlcyBSRFMgQVBJIG1hbmFnZW1lbnQgY2FsbHMgdG8gQXp1cmUgbWFuYWdlbWVudCBBUEkuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojMzM0MTU1fTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImFoZC1wb3N0Z3Jlc3FsLWZsZXhpYmxlLXNlcnZlciIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNyIgbWFya2VySGVpZ2h0PSI3IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+PHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBzdHlsZT0iZmlsbDojOTRhM2I4Ii8+PC9tYXJrZXI+PC9kZWZzPgo8cmVjdCB4PSI4IiB5PSIzNCIgd2lkdGg9IjgyMCIgaGVpZ2h0PSIyMDYiIHJ4PSIxNiIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0cm9rZS1kYXNoYXJyYXk9IjUgNSIgc3R5bGU9ImZpbGw6I2Y4ZmFmYztzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSIyNiIgeT0iNTQiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4OyBmaWxsOiMwNDc4NTciPk9OIEFaVVJFPC90ZXh0PjxzdmcgeD0iNzkyIiB5PSIzNiIgd2lkdGg9IjE2IiBoZWlnaHQ9IjE2IiB2aWV3Qm94PSIwIDAgMTYgMTYiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiIGZpbGw9Im5vbmUiPjxnIGZpbGw9IiMwMDg5RDYiPiA8cGF0aCBkPSJNNy40NyAxMi40MTJsMy4zNDgtLjU5Mi4wMzEtLjAwNy0xLjcyMi0yLjA0OWEyOTEuNDc0IDI5MS40NzQgMCAwMS0xLjcyMy0yLjA1OGMwLS4wMSAxLjc3OS00LjkwOSAxLjc4OS00LjkyNmE3ODguOTUgNzg4Ljk1IDAgMDEyLjkzNCA1LjA2NmwyLjk1IDUuMTE1LjAyMy4wMzktMTAuOTQ4LS4wMDEgMy4zMTctLjU4N3pNLjkgMTEuNzg4YzAtLjAwMy44MTEtMS40MTIgMS44MDMtMy4xMzFMNC41MDcgNS41M2wyLjEwMi0xLjc2NEM3Ljc2NSAyLjc5NyA4LjcxNCAyIDguNzE3IDJhLjM3LjM3IDAgMDEtLjAzMy4wODVMNi40IDYuOTgxIDQuMTYgMTEuNzg5bC0xLjYzLjAwMmMtLjg5Ny4wMDEtMS42MyAwLTEuNjMtLjAwM3oiLz4gPC9nPjwvc3ZnPgo8cmVjdCB4PSIyNiIgeT0iODgiIHdpZHRoPSIxMjgiIGhlaWdodD0iMTEyIiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjkwIiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTNweCI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIxNDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5Qb3N0Z3JlU1FMIGRyaXZlcjwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjE2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij51bmNoYW5nZWQ8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iODIiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4OyBmaWxsOiMwNDc4NTciPkRBVEFCQVNFIFJFUVVFU1RTIMK3IERJUkVDVCBDT05ORUNUSU9OPC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTA4IiB4Mj0iNjEwIiB5Mj0iMTA4IiBzdHJva2Utd2lkdGg9IjIuMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtcG9zdGdyZXNxbC1mbGV4aWJsZS1zZXJ2ZXIpIiBzdHlsZT0ic3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iMzgyIiB5PSIxMDAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiMwNDc4NTciPlNRTCBvdmVyIHBnd2lyZTwvdGV4dD4KPHJlY3QgeD0iNjE0IiB5PSI3NiIgd2lkdGg9IjE5NiIgaGVpZ2h0PSI2NCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPjxzdmcgeD0iNzg2IiB5PSI1NiIgd2lkdGg9IjIwIiBoZWlnaHQ9IjIwIiB2aWV3Qm94PSIwIDAgNDMyLjA3MSA0NDUuMzgzIiBwcmVzZXJ2ZUFzcGVjdFJhdGlvPSJ4TWlkWU1pZCBtZWV0Ij48ZyBzdHlsZT0iZmlsbC1ydWxlOm5vbnplcm87Y2xpcC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLW1pdGVybGltaXQ6NCI+IDwvZz4gPGcgc3R5bGU9ImZpbGwtcnVsZTpub256ZXJvO2NsaXAtcnVsZTpub256ZXJvO2ZpbGw6bm9uZTtzdHJva2U6I0ZGRkZGRjtzdHJva2Utd2lkdGg6MTIuNDY1MTtzdHJva2UtbGluZWNhcDpyb3VuZDtzdHJva2UtbGluZWpvaW46cm91bmQ7c3Ryb2tlLW1pdGVybGltaXQ6NCI+IDxwYXRoIGQ9Ik0zMjMuMjA1LDMyNC4yMjdjMi44MzMtMjMuNjAxLDEuOTg0LTI3LjA2MiwxOS41NjMtMjMuMjM5bDQuNDYzLDAuMzkyYzEzLjUxNywwLjYxNSwzMS4xOTktMi4xNzQsNDEuNTg3LTdjMjIuMzYyLTEwLjM3NiwzNS42MjItMjcuNywxMy41NzItMjMuMTQ4Yy01MC4yOTcsMTAuMzc2LTUzLjc1NS02LjY1NS01My43NTUtNi42NTVjNTMuMTExLTc4LjgwMyw3NS4zMTMtMTc4LjgzNiw1Ni4xNDktMjAzLjMyMiBDMzUyLjUxNC01LjUzNCwyNjIuMDM2LDI2LjA0OSwyNjAuNTIyLDI2Ljg2OWwtMC40ODIsMC4wODljLTkuOTM4LTIuMDYyLTIxLjA2LTMuMjk0LTMzLjU1NC0zLjQ5NmMtMjIuNzYxLTAuMzc0LTQwLjAzMiw1Ljk2Ny01My4xMzMsMTUuOTA0YzAsMC0xNjEuNDA4LTY2LjQ5OC0xNTMuODk5LDgzLjYyOGMxLjU5NywzMS45MzYsNDUuNzc3LDI0MS42NTUsOTguNDcsMTc4LjMxIGMxOS4yNTktMjMuMTYzLDM3Ljg3MS00Mi43NDgsMzcuODcxLTQyLjc0OGM5LjI0Miw2LjE0LDIwLjMwNyw5LjI3MiwzMS45MTIsOC4xNDdsMC44OTctMC43NjVjLTAuMjgxLDIuODc2LTAuMTU3LDUuNjg5LDAuMzU5LDkuMDE5Yy0xMy41NzIsMTUuMTY3LTkuNTg0LDE3LjgzLTM2LjcyMywyMy40MTZjLTI3LjQ1Nyw1LjY1OS0xMS4zMjYsMTUuNzM0LTAuNzk3LDE4LjM2N2MxMi43NjgsMy4xOTMsNDIuMzA1LDcuNzE2LDYyLjI2OC0yMC4yMjQgbC0wLjc5NSwzLjE4OGM1LjMyNSw0LjI2LDQuOTY1LDMwLjYxOSw1LjcyLDQ5LjQ1MmMwLjc1NiwxOC44MzQsMi4wMTcsMzYuNDA5LDUuODU2LDQ2Ljc3MWMzLjgzOSwxMC4zNiw4LjM2OSwzNy4wNSw0NC4wMzYsMjkuNDA2YzI5LjgwOS02LjM4OCw1Mi42LTE1LjU4Miw1NC42NzctMTAxLjEwNyIgc3R5bGU9ImZpbGw6IzAwMDAwMDtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MzcuMzk1MztzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNNDAyLjM5NSwyNzEuMjNjLTUwLjMwMiwxMC4zNzYtNTMuNzYtNi42NTUtNTMuNzYtNi42NTVjNTMuMTExLTc4LjgwOCw3NS4zMTMtMTc4Ljg0Myw1Ni4xNTMtMjAzLjMyNmMtNTIuMjctNjYuNzg1LTE0Mi43NTItMzUuMi0xNDQuMjYyLTM0LjM4bC0wLjQ4NiwwLjA4N2MtOS45MzgtMi4wNjMtMjEuMDYtMy4yOTItMzMuNTYtMy40OTZjLTIyLjc2MS0wLjM3My00MC4wMjYsNS45NjctNTMuMTI3LDE1LjkwMiBjMCwwLTE2MS40MTEtNjYuNDk1LTE1My45MDQsODMuNjNjMS41OTcsMzEuOTM4LDQ1Ljc3NiwyNDEuNjU3LDk4LjQ3MSwxNzguMzEyYzE5LjI2LTIzLjE2MywzNy44NjktNDIuNzQ4LDM3Ljg2OS00Mi43NDhjOS4yNDMsNi4xNCwyMC4zMDgsOS4yNzIsMzEuOTA4LDguMTQ3bDAuOTAxLTAuNzY1Yy0wLjI4LDIuODc2LTAuMTUyLDUuNjg5LDAuMzYxLDkuMDE5Yy0xMy41NzUsMTUuMTY3LTkuNTg2LDE3LjgzLTM2LjcyMywyMy40MTYgYy0yNy40NTksNS42NTktMTEuMzI4LDE1LjczNC0wLjc5NiwxOC4zNjdjMTIuNzY4LDMuMTkzLDQyLjMwNyw3LjcxNiw2Mi4yNjYtMjAuMjI0bC0wLjc5NiwzLjE4OGM1LjMxOSw0LjI2LDkuMDU0LDI3LjcxMSw4LjQyOCw0OC45NjljLTAuNjI2LDIxLjI1OS0xLjA0NCwzNS44NTQsMy4xNDcsNDcuMjU0YzQuMTkxLDExLjQsOC4zNjgsMzcuMDUsNDQuMDQyLDI5LjQwNmMyOS44MDktNi4zODgsNDUuMjU2LTIyLjk0Miw0Ny40MDUtNTAuNTU1IGMxLjUyNS0xOS42MzEsNC45NzYtMTYuNzI5LDUuMTk0LTM0LjI4bDIuNzY4LTguMzA5YzMuMTkyLTI2LjYxMSwwLjUwNy0zNS4xOTYsMTguODcyLTMxLjIwM2w0LjQ2MywwLjM5MmMxMy41MTcsMC42MTUsMzEuMjA4LTIuMTc0LDQxLjU5MS03YzIyLjM1OC0xMC4zNzYsMzUuNjE4LTI3LjcsMTMuNTczLTIzLjE0OHoiIHN0eWxlPSJmaWxsOiMzMzY3OTE7c3Ryb2tlOm5vbmUiLz4gPHBhdGggZD0iTTIxNS44NjYsMjg2LjQ4NGMtMS4zODUsNDkuNTE2LDAuMzQ4LDk5LjM3Nyw1LjE5MywxMTEuNDk1YzQuODQ4LDEyLjExOCwxNS4yMjMsMzUuNjg4LDUwLjksMjguMDQ1YzI5LjgwNi02LjM5LDQwLjY1MS0xOC43NTYsNDUuMzU3LTQ2LjA1MWMzLjQ2Ni0yMC4wODIsMTAuMTQ4LTc1Ljg1NCwxMS4wMDUtODcuMjgxIi8+IDxwYXRoIGQ9Ik0xNzMuMTA0LDM4LjI1NmMwLDAtMTYxLjUyMS02Ni4wMTYtMTU0LjAxMiw4NC4xMDljMS41OTcsMzEuOTM4LDQ1Ljc3OSwyNDEuNjY0LDk4LjQ3MywxNzguMzE2YzE5LjI1Ni0yMy4xNjYsMzYuNjcxLTQxLjMzNSwzNi42NzEtNDEuMzM1Ii8+IDxwYXRoIGQ9Ik0yNjAuMzQ5LDI2LjIwN2MtNS41OTEsMS43NTMsODkuODQ4LTM0Ljg4OSwxNDQuMDg3LDM0LjQxN2MxOS4xNTksMjQuNDg0LTMuMDQzLDEyNC41MTktNTYuMTUzLDIwMy4zMjkiLz4gPHBhdGggZD0iTTM0OC4yODIsMjYzLjk1M2MwLDAsMy40NjEsMTcuMDM2LDUzLjc2NCw2LjY1M2MyMi4wNC00LjU1Miw4Ljc3NiwxMi43NzQtMTMuNTc3LDIzLjE1NWMtMTguMzQ1LDguNTE0LTU5LjQ3NCwxMC42OTYtNjAuMTQ2LTEuMDY5Yy0xLjcyOS0zMC4zNTUsMjEuNjQ3LTIxLjEzMywxOS45Ni0yOC43MzljLTEuNTI1LTYuODUtMTEuOTc5LTEzLjU3My0xOC44OTQtMzAuMzM4IGMtNi4wMzctMTQuNjMzLTgyLjc5Ni0xMjYuODQ5LDIxLjI4Ny0xMTAuMTgzYzMuODEzLTAuNzg5LTI3LjE0Ni05OS4wMDItMTI0LjU1My0xMDAuNTk5Yy05Ny4zODUtMS41OTctOTQuMTksMTE5Ljc2Mi05NC4xOSwxMTkuNzYyIiBzdHlsZT0ic3Ryb2tlLWxpbmVqb2luOmJldmVsIi8+IDxwYXRoIGQ9Ik0xODguNjA0LDI3NC4zMzRjLTEzLjU3NywxNS4xNjYtOS41ODQsMTcuODI5LTM2LjcyMywyMy40MTdjLTI3LjQ1OSw1LjY2LTExLjMyNiwxNS43MzMtMC43OTcsMTguMzY1YzEyLjc2OCwzLjE5NSw0Mi4zMDcsNy43MTgsNjIuMjY2LTIwLjIyOWM2LjA3OC04LjUwOS0wLjAzNi0yMi4wODYtOC4zODUtMjUuNTQ3Yy00LjAzNC0xLjY3MS05LjQyOC0zLjc2NS0xNi4zNjEsMy45OTR6Ii8+IDxwYXRoIGQ9Ik0xODcuNzE1LDI3NC4wNjljLTEuMzY4LTguOTE3LDIuOTMtMTkuNTI4LDcuNTM2LTMxLjk0MmM2LjkyMi0xOC42MjYsMjIuODkzLTM3LjI1NSwxMC4xMTctOTYuMzM5Yy05LjUyMy00NC4wMjktNzMuMzk2LTkuMTYzLTczLjQzNi0zLjE5M2MtMC4wMzksNS45NjgsMi44ODksMzAuMjYtMS4wNjcsNTguNTQ4Yy01LjE2MiwzNi45MTMsMjMuNDg4LDY4LjEzMiw1Ni40NzksNjQuOTM4Ii8+IDxwYXRoIGQ9Ik0xNzIuNTE3LDE0MS43Yy0wLjI4OCwyLjAzOSwzLjczMyw3LjQ4LDguOTc2LDguMjA3YzUuMjM0LDAuNzMsOS43MTQtMy41MjIsOS45OTgtNS41NTljMC4yODQtMi4wMzktMy43MzItNC4yODUtOC45NzctNS4wMTVjLTUuMjM3LTAuNzMxLTkuNzE5LDAuMzMzLTkuOTk2LDIuMzY3eiIgc3R5bGU9ImZpbGw6I0ZGRkZGRjtzdHJva2Utd2lkdGg6NC4xNTU7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTMzMS45NDEsMTM3LjU0M2MwLjI4NCwyLjAzOS0zLjczMiw3LjQ4LTguOTc2LDguMjA3Yy01LjIzOCwwLjczLTkuNzE4LTMuNTIyLTEwLjAwNS01LjU1OWMtMC4yNzctMi4wMzksMy43NC00LjI4NSw4Ljk3OS01LjAxNWM1LjIzOS0wLjczLDkuNzE4LDAuMzMzLDEwLjAwMiwyLjM2OHoiIHN0eWxlPSJmaWxsOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjIuMDc3NTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNMzUwLjY3NiwxMjMuNDMyYzAuODYzLDE1Ljk5NC0zLjQ0NSwyNi44ODgtMy45ODgsNDMuOTE0Yy0wLjgwNCwyNC43NDgsMTEuNzk5LDUzLjA3NC03LjE5MSw4MS40MzUiLz4gPHBhdGggZD0iTTAsNjAuMjMyIiBzdHlsZT0ic3Ryb2tlLXdpZHRoOjMiLz4gPC9nPjwvc3ZnPgo8dGV4dCB4PSI3MTIiIHk9IjEwMyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMnB4Ij5Qb3N0Z3JlU1FMIEZsZXhpYmxlIFNlcnZlcjwvdGV4dD4KPHRleHQgeD0iNzEyIiB5PSIxMjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5Qb3N0Z3JlU1FMIGVuZ2luZTwvdGV4dD4KPHRleHQgeD0iMjAwIiB5PSIxNTgiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4Ij5NQU5BR0VNRU5UIFJFUVVFU1RTIMK3IFZJQSBURU5TT1I5PC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTk2IiB4Mj0iMzAwIiB5Mj0iMTk2IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLXBvc3RncmVzcWwtZmxleGlibGUtc2VydmVyKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjIyNyIgeT0iMTg4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YiI+UkRTIEFQSTwvdGV4dD4KPHJlY3QgeD0iMzA0IiB5PSIxNjQiIHdpZHRoPSIxODAiIGhlaWdodD0iNjYiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iMzk0IiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSIzOTQiIHk9IjIwOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+c2VydmljZSBhZGFwdGVyPC90ZXh0Pgo8bGluZSB4MT0iNDg0IiB5MT0iMTk2IiB4Mj0iNjEwIiB5Mj0iMTk2IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLXBvc3RncmVzcWwtZmxleGlibGUtc2VydmVyKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxyZWN0IHg9IjYxNCIgeT0iMTY0IiB3aWR0aD0iMTk2IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjcxMiIgeT0iMTkxIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjExLjVweCI+QXp1cmUgbWFuYWdlbWVudCBBUEk8L3RleHQ+Cjx0ZXh0IHg9IjcxMiIgeT0iMjEwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+dGhlIGJhY2tlbmQncyBtYW5hZ2VtZW50IEFQSTwvdGV4dD4KPC9zdmc+)

![Database requests (SQL over pgwire) connect directly to PostgreSQL Flexible Server. The Tensor9 service adapter translates RDS API management calls to Azure management API.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgcGd3aXJlKSBjb25uZWN0IGRpcmVjdGx5IHRvIFBvc3RncmVTUUwgRmxleGlibGUgU2VydmVyLiBUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgdHJhbnNsYXRlcyBSRFMgQVBJIG1hbmFnZW1lbnQgY2FsbHMgdG8gQXp1cmUgbWFuYWdlbWVudCBBUEkuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojY2JkNWUxfTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImFoZC1wb3N0Z3Jlc3FsLWZsZXhpYmxlLXNlcnZlciIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNyIgbWFya2VySGVpZ2h0PSI3IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+PHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBzdHlsZT0iZmlsbDojNjQ3NDhiIi8+PC9tYXJrZXI+PC9kZWZzPgo8cmVjdCB4PSI4IiB5PSIzNCIgd2lkdGg9IjgyMCIgaGVpZ2h0PSIyMDYiIHJ4PSIxNiIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0cm9rZS1kYXNoYXJyYXk9IjUgNSIgc3R5bGU9ImZpbGw6IzBmMTcyYTtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSIyNiIgeT0iNTQiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiM2ZWU3YjciPk9OIEFaVVJFPC90ZXh0PjxzdmcgeD0iNzkyIiB5PSIzNiIgd2lkdGg9IjE2IiBoZWlnaHQ9IjE2IiB2aWV3Qm94PSIwIDAgMTYgMTYiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiIGZpbGw9Im5vbmUiPjxnIGZpbGw9IiMwMDg5RDYiPiA8cGF0aCBkPSJNNy40NyAxMi40MTJsMy4zNDgtLjU5Mi4wMzEtLjAwNy0xLjcyMi0yLjA0OWEyOTEuNDc0IDI5MS40NzQgMCAwMS0xLjcyMy0yLjA1OGMwLS4wMSAxLjc3OS00LjkwOSAxLjc4OS00LjkyNmE3ODguOTUgNzg4Ljk1IDAgMDEyLjkzNCA1LjA2NmwyLjk1IDUuMTE1LjAyMy4wMzktMTAuOTQ4LS4wMDEgMy4zMTctLjU4N3pNLjkgMTEuNzg4YzAtLjAwMy44MTEtMS40MTIgMS44MDMtMy4xMzFMNC41MDcgNS41M2wyLjEwMi0xLjc2NEM3Ljc2NSAyLjc5NyA4LjcxNCAyIDguNzE3IDJhLjM3LjM3IDAgMDEtLjAzMy4wODVMNi40IDYuOTgxIDQuMTYgMTEuNzg5bC0xLjYzLjAwMmMtLjg5Ny4wMDEtMS42MyAwLTEuNjMtLjAwM3oiLz4gPC9nPjwvc3ZnPgo8cmVjdCB4PSIyNiIgeT0iODgiIHdpZHRoPSIxMjgiIGhlaWdodD0iMTEyIiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjkwIiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTNweCI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIxNDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5Qb3N0Z3JlU1FMIGRyaXZlcjwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjE2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij51bmNoYW5nZWQ8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iODIiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiM2ZWU3YjciPkRBVEFCQVNFIFJFUVVFU1RTIMK3IERJUkVDVCBDT05ORUNUSU9OPC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTA4IiB4Mj0iNjEwIiB5Mj0iMTA4IiBzdHJva2Utd2lkdGg9IjIuMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtcG9zdGdyZXNxbC1mbGV4aWJsZS1zZXJ2ZXIpIiBzdHlsZT0ic3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iMzgyIiB5PSIxMDAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiM2ZWU3YjciPlNRTCBvdmVyIHBnd2lyZTwvdGV4dD4KPHJlY3QgeD0iNjE0IiB5PSI3NiIgd2lkdGg9IjE5NiIgaGVpZ2h0PSI2NCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPjxzdmcgeD0iNzg2IiB5PSI1NiIgd2lkdGg9IjIwIiBoZWlnaHQ9IjIwIiB2aWV3Qm94PSIwIDAgNDMyLjA3MSA0NDUuMzgzIiBwcmVzZXJ2ZUFzcGVjdFJhdGlvPSJ4TWlkWU1pZCBtZWV0Ij48ZyBzdHlsZT0iZmlsbC1ydWxlOm5vbnplcm87Y2xpcC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLW1pdGVybGltaXQ6NCI+IDwvZz4gPGcgc3R5bGU9ImZpbGwtcnVsZTpub256ZXJvO2NsaXAtcnVsZTpub256ZXJvO2ZpbGw6bm9uZTtzdHJva2U6I0ZGRkZGRjtzdHJva2Utd2lkdGg6MTIuNDY1MTtzdHJva2UtbGluZWNhcDpyb3VuZDtzdHJva2UtbGluZWpvaW46cm91bmQ7c3Ryb2tlLW1pdGVybGltaXQ6NCI+IDxwYXRoIGQ9Ik0zMjMuMjA1LDMyNC4yMjdjMi44MzMtMjMuNjAxLDEuOTg0LTI3LjA2MiwxOS41NjMtMjMuMjM5bDQuNDYzLDAuMzkyYzEzLjUxNywwLjYxNSwzMS4xOTktMi4xNzQsNDEuNTg3LTdjMjIuMzYyLTEwLjM3NiwzNS42MjItMjcuNywxMy41NzItMjMuMTQ4Yy01MC4yOTcsMTAuMzc2LTUzLjc1NS02LjY1NS01My43NTUtNi42NTVjNTMuMTExLTc4LjgwMyw3NS4zMTMtMTc4LjgzNiw1Ni4xNDktMjAzLjMyMiBDMzUyLjUxNC01LjUzNCwyNjIuMDM2LDI2LjA0OSwyNjAuNTIyLDI2Ljg2OWwtMC40ODIsMC4wODljLTkuOTM4LTIuMDYyLTIxLjA2LTMuMjk0LTMzLjU1NC0zLjQ5NmMtMjIuNzYxLTAuMzc0LTQwLjAzMiw1Ljk2Ny01My4xMzMsMTUuOTA0YzAsMC0xNjEuNDA4LTY2LjQ5OC0xNTMuODk5LDgzLjYyOGMxLjU5NywzMS45MzYsNDUuNzc3LDI0MS42NTUsOTguNDcsMTc4LjMxIGMxOS4yNTktMjMuMTYzLDM3Ljg3MS00Mi43NDgsMzcuODcxLTQyLjc0OGM5LjI0Miw2LjE0LDIwLjMwNyw5LjI3MiwzMS45MTIsOC4xNDdsMC44OTctMC43NjVjLTAuMjgxLDIuODc2LTAuMTU3LDUuNjg5LDAuMzU5LDkuMDE5Yy0xMy41NzIsMTUuMTY3LTkuNTg0LDE3LjgzLTM2LjcyMywyMy40MTZjLTI3LjQ1Nyw1LjY1OS0xMS4zMjYsMTUuNzM0LTAuNzk3LDE4LjM2N2MxMi43NjgsMy4xOTMsNDIuMzA1LDcuNzE2LDYyLjI2OC0yMC4yMjQgbC0wLjc5NSwzLjE4OGM1LjMyNSw0LjI2LDQuOTY1LDMwLjYxOSw1LjcyLDQ5LjQ1MmMwLjc1NiwxOC44MzQsMi4wMTcsMzYuNDA5LDUuODU2LDQ2Ljc3MWMzLjgzOSwxMC4zNiw4LjM2OSwzNy4wNSw0NC4wMzYsMjkuNDA2YzI5LjgwOS02LjM4OCw1Mi42LTE1LjU4Miw1NC42NzctMTAxLjEwNyIgc3R5bGU9ImZpbGw6IzAwMDAwMDtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MzcuMzk1MztzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNNDAyLjM5NSwyNzEuMjNjLTUwLjMwMiwxMC4zNzYtNTMuNzYtNi42NTUtNTMuNzYtNi42NTVjNTMuMTExLTc4LjgwOCw3NS4zMTMtMTc4Ljg0Myw1Ni4xNTMtMjAzLjMyNmMtNTIuMjctNjYuNzg1LTE0Mi43NTItMzUuMi0xNDQuMjYyLTM0LjM4bC0wLjQ4NiwwLjA4N2MtOS45MzgtMi4wNjMtMjEuMDYtMy4yOTItMzMuNTYtMy40OTZjLTIyLjc2MS0wLjM3My00MC4wMjYsNS45NjctNTMuMTI3LDE1LjkwMiBjMCwwLTE2MS40MTEtNjYuNDk1LTE1My45MDQsODMuNjNjMS41OTcsMzEuOTM4LDQ1Ljc3NiwyNDEuNjU3LDk4LjQ3MSwxNzguMzEyYzE5LjI2LTIzLjE2MywzNy44NjktNDIuNzQ4LDM3Ljg2OS00Mi43NDhjOS4yNDMsNi4xNCwyMC4zMDgsOS4yNzIsMzEuOTA4LDguMTQ3bDAuOTAxLTAuNzY1Yy0wLjI4LDIuODc2LTAuMTUyLDUuNjg5LDAuMzYxLDkuMDE5Yy0xMy41NzUsMTUuMTY3LTkuNTg2LDE3LjgzLTM2LjcyMywyMy40MTYgYy0yNy40NTksNS42NTktMTEuMzI4LDE1LjczNC0wLjc5NiwxOC4zNjdjMTIuNzY4LDMuMTkzLDQyLjMwNyw3LjcxNiw2Mi4yNjYtMjAuMjI0bC0wLjc5NiwzLjE4OGM1LjMxOSw0LjI2LDkuMDU0LDI3LjcxMSw4LjQyOCw0OC45NjljLTAuNjI2LDIxLjI1OS0xLjA0NCwzNS44NTQsMy4xNDcsNDcuMjU0YzQuMTkxLDExLjQsOC4zNjgsMzcuMDUsNDQuMDQyLDI5LjQwNmMyOS44MDktNi4zODgsNDUuMjU2LTIyLjk0Miw0Ny40MDUtNTAuNTU1IGMxLjUyNS0xOS42MzEsNC45NzYtMTYuNzI5LDUuMTk0LTM0LjI4bDIuNzY4LTguMzA5YzMuMTkyLTI2LjYxMSwwLjUwNy0zNS4xOTYsMTguODcyLTMxLjIwM2w0LjQ2MywwLjM5MmMxMy41MTcsMC42MTUsMzEuMjA4LTIuMTc0LDQxLjU5MS03YzIyLjM1OC0xMC4zNzYsMzUuNjE4LTI3LjcsMTMuNTczLTIzLjE0OHoiIHN0eWxlPSJmaWxsOiMzMzY3OTE7c3Ryb2tlOm5vbmUiLz4gPHBhdGggZD0iTTIxNS44NjYsMjg2LjQ4NGMtMS4zODUsNDkuNTE2LDAuMzQ4LDk5LjM3Nyw1LjE5MywxMTEuNDk1YzQuODQ4LDEyLjExOCwxNS4yMjMsMzUuNjg4LDUwLjksMjguMDQ1YzI5LjgwNi02LjM5LDQwLjY1MS0xOC43NTYsNDUuMzU3LTQ2LjA1MWMzLjQ2Ni0yMC4wODIsMTAuMTQ4LTc1Ljg1NCwxMS4wMDUtODcuMjgxIi8+IDxwYXRoIGQ9Ik0xNzMuMTA0LDM4LjI1NmMwLDAtMTYxLjUyMS02Ni4wMTYtMTU0LjAxMiw4NC4xMDljMS41OTcsMzEuOTM4LDQ1Ljc3OSwyNDEuNjY0LDk4LjQ3MywxNzguMzE2YzE5LjI1Ni0yMy4xNjYsMzYuNjcxLTQxLjMzNSwzNi42NzEtNDEuMzM1Ii8+IDxwYXRoIGQ9Ik0yNjAuMzQ5LDI2LjIwN2MtNS41OTEsMS43NTMsODkuODQ4LTM0Ljg4OSwxNDQuMDg3LDM0LjQxN2MxOS4xNTksMjQuNDg0LTMuMDQzLDEyNC41MTktNTYuMTUzLDIwMy4zMjkiLz4gPHBhdGggZD0iTTM0OC4yODIsMjYzLjk1M2MwLDAsMy40NjEsMTcuMDM2LDUzLjc2NCw2LjY1M2MyMi4wNC00LjU1Miw4Ljc3NiwxMi43NzQtMTMuNTc3LDIzLjE1NWMtMTguMzQ1LDguNTE0LTU5LjQ3NCwxMC42OTYtNjAuMTQ2LTEuMDY5Yy0xLjcyOS0zMC4zNTUsMjEuNjQ3LTIxLjEzMywxOS45Ni0yOC43MzljLTEuNTI1LTYuODUtMTEuOTc5LTEzLjU3My0xOC44OTQtMzAuMzM4IGMtNi4wMzctMTQuNjMzLTgyLjc5Ni0xMjYuODQ5LDIxLjI4Ny0xMTAuMTgzYzMuODEzLTAuNzg5LTI3LjE0Ni05OS4wMDItMTI0LjU1My0xMDAuNTk5Yy05Ny4zODUtMS41OTctOTQuMTksMTE5Ljc2Mi05NC4xOSwxMTkuNzYyIiBzdHlsZT0ic3Ryb2tlLWxpbmVqb2luOmJldmVsIi8+IDxwYXRoIGQ9Ik0xODguNjA0LDI3NC4zMzRjLTEzLjU3NywxNS4xNjYtOS41ODQsMTcuODI5LTM2LjcyMywyMy40MTdjLTI3LjQ1OSw1LjY2LTExLjMyNiwxNS43MzMtMC43OTcsMTguMzY1YzEyLjc2OCwzLjE5NSw0Mi4zMDcsNy43MTgsNjIuMjY2LTIwLjIyOWM2LjA3OC04LjUwOS0wLjAzNi0yMi4wODYtOC4zODUtMjUuNTQ3Yy00LjAzNC0xLjY3MS05LjQyOC0zLjc2NS0xNi4zNjEsMy45OTR6Ii8+IDxwYXRoIGQ9Ik0xODcuNzE1LDI3NC4wNjljLTEuMzY4LTguOTE3LDIuOTMtMTkuNTI4LDcuNTM2LTMxLjk0MmM2LjkyMi0xOC42MjYsMjIuODkzLTM3LjI1NSwxMC4xMTctOTYuMzM5Yy05LjUyMy00NC4wMjktNzMuMzk2LTkuMTYzLTczLjQzNi0zLjE5M2MtMC4wMzksNS45NjgsMi44ODksMzAuMjYtMS4wNjcsNTguNTQ4Yy01LjE2MiwzNi45MTMsMjMuNDg4LDY4LjEzMiw1Ni40NzksNjQuOTM4Ii8+IDxwYXRoIGQ9Ik0xNzIuNTE3LDE0MS43Yy0wLjI4OCwyLjAzOSwzLjczMyw3LjQ4LDguOTc2LDguMjA3YzUuMjM0LDAuNzMsOS43MTQtMy41MjIsOS45OTgtNS41NTljMC4yODQtMi4wMzktMy43MzItNC4yODUtOC45NzctNS4wMTVjLTUuMjM3LTAuNzMxLTkuNzE5LDAuMzMzLTkuOTk2LDIuMzY3eiIgc3R5bGU9ImZpbGw6I0ZGRkZGRjtzdHJva2Utd2lkdGg6NC4xNTU7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTMzMS45NDEsMTM3LjU0M2MwLjI4NCwyLjAzOS0zLjczMiw3LjQ4LTguOTc2LDguMjA3Yy01LjIzOCwwLjczLTkuNzE4LTMuNTIyLTEwLjAwNS01LjU1OWMtMC4yNzctMi4wMzksMy43NC00LjI4NSw4Ljk3OS01LjAxNWM1LjIzOS0wLjczLDkuNzE4LDAuMzMzLDEwLjAwMiwyLjM2OHoiIHN0eWxlPSJmaWxsOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjIuMDc3NTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNMzUwLjY3NiwxMjMuNDMyYzAuODYzLDE1Ljk5NC0zLjQ0NSwyNi44ODgtMy45ODgsNDMuOTE0Yy0wLjgwNCwyNC43NDgsMTEuNzk5LDUzLjA3NC03LjE5MSw4MS40MzUiLz4gPHBhdGggZD0iTTAsNjAuMjMyIiBzdHlsZT0ic3Ryb2tlLXdpZHRoOjMiLz4gPC9nPjwvc3ZnPgo8dGV4dCB4PSI3MTIiIHk9IjEwMyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMnB4Ij5Qb3N0Z3JlU1FMIEZsZXhpYmxlIFNlcnZlcjwvdGV4dD4KPHRleHQgeD0iNzEyIiB5PSIxMjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5Qb3N0Z3JlU1FMIGVuZ2luZTwvdGV4dD4KPHRleHQgeD0iMjAwIiB5PSIxNTgiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiIj5NQU5BR0VNRU5UIFJFUVVFU1RTIMK3IFZJQSBURU5TT1I5PC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTk2IiB4Mj0iMzAwIiB5Mj0iMTk2IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLXBvc3RncmVzcWwtZmxleGlibGUtc2VydmVyKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjIyNyIgeT0iMTg4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiOCI+UkRTIEFQSTwvdGV4dD4KPHJlY3QgeD0iMzA0IiB5PSIxNjQiIHdpZHRoPSIxODAiIGhlaWdodD0iNjYiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iMzk0IiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSIzOTQiIHk9IjIwOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+c2VydmljZSBhZGFwdGVyPC90ZXh0Pgo8bGluZSB4MT0iNDg0IiB5MT0iMTk2IiB4Mj0iNjEwIiB5Mj0iMTk2IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLXBvc3RncmVzcWwtZmxleGlibGUtc2VydmVyKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxyZWN0IHg9IjYxNCIgeT0iMTY0IiB3aWR0aD0iMTk2IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjcxMiIgeT0iMTkxIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjExLjVweCI+QXp1cmUgbWFuYWdlbWVudCBBUEk8L3RleHQ+Cjx0ZXh0IHg9IjcxMiIgeT0iMjEwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+dGhlIGJhY2tlbmQncyBtYW5hZ2VtZW50IEFQSTwvdGV4dD4KPC9zdmc+)

Queries reach the database directly; only the management calls are translated.

#### Database connections

Aurora stores data in an AWS-specific storage layer, but your application reaches it over the standard PostgreSQL wire protocol, which Azure Database for PostgreSQL Flexible Server also supports. Your SQL, drivers, object-relational mappers (ORMs), prepared statements, data types and transaction behavior stay the same; only the storage underneath changes.

AWS and Aurora add SQL functions for moving data through S3, invoking Lambda and machine learning. These functions do not exist on the backend, so a query that calls them returns an error.

#### Database management

At runtime your application and tools keep making the same RDS calls: describe the cluster, take a snapshot, restore to a point in time, add a reader, trigger a failover, stop and start, change the instance class or a parameter. For each supported operation, the adapter accepts the RDS request, returns the RDS response format, and performs the operation on the Flexible Server: on-demand backups and restores, point-in-time restore, read replicas, manual failover, stop / start, and compute, storage and server-parameter updates.

The adapter also runs the Aurora Data API (SQL over HTTPS, transactions included), executing each statement over a native connection to the backend database. The adapter also handles Aurora's global database. The Flexible Server has no global-cluster object, so Tensor9 keeps the global cluster itself and maps its members and role changes onto cross-region read replicas. The backend's managed replica promotion operation handles planned switchover and unplanned failover.

With Max, your tools call `CreateDBCluster` and `CreateDBInstance` through the RDS adapter to create a logical Aurora cluster and its members on Azure PostgreSQL Flexible Server. Tensor9 keeps a durable record of the logical cluster and its members and reconciles the Azure resources with it: it records each accepted request, then creates or removes the Azure resources in the background. `DescribeDBClusters` and `DescribeDBInstances` report status and endpoints. `DeleteDBInstance` removes members; `DeleteDBCluster` removes the cluster once its members are gone. Your application's SQL connection still goes directly to the database. With the Infrastructure-only option, Tensor9 compiles the declared cluster into Azure PostgreSQL Flexible Server resources, which you manage with Microsoft's own tools; runtime RDS API calls require Max.

![The Tensor9 service adapter handles RDS management requests using Azure management API and returns RDS responses.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTk2IiB2aWV3Qm94PSIwIDAgODM2IDE5NiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgaGFuZGxlcyBSRFMgbWFuYWdlbWVudCByZXF1ZXN0cyB1c2luZyBBenVyZSBtYW5hZ2VtZW50IEFQSSBhbmQgcmV0dXJucyBSRFMgcmVzcG9uc2VzLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaGMtcmRzLWF6dXJlLW1hbmFnZW1lbnQtYXBpIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM5NGEzYjgiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjE2IiB5PSIzNCIgd2lkdGg9IjIzNiIgaGVpZ2h0PSIxMjgiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iMTM0IiB5PSI2MCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMi41cHgiPlJEUyBtYW5hZ2VtZW50IGNhbGw8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iODIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5zbmFwc2hvdCDCtyBwb2ludC1pbi10aW1lIHJlc3RvcmU8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iOTkiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5yZWFkZXIgwrcgZmFpbG92ZXIgwrcgZ2xvYmFsIGRhdGFiYXNlPC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9IjExNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPkRhdGEgQVBJIMK3IHBhcmFtZXRlcnM8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iMTQyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YiI+c2FtZSByZXF1ZXN0IC8gcmVzcG9uc2Ugc2hhcGVzPC90ZXh0Pgo8bGluZSB4MT0iMjUyIiB5MT0iNzQiIHgyPSIzMTQiIHkyPSI3NCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtYXp1cmUtbWFuYWdlbWVudC1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPGxpbmUgeDE9IjMxOCIgeTE9IjEyOCIgeDI9IjI1NiIgeTI9IjEyOCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtYXp1cmUtbWFuYWdlbWVudC1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHJlY3QgeD0iMzE4IiB5PSI1NCIgd2lkdGg9IjIwNCIgaGVpZ2h0PSI4OCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI0MjAiIHk9Ijk0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC1zaXplOjEycHgiPlRlbnNvcjk8L3RleHQ+CiAgPHRleHQgeD0iNDIwIiB5PSIxMTIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPnNlcnZpY2UgYWRhcHRlcjwvdGV4dD4KPGxpbmUgeDE9IjUyMiIgeTE9Ijc0IiB4Mj0iNTg0IiB5Mj0iNzQiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWF6dXJlLW1hbmFnZW1lbnQtYXBpKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxsaW5lIHgxPSI1ODgiIHkxPSIxMjgiIHgyPSI1MjYiIHkyPSIxMjgiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWF6dXJlLW1hbmFnZW1lbnQtYXBpKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxyZWN0IHg9IjU4OCIgeT0iMzQiIHdpZHRoPSIyMzIiIGhlaWdodD0iMTI4IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjcwNCIgeT0iNjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTJweCI+QXp1cmUgbWFuYWdlbWVudCBBUEk8L3RleHQ+Cjx0ZXh0IHg9IjcwNCIgeT0iOTQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5iYWNrdXBzIMK3IHJlc3RvcmVzIMK3IHJlcGxpY2FzPC90ZXh0Pgo8dGV4dCB4PSI3MDQiIHk9IjExMSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPmZhaWxvdmVyIMK3IHVwZGF0ZXMgwrcgcGFyYW1ldGVyczwvdGV4dD4KPC9zdmc+)

![The Tensor9 service adapter handles RDS management requests using Azure management API and returns RDS responses.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTk2IiB2aWV3Qm94PSIwIDAgODM2IDE5NiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgaGFuZGxlcyBSRFMgbWFuYWdlbWVudCByZXF1ZXN0cyB1c2luZyBBenVyZSBtYW5hZ2VtZW50IEFQSSBhbmQgcmV0dXJucyBSRFMgcmVzcG9uc2VzLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaGMtcmRzLWF6dXJlLW1hbmFnZW1lbnQtYXBpIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM2NDc0OGIiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjE2IiB5PSIzNCIgd2lkdGg9IjIzNiIgaGVpZ2h0PSIxMjgiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iMTM0IiB5PSI2MCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMi41cHgiPlJEUyBtYW5hZ2VtZW50IGNhbGw8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iODIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5zbmFwc2hvdCDCtyBwb2ludC1pbi10aW1lIHJlc3RvcmU8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iOTkiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5yZWFkZXIgwrcgZmFpbG92ZXIgwrcgZ2xvYmFsIGRhdGFiYXNlPC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9IjExNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPkRhdGEgQVBJIMK3IHBhcmFtZXRlcnM8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iMTQyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiOCI+c2FtZSByZXF1ZXN0IC8gcmVzcG9uc2Ugc2hhcGVzPC90ZXh0Pgo8bGluZSB4MT0iMjUyIiB5MT0iNzQiIHgyPSIzMTQiIHkyPSI3NCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtYXp1cmUtbWFuYWdlbWVudC1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPGxpbmUgeDE9IjMxOCIgeTE9IjEyOCIgeDI9IjI1NiIgeTI9IjEyOCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtYXp1cmUtbWFuYWdlbWVudC1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHJlY3QgeD0iMzE4IiB5PSI1NCIgd2lkdGg9IjIwNCIgaGVpZ2h0PSI4OCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSI0MjAiIHk9Ijk0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC1zaXplOjEycHgiPlRlbnNvcjk8L3RleHQ+CiAgPHRleHQgeD0iNDIwIiB5PSIxMTIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPnNlcnZpY2UgYWRhcHRlcjwvdGV4dD4KPGxpbmUgeDE9IjUyMiIgeTE9Ijc0IiB4Mj0iNTg0IiB5Mj0iNzQiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWF6dXJlLW1hbmFnZW1lbnQtYXBpKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxsaW5lIHgxPSI1ODgiIHkxPSIxMjgiIHgyPSI1MjYiIHkyPSIxMjgiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWF6dXJlLW1hbmFnZW1lbnQtYXBpKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxyZWN0IHg9IjU4OCIgeT0iMzQiIHdpZHRoPSIyMzIiIGhlaWdodD0iMTI4IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjcwNCIgeT0iNjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTJweCI+QXp1cmUgbWFuYWdlbWVudCBBUEk8L3RleHQ+Cjx0ZXh0IHg9IjcwNCIgeT0iOTQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5iYWNrdXBzIMK3IHJlc3RvcmVzIMK3IHJlcGxpY2FzPC90ZXh0Pgo8dGV4dCB4PSI3MDQiIHk9IjExMSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPmZhaWxvdmVyIMK3IHVwZGF0ZXMgwrcgcGFyYW1ldGVyczwvdGV4dD4KPC9zdmc+)

Tensor9 translates RDS management requests to the backend API and returns RDS responses.

#### Limitations

Where Aurora and PostgreSQL Flexible Server differ

* **Aurora-specific settings are not supported.** Failover priority / promotion tiers, Serverless v2 autoscaling, global write forwarding and I/O-Optimized storage have no Flexible Server equivalent.
* **Event subscriptions are not supported.** RDS event notifications publish to SNS. Azure Monitor works differently and has no direct equivalent.
* **Parameter groups behave differently: Tensor9 keeps the group and applies its settings as server parameters.** Tensor9 keeps named parameter groups and their overrides. Supported explicit PostgreSQL parameters become Azure server parameters; the group object itself stays with Tensor9 and is not created on the Flexible Server. The group family must match the PostgreSQL version, and Azure's limits on allowed values and restarts still apply. RDS-specific parameters and settings outside the backend's settable list are rejected.

#### Other considerations

**Migration.** Moving the data is a one-time step, covered by this page's migration note: a logical dump and restore, or logical replication for a short cutover. This page describes how things work after cutover.

**Operations.** The customer owns the Flexible Server in their Azure subscription. Maintenance windows, quotas and pricing are Microsoft's.

**Features and capacity.** The comparison table on this page lists feature and high-availability differences. Check the backend's pricing and capacity limits when you size the deployment.

#### 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.

##### Aurora PostgreSQL · Primary allocated compute

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Primary allocated compute. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.

![Aurora PostgreSQL · 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/9ab9ce074b2ba0d3572c6887b76969539a15c4497f25ab4322488b5ae8b3e2ab-light.svg)

![Aurora PostgreSQL · 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/d6e0926e1a9140655b37ebda4d629f4670cdd721786d356611a706eeb5c20537-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) | Aurora PostgreSQL | Target scenario | PostgreSQL Flexible Server | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | PostgreSQL Flexible Server (one copy) | 141.44 | 141.44 |
| 0 | 0.00 | PostgreSQL Flexible Server (two copies) | 282.88 | 282.88 |
| 1,460 | 211.70 | PostgreSQL Flexible Server (one copy) | 141.44 | -70.26 |
| 1,460 | 211.70 | PostgreSQL Flexible Server (two copies) | 282.88 | 71.18 |
| 2,920 | 423.40 | PostgreSQL Flexible Server (one copy) | 271.38 | -152.02 |
| 2,920 | 423.40 | PostgreSQL Flexible Server (two copies) | 542.76 | 119.36 |
| 5,840 | 846.80 | PostgreSQL Flexible Server (one copy) | 531.26 | -315.54 |
| 5,840 | 846.80 | PostgreSQL Flexible Server (two copies) | 1,062.52 | 215.72 |
| 11,680 | 1,693.60 | PostgreSQL Flexible Server (one copy) | 1,051.02 | -642.58 |
| 11,680 | 1,693.60 | PostgreSQL Flexible Server (two copies) | 2,102.04 | 408.44 |
| 23,360 | 3,387.20 | PostgreSQL Flexible Server (one copy) | 2,090.54 | -1,296.66 |
| 23,360 | 3,387.20 | PostgreSQL Flexible Server (two copies) | 4,181.08 | 793.88 |
| 46,720 | 6,774.40 | PostgreSQL Flexible Server (one copy) | 4,169.58 | -2,604.82 |
| 46,720 | 6,774.40 | PostgreSQL Flexible Server (two copies) | 8,339.16 | 1,564.76 |

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 |
| - | - | -: | - |
| PostgreSQL Flexible Server (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| PostgreSQL Flexible Server (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| PostgreSQL Flexible Server (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| PostgreSQL Flexible Server (one copy) | Origin list price · Database reads | 0 | USD/operations |
| PostgreSQL Flexible Server (one copy) | Origin list price · Database writes | 0 | USD/operations |
| PostgreSQL Flexible Server (one copy) | Target CPU / source CPU | 1 | multiplier |
| PostgreSQL Flexible Server (one copy) | Target RAM / source RAM | 1 | multiplier |
| PostgreSQL Flexible Server (one copy) | Target disk / source disk | 1 | multiplier |
| PostgreSQL Flexible Server (one copy) | Target price guess · read | 0 | USD/read |
| PostgreSQL Flexible Server (one copy) | Target price guess · write | 0 | USD/write |
| PostgreSQL Flexible Server (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL Flexible Server (one copy) | Target list price · GiB-month | 0.115 | USD/GiB-month |
| PostgreSQL Flexible Server (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL Flexible Server (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL Flexible Server (one copy) | Target list price · network GiB | 0.087 | USD/network GiB |
| PostgreSQL Flexible Server (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL Flexible Server (one copy) | Target list price · vCPU-hour | 0.053 | USD/vCPU-hour |
| PostgreSQL Flexible Server (one copy) | Target list price · GiB-hour | 0.009 | USD/GiB-hour |
| PostgreSQL Flexible Server (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL Flexible Server (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL Flexible Server (one copy) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL Flexible Server (one copy) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL Flexible Server (one copy) | Target monthly base charge | 0 | USD/month |
| PostgreSQL Flexible Server (one copy) | Target service minimum | 16.09 | USD/month |
| PostgreSQL Flexible Server (one copy) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL Flexible Server (one copy) | Minimum primary RAM | 8 | GiB |
| PostgreSQL Flexible Server (one copy) | Minimum primary disk | 100 | GiB |
| PostgreSQL Flexible Server (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| PostgreSQL Flexible Server (one copy) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL Flexible Server (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL Flexible Server (one copy) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL Flexible Server (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL Flexible Server (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL Flexible Server (one copy) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL Flexible Server (one copy) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL Flexible Server (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL Flexible Server (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL Flexible Server (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL Flexible Server (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL Flexible Server (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| PostgreSQL Flexible Server (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| PostgreSQL Flexible Server (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| PostgreSQL Flexible Server (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| PostgreSQL Flexible Server (two copies) | Origin list price · Database reads | 0 | USD/operations |
| PostgreSQL Flexible Server (two copies) | Origin list price · Database writes | 0 | USD/operations |
| PostgreSQL Flexible Server (two copies) | Target CPU / source CPU | 1 | multiplier |
| PostgreSQL Flexible Server (two copies) | Target RAM / source RAM | 1 | multiplier |
| PostgreSQL Flexible Server (two copies) | Target disk / source disk | 1 | multiplier |
| PostgreSQL Flexible Server (two copies) | Target price guess · read | 0 | USD/read |
| PostgreSQL Flexible Server (two copies) | Target price guess · write | 0 | USD/write |
| PostgreSQL Flexible Server (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL Flexible Server (two copies) | Target list price · GiB-month | 0.115 | USD/GiB-month |
| PostgreSQL Flexible Server (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL Flexible Server (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL Flexible Server (two copies) | Target list price · network GiB | 0.087 | USD/network GiB |
| PostgreSQL Flexible Server (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL Flexible Server (two copies) | Target list price · vCPU-hour | 0.053 | USD/vCPU-hour |
| PostgreSQL Flexible Server (two copies) | Target list price · GiB-hour | 0.009 | USD/GiB-hour |
| PostgreSQL Flexible Server (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL Flexible Server (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL Flexible Server (two copies) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL Flexible Server (two copies) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL Flexible Server (two copies) | Target monthly base charge | 0 | USD/month |
| PostgreSQL Flexible Server (two copies) | Target service minimum | 16.09 | USD/month |
| PostgreSQL Flexible Server (two copies) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL Flexible Server (two copies) | Minimum primary RAM | 8 | GiB |
| PostgreSQL Flexible Server (two copies) | Minimum primary disk | 100 | GiB |
| PostgreSQL Flexible Server (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| PostgreSQL Flexible Server (two copies) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL Flexible Server (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL Flexible Server (two copies) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL Flexible Server (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL Flexible Server (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL Flexible Server (two copies) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL Flexible Server (two copies) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL Flexible Server (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL Flexible Server (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL Flexible Server (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL Flexible Server (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL 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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* Azure Database for PostgreSQL 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 133.62 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: E96ds\_v5 has 96 vCores and 672 GiB ([https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-compute](https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-compute)); Premium SSD storage holds up to 32,767 GiB ([https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-storage](https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-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-872daf3fc345e314056ab6183e28b95413202233` / `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).

##### Aurora PostgreSQL · Stored data

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.

![Aurora PostgreSQL · 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/dbf4920c78399e04d84f53d869b516a805a9b1eec79523479fbb543b60cf10bc-light.svg)

![Aurora PostgreSQL · 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/04dc1f7b977492c6a6ba3dd2def493032e25de561a6717d6f9c2af35e841e205-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) | Aurora PostgreSQL | Target scenario | PostgreSQL Flexible Server | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | PostgreSQL Flexible Server (one copy) | 141.44 | 141.44 |
| 0 | 0.00 | PostgreSQL Flexible Server (two copies) | 282.88 | 282.88 |
| 10 | 1.00 | PostgreSQL Flexible Server (one copy) | 141.44 | 140.44 |
| 10 | 1.00 | PostgreSQL Flexible Server (two copies) | 282.88 | 281.88 |
| 100 | 10.00 | PostgreSQL Flexible Server (one copy) | 147.19 | 137.19 |
| 100 | 10.00 | PostgreSQL Flexible Server (two copies) | 294.38 | 284.38 |
| 1,000 | 100.00 | PostgreSQL Flexible Server (one copy) | 276.57 | 176.57 |
| 1,000 | 100.00 | PostgreSQL Flexible Server (two copies) | 553.13 | 453.13 |
| 10,000 | 1,000.00 | PostgreSQL Flexible Server (one copy) | 1,570.32 | 570.32 |
| 10,000 | 1,000.00 | PostgreSQL Flexible Server (two copies) | 3,140.63 | 2,140.63 |
| 100,000 | 10,000.00 | PostgreSQL Flexible Server (one copy) | Unpriced | Unavailable |
| 100,000 | 10,000.00 | PostgreSQL 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 |
| - | - | -: | - |
| PostgreSQL Flexible Server (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| PostgreSQL Flexible Server (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| PostgreSQL Flexible Server (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| PostgreSQL Flexible Server (one copy) | Origin list price · Database reads | 0 | USD/operations |
| PostgreSQL Flexible Server (one copy) | Origin list price · Database writes | 0 | USD/operations |
| PostgreSQL Flexible Server (one copy) | Target CPU / source CPU | 1 | multiplier |
| PostgreSQL Flexible Server (one copy) | Target RAM / source RAM | 1 | multiplier |
| PostgreSQL Flexible Server (one copy) | Target disk / source disk | 1 | multiplier |
| PostgreSQL Flexible Server (one copy) | Target price guess · read | 0 | USD/read |
| PostgreSQL Flexible Server (one copy) | Target price guess · write | 0 | USD/write |
| PostgreSQL Flexible Server (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL Flexible Server (one copy) | Target list price · GiB-month | 0.115 | USD/GiB-month |
| PostgreSQL Flexible Server (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL Flexible Server (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL Flexible Server (one copy) | Target list price · network GiB | 0.087 | USD/network GiB |
| PostgreSQL Flexible Server (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL Flexible Server (one copy) | Target list price · vCPU-hour | 0.053 | USD/vCPU-hour |
| PostgreSQL Flexible Server (one copy) | Target list price · GiB-hour | 0.009 | USD/GiB-hour |
| PostgreSQL Flexible Server (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL Flexible Server (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL Flexible Server (one copy) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL Flexible Server (one copy) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL Flexible Server (one copy) | Target monthly base charge | 0 | USD/month |
| PostgreSQL Flexible Server (one copy) | Target service minimum | 16.09 | USD/month |
| PostgreSQL Flexible Server (one copy) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL Flexible Server (one copy) | Minimum primary RAM | 8 | GiB |
| PostgreSQL Flexible Server (one copy) | Minimum primary disk | 100 | GiB |
| PostgreSQL Flexible Server (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| PostgreSQL Flexible Server (one copy) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL Flexible Server (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL Flexible Server (one copy) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL Flexible Server (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL Flexible Server (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL Flexible Server (one copy) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL Flexible Server (one copy) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL Flexible Server (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL Flexible Server (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL Flexible Server (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL Flexible Server (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL Flexible Server (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| PostgreSQL Flexible Server (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| PostgreSQL Flexible Server (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| PostgreSQL Flexible Server (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| PostgreSQL Flexible Server (two copies) | Origin list price · Database reads | 0 | USD/operations |
| PostgreSQL Flexible Server (two copies) | Origin list price · Database writes | 0 | USD/operations |
| PostgreSQL Flexible Server (two copies) | Target CPU / source CPU | 1 | multiplier |
| PostgreSQL Flexible Server (two copies) | Target RAM / source RAM | 1 | multiplier |
| PostgreSQL Flexible Server (two copies) | Target disk / source disk | 1 | multiplier |
| PostgreSQL Flexible Server (two copies) | Target price guess · read | 0 | USD/read |
| PostgreSQL Flexible Server (two copies) | Target price guess · write | 0 | USD/write |
| PostgreSQL Flexible Server (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL Flexible Server (two copies) | Target list price · GiB-month | 0.115 | USD/GiB-month |
| PostgreSQL Flexible Server (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL Flexible Server (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL Flexible Server (two copies) | Target list price · network GiB | 0.087 | USD/network GiB |
| PostgreSQL Flexible Server (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL Flexible Server (two copies) | Target list price · vCPU-hour | 0.053 | USD/vCPU-hour |
| PostgreSQL Flexible Server (two copies) | Target list price · GiB-hour | 0.009 | USD/GiB-hour |
| PostgreSQL Flexible Server (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL Flexible Server (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL Flexible Server (two copies) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL Flexible Server (two copies) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL Flexible Server (two copies) | Target monthly base charge | 0 | USD/month |
| PostgreSQL Flexible Server (two copies) | Target service minimum | 16.09 | USD/month |
| PostgreSQL Flexible Server (two copies) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL Flexible Server (two copies) | Minimum primary RAM | 8 | GiB |
| PostgreSQL Flexible Server (two copies) | Minimum primary disk | 100 | GiB |
| PostgreSQL Flexible Server (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| PostgreSQL Flexible Server (two copies) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL Flexible Server (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL Flexible Server (two copies) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL Flexible Server (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL Flexible Server (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL Flexible Server (two copies) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL Flexible Server (two copies) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL Flexible Server (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL Flexible Server (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL Flexible Server (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL Flexible Server (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL 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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* Azure Database for PostgreSQL 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 133.62 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: E96ds\_v5 has 96 vCores and 672 GiB ([https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-compute](https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-compute)); Premium SSD storage holds up to 32,767 GiB ([https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-storage](https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-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-872daf3fc345e314056ab6183e28b95413202233` / `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).

##### Aurora PostgreSQL · Database writes

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Database writes. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.

![Aurora PostgreSQL · 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/f86c9cd145cd50e53b6fef5884d2d27e0dd1176d5f515df0c19682a932870812-light.svg)

![Aurora PostgreSQL · 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/659a6642496d586683683ed1bb0eadf6b0b1d6ca83713e242fcac03f3b3dd636-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) | Aurora PostgreSQL | Target scenario | PostgreSQL Flexible Server | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | PostgreSQL Flexible Server (one copy) | 141.44 | 141.44 |
| 0 | 0.00 | PostgreSQL Flexible Server (two copies) | 282.88 | 282.88 |
| 1 | 0.00 | PostgreSQL Flexible Server (one copy) | 141.44 | 141.44 |
| 1 | 0.00 | PostgreSQL Flexible Server (two copies) | 282.88 | 282.88 |
| 10 | 0.00 | PostgreSQL Flexible Server (one copy) | 141.44 | 141.44 |
| 10 | 0.00 | PostgreSQL Flexible Server (two copies) | 282.88 | 282.88 |
| 100 | 0.00 | PostgreSQL Flexible Server (one copy) | 141.44 | 141.44 |
| 100 | 0.00 | PostgreSQL Flexible Server (two copies) | 282.88 | 282.88 |
| 1,000 | 0.00 | PostgreSQL Flexible Server (one copy) | 141.44 | 141.44 |
| 1,000 | 0.00 | PostgreSQL Flexible Server (two copies) | 282.88 | 282.88 |
| 10,000 | 0.00 | PostgreSQL Flexible Server (one copy) | 141.44 | 141.44 |
| 10,000 | 0.00 | PostgreSQL Flexible Server (two copies) | 282.88 | 282.88 |

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 |
| - | - | -: | - |
| PostgreSQL Flexible Server (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| PostgreSQL Flexible Server (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| PostgreSQL Flexible Server (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| PostgreSQL Flexible Server (one copy) | Origin list price · Database reads | 0 | USD/operations |
| PostgreSQL Flexible Server (one copy) | Origin list price · Database writes | 0 | USD/operations |
| PostgreSQL Flexible Server (one copy) | Target CPU / source CPU | 1 | multiplier |
| PostgreSQL Flexible Server (one copy) | Target RAM / source RAM | 1 | multiplier |
| PostgreSQL Flexible Server (one copy) | Target disk / source disk | 1 | multiplier |
| PostgreSQL Flexible Server (one copy) | Target price guess · read | 0 | USD/read |
| PostgreSQL Flexible Server (one copy) | Target price guess · write | 0 | USD/write |
| PostgreSQL Flexible Server (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL Flexible Server (one copy) | Target list price · GiB-month | 0.115 | USD/GiB-month |
| PostgreSQL Flexible Server (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL Flexible Server (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL Flexible Server (one copy) | Target list price · network GiB | 0.087 | USD/network GiB |
| PostgreSQL Flexible Server (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL Flexible Server (one copy) | Target list price · vCPU-hour | 0.053 | USD/vCPU-hour |
| PostgreSQL Flexible Server (one copy) | Target list price · GiB-hour | 0.009 | USD/GiB-hour |
| PostgreSQL Flexible Server (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL Flexible Server (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL Flexible Server (one copy) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL Flexible Server (one copy) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL Flexible Server (one copy) | Target monthly base charge | 0 | USD/month |
| PostgreSQL Flexible Server (one copy) | Target service minimum | 16.09 | USD/month |
| PostgreSQL Flexible Server (one copy) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL Flexible Server (one copy) | Minimum primary RAM | 8 | GiB |
| PostgreSQL Flexible Server (one copy) | Minimum primary disk | 100 | GiB |
| PostgreSQL Flexible Server (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| PostgreSQL Flexible Server (one copy) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL Flexible Server (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL Flexible Server (one copy) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL Flexible Server (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL Flexible Server (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL Flexible Server (one copy) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL Flexible Server (one copy) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL Flexible Server (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL Flexible Server (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL Flexible Server (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL Flexible Server (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL Flexible Server (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| PostgreSQL Flexible Server (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| PostgreSQL Flexible Server (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| PostgreSQL Flexible Server (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| PostgreSQL Flexible Server (two copies) | Origin list price · Database reads | 0 | USD/operations |
| PostgreSQL Flexible Server (two copies) | Origin list price · Database writes | 0 | USD/operations |
| PostgreSQL Flexible Server (two copies) | Target CPU / source CPU | 1 | multiplier |
| PostgreSQL Flexible Server (two copies) | Target RAM / source RAM | 1 | multiplier |
| PostgreSQL Flexible Server (two copies) | Target disk / source disk | 1 | multiplier |
| PostgreSQL Flexible Server (two copies) | Target price guess · read | 0 | USD/read |
| PostgreSQL Flexible Server (two copies) | Target price guess · write | 0 | USD/write |
| PostgreSQL Flexible Server (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL Flexible Server (two copies) | Target list price · GiB-month | 0.115 | USD/GiB-month |
| PostgreSQL Flexible Server (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL Flexible Server (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL Flexible Server (two copies) | Target list price · network GiB | 0.087 | USD/network GiB |
| PostgreSQL Flexible Server (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL Flexible Server (two copies) | Target list price · vCPU-hour | 0.053 | USD/vCPU-hour |
| PostgreSQL Flexible Server (two copies) | Target list price · GiB-hour | 0.009 | USD/GiB-hour |
| PostgreSQL Flexible Server (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL Flexible Server (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL Flexible Server (two copies) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL Flexible Server (two copies) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL Flexible Server (two copies) | Target monthly base charge | 0 | USD/month |
| PostgreSQL Flexible Server (two copies) | Target service minimum | 16.09 | USD/month |
| PostgreSQL Flexible Server (two copies) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL Flexible Server (two copies) | Minimum primary RAM | 8 | GiB |
| PostgreSQL Flexible Server (two copies) | Minimum primary disk | 100 | GiB |
| PostgreSQL Flexible Server (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| PostgreSQL Flexible Server (two copies) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL Flexible Server (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL Flexible Server (two copies) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL Flexible Server (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL Flexible Server (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL Flexible Server (two copies) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL Flexible Server (two copies) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL Flexible Server (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL Flexible Server (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL Flexible Server (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL Flexible Server (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL 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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* Azure Database for PostgreSQL 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 133.62 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: E96ds\_v5 has 96 vCores and 672 GiB ([https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-compute](https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-compute)); Premium SSD storage holds up to 32,767 GiB ([https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-storage](https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-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-872daf3fc345e314056ab6183e28b95413202233` / `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).

**Aurora PostgreSQL → PostgreSQL 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 | 52.56 |
| 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.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.145 | USD/vCPU-hours |
| Origin list price · Primary memory | 0 | USD/GiB-hours |
| Origin list price · Primary provisioned storage | 0.1 | 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.009 | 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 | 16.09 | 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.

* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.

* Azure Database for PostgreSQL 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 133.62 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: E96ds\_v5 has 96 vCores and 672 GiB ([https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-compute](https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-compute)); Premium SSD storage holds up to 32,767 GiB ([https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-storage](https://learn.microsoft.com/en-us/azure/postgresql/compute-storage/concepts-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-872daf3fc345e314056ab6183e28b95413202233` / `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

### PostgreSQL

| 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 |
| PostgreSQL client protocol (application SQL) | Wire protocol | Supported | Common | connects directly to Managed PostgreSQL; check the selected engine version and supported extensions or plugins |

#### How it works

Your application connects to DigitalOcean Managed PostgreSQL with its usual PostgreSQL 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. The adapter maps the Aurora cluster to a primary database and separate read-only nodes. Applications that use the Aurora Data API send those requests through the adapter, which runs them as SQL over a PostgreSQL connection; direct PostgreSQL clients connect to the database.

![Database requests (PostgreSQL protocol) connect directly to Managed PostgreSQL. The Tensor9 service adapter translates RDS API management calls to DigitalOcean database API.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoUG9zdGdyZVNRTCBwcm90b2NvbCkgY29ubmVjdCBkaXJlY3RseSB0byBNYW5hZ2VkIFBvc3RncmVTUUwuIFRoZSBUZW5zb3I5IHNlcnZpY2UgYWRhcHRlciB0cmFuc2xhdGVzIFJEUyBBUEkgbWFuYWdlbWVudCBjYWxscyB0byBEaWdpdGFsT2NlYW4gZGF0YWJhc2UgQVBJLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaGQtbWFuYWdlZC1wb3N0Z3Jlc3FsIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM5NGEzYjgiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjgiIHk9IjM0IiB3aWR0aD0iODIwIiBoZWlnaHQ9IjIwNiIgcng9IjE2IiBzdHJva2Utd2lkdGg9IjEuNCIgc3Ryb2tlLWRhc2hhcnJheT0iNSA1IiBzdHlsZT0iZmlsbDojZjhmYWZjO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjI2IiB5PSI1NCIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjg7IGZpbGw6IzA0Nzg1NyI+T04gRElHSVRBTE9DRUFOPC90ZXh0PjxzdmcgeD0iNzkyIiB5PSIzNiIgd2lkdGg9IjE2IiBoZWlnaHQ9IjE2IiB2aWV3Qm94PSIwIDAgMzIgMzIiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiIGZpbGw9Im5vbmUiPjxwYXRoIGQ9Ik0xNi4wMjE5IDI1LjgwMzZWMzJDMjYuNDg3NCAzMiAzNC42MzE2IDIxLjg4ODEgMzEuMjA2NSAxMC45MDJDMjkuNjg0MiA2LjExMjE0IDI1Ljg3ODUgMi4yNzI2OCAyMS4wODM0IDAuNzkwMTEyQzEwLjEyMzEgLTIuNjMxMTkgMCA1LjU0MTkyIDAgMTUuOTk1OUg2LjIwMzI0QzYuMjAzMjQgOS40NTc0MSAxMi43MTA5IDQuMzYzNDcgMTkuNjM3MiA2Ljg3MjQzQzIyLjE4NyA3Ljc4NDc4IDI0LjI0MjEgOS44Mzc1NiAyNS4xNTU1IDEyLjM4NDVDMjcuNjY3MiAxOS4zMDMyIDIyLjYwNTcgMjUuODAzNiAxNi4wMjE5IDI1LjgwMzZaIiBzdHlsZT0iZmlsbDojNDc1NTY5Ii8+IDxwYXRoIGQ9Ik05Ljg1NTQ3IDI1Ljg0MTdIMTYuMDIwNlYxOS42ODM0SDkuODU1NDdWMjUuODQxN1oiIHN0eWxlPSJmaWxsOiM0NzU1NjkiLz4gPHBhdGggZD0iTTkuODU0NzQgMzAuNTkzNEg1LjA5NzY2VjI1Ljg0MTdMOS44NTU0NyAyNS44NDE3TDkuODU0NzQgMzAuNTkzNFoiIHN0eWxlPSJmaWxsOiM0NzU1NjkiLz4gPHBhdGggZD0iTTEuMTA5MzggMjUuODQxN0g1LjA2NzI3VjIxLjg4ODJIMS4xMDkzOFYyNS44NDE3WiIgc3R5bGU9ImZpbGw6IzQ3NTU2OSIvPjwvc3ZnPgo8cmVjdCB4PSIyNiIgeT0iODgiIHdpZHRoPSIxMjgiIGhlaWdodD0iMTEyIiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjkwIiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTNweCI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIxNDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5Qb3N0Z3JlU1FMIGRyaXZlcjwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjE2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij51bmNoYW5nZWQ8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iODIiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4OyBmaWxsOiMwNDc4NTciPkRBVEFCQVNFIFJFUVVFU1RTIMK3IERJUkVDVCBDT05ORUNUSU9OPC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTA4IiB4Mj0iNjEwIiB5Mj0iMTA4IiBzdHJva2Utd2lkdGg9IjIuMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtbWFuYWdlZC1wb3N0Z3Jlc3FsKSIgc3R5bGU9InN0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjM4MiIgeT0iMTAwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YjsgZmlsbDojMDQ3ODU3Ij5Qb3N0Z3JlU1FMIHByb3RvY29sPC90ZXh0Pgo8cmVjdCB4PSI2MTQiIHk9Ijc2IiB3aWR0aD0iMTk2IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+PHN2ZyB4PSI3ODYiIHk9IjU2IiB3aWR0aD0iMjAiIGhlaWdodD0iMjAiIHZpZXdCb3g9IjAgMCA0MzIuMDcxIDQ0NS4zODMiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiPjxnIHN0eWxlPSJmaWxsLXJ1bGU6bm9uemVybztjbGlwLXJ1bGU6bm9uemVybztzdHJva2U6IzAwMDAwMDtzdHJva2UtbWl0ZXJsaW1pdDo0Ij4gPC9nPiA8ZyBzdHlsZT0iZmlsbC1ydWxlOm5vbnplcm87Y2xpcC1ydWxlOm5vbnplcm87ZmlsbDpub25lO3N0cm9rZTojRkZGRkZGO3N0cm9rZS13aWR0aDoxMi40NjUxO3N0cm9rZS1saW5lY2FwOnJvdW5kO3N0cm9rZS1saW5lam9pbjpyb3VuZDtzdHJva2UtbWl0ZXJsaW1pdDo0Ij4gPHBhdGggZD0iTTMyMy4yMDUsMzI0LjIyN2MyLjgzMy0yMy42MDEsMS45ODQtMjcuMDYyLDE5LjU2My0yMy4yMzlsNC40NjMsMC4zOTJjMTMuNTE3LDAuNjE1LDMxLjE5OS0yLjE3NCw0MS41ODctN2MyMi4zNjItMTAuMzc2LDM1LjYyMi0yNy43LDEzLjU3Mi0yMy4xNDhjLTUwLjI5NywxMC4zNzYtNTMuNzU1LTYuNjU1LTUzLjc1NS02LjY1NWM1My4xMTEtNzguODAzLDc1LjMxMy0xNzguODM2LDU2LjE0OS0yMDMuMzIyIEMzNTIuNTE0LTUuNTM0LDI2Mi4wMzYsMjYuMDQ5LDI2MC41MjIsMjYuODY5bC0wLjQ4MiwwLjA4OWMtOS45MzgtMi4wNjItMjEuMDYtMy4yOTQtMzMuNTU0LTMuNDk2Yy0yMi43NjEtMC4zNzQtNDAuMDMyLDUuOTY3LTUzLjEzMywxNS45MDRjMCwwLTE2MS40MDgtNjYuNDk4LTE1My44OTksODMuNjI4YzEuNTk3LDMxLjkzNiw0NS43NzcsMjQxLjY1NSw5OC40NywxNzguMzEgYzE5LjI1OS0yMy4xNjMsMzcuODcxLTQyLjc0OCwzNy44NzEtNDIuNzQ4YzkuMjQyLDYuMTQsMjAuMzA3LDkuMjcyLDMxLjkxMiw4LjE0N2wwLjg5Ny0wLjc2NWMtMC4yODEsMi44NzYtMC4xNTcsNS42ODksMC4zNTksOS4wMTljLTEzLjU3MiwxNS4xNjctOS41ODQsMTcuODMtMzYuNzIzLDIzLjQxNmMtMjcuNDU3LDUuNjU5LTExLjMyNiwxNS43MzQtMC43OTcsMTguMzY3YzEyLjc2OCwzLjE5Myw0Mi4zMDUsNy43MTYsNjIuMjY4LTIwLjIyNCBsLTAuNzk1LDMuMTg4YzUuMzI1LDQuMjYsNC45NjUsMzAuNjE5LDUuNzIsNDkuNDUyYzAuNzU2LDE4LjgzNCwyLjAxNywzNi40MDksNS44NTYsNDYuNzcxYzMuODM5LDEwLjM2LDguMzY5LDM3LjA1LDQ0LjAzNiwyOS40MDZjMjkuODA5LTYuMzg4LDUyLjYtMTUuNTgyLDU0LjY3Ny0xMDEuMTA3IiBzdHlsZT0iZmlsbDojMDAwMDAwO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDozNy4zOTUzO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyIi8+IDxwYXRoIGQ9Ik00MDIuMzk1LDI3MS4yM2MtNTAuMzAyLDEwLjM3Ni01My43Ni02LjY1NS01My43Ni02LjY1NWM1My4xMTEtNzguODA4LDc1LjMxMy0xNzguODQzLDU2LjE1My0yMDMuMzI2Yy01Mi4yNy02Ni43ODUtMTQyLjc1Mi0zNS4yLTE0NC4yNjItMzQuMzhsLTAuNDg2LDAuMDg3Yy05LjkzOC0yLjA2My0yMS4wNi0zLjI5Mi0zMy41Ni0zLjQ5NmMtMjIuNzYxLTAuMzczLTQwLjAyNiw1Ljk2Ny01My4xMjcsMTUuOTAyIGMwLDAtMTYxLjQxMS02Ni40OTUtMTUzLjkwNCw4My42M2MxLjU5NywzMS45MzgsNDUuNzc2LDI0MS42NTcsOTguNDcxLDE3OC4zMTJjMTkuMjYtMjMuMTYzLDM3Ljg2OS00Mi43NDgsMzcuODY5LTQyLjc0OGM5LjI0Myw2LjE0LDIwLjMwOCw5LjI3MiwzMS45MDgsOC4xNDdsMC45MDEtMC43NjVjLTAuMjgsMi44NzYtMC4xNTIsNS42ODksMC4zNjEsOS4wMTljLTEzLjU3NSwxNS4xNjctOS41ODYsMTcuODMtMzYuNzIzLDIzLjQxNiBjLTI3LjQ1OSw1LjY1OS0xMS4zMjgsMTUuNzM0LTAuNzk2LDE4LjM2N2MxMi43NjgsMy4xOTMsNDIuMzA3LDcuNzE2LDYyLjI2Ni0yMC4yMjRsLTAuNzk2LDMuMTg4YzUuMzE5LDQuMjYsOS4wNTQsMjcuNzExLDguNDI4LDQ4Ljk2OWMtMC42MjYsMjEuMjU5LTEuMDQ0LDM1Ljg1NCwzLjE0Nyw0Ny4yNTRjNC4xOTEsMTEuNCw4LjM2OCwzNy4wNSw0NC4wNDIsMjkuNDA2YzI5LjgwOS02LjM4OCw0NS4yNTYtMjIuOTQyLDQ3LjQwNS01MC41NTUgYzEuNTI1LTE5LjYzMSw0Ljk3Ni0xNi43MjksNS4xOTQtMzQuMjhsMi43NjgtOC4zMDljMy4xOTItMjYuNjExLDAuNTA3LTM1LjE5NiwxOC44NzItMzEuMjAzbDQuNDYzLDAuMzkyYzEzLjUxNywwLjYxNSwzMS4yMDgtMi4xNzQsNDEuNTkxLTdjMjIuMzU4LTEwLjM3NiwzNS42MTgtMjcuNywxMy41NzMtMjMuMTQ4eiIgc3R5bGU9ImZpbGw6IzMzNjc5MTtzdHJva2U6bm9uZSIvPiA8cGF0aCBkPSJNMjE1Ljg2NiwyODYuNDg0Yy0xLjM4NSw0OS41MTYsMC4zNDgsOTkuMzc3LDUuMTkzLDExMS40OTVjNC44NDgsMTIuMTE4LDE1LjIyMywzNS42ODgsNTAuOSwyOC4wNDVjMjkuODA2LTYuMzksNDAuNjUxLTE4Ljc1Niw0NS4zNTctNDYuMDUxYzMuNDY2LTIwLjA4MiwxMC4xNDgtNzUuODU0LDExLjAwNS04Ny4yODEiLz4gPHBhdGggZD0iTTE3My4xMDQsMzguMjU2YzAsMC0xNjEuNTIxLTY2LjAxNi0xNTQuMDEyLDg0LjEwOWMxLjU5NywzMS45MzgsNDUuNzc5LDI0MS42NjQsOTguNDczLDE3OC4zMTZjMTkuMjU2LTIzLjE2NiwzNi42NzEtNDEuMzM1LDM2LjY3MS00MS4zMzUiLz4gPHBhdGggZD0iTTI2MC4zNDksMjYuMjA3Yy01LjU5MSwxLjc1Myw4OS44NDgtMzQuODg5LDE0NC4wODcsMzQuNDE3YzE5LjE1OSwyNC40ODQtMy4wNDMsMTI0LjUxOS01Ni4xNTMsMjAzLjMyOSIvPiA8cGF0aCBkPSJNMzQ4LjI4MiwyNjMuOTUzYzAsMCwzLjQ2MSwxNy4wMzYsNTMuNzY0LDYuNjUzYzIyLjA0LTQuNTUyLDguNzc2LDEyLjc3NC0xMy41NzcsMjMuMTU1Yy0xOC4zNDUsOC41MTQtNTkuNDc0LDEwLjY5Ni02MC4xNDYtMS4wNjljLTEuNzI5LTMwLjM1NSwyMS42NDctMjEuMTMzLDE5Ljk2LTI4LjczOWMtMS41MjUtNi44NS0xMS45NzktMTMuNTczLTE4Ljg5NC0zMC4zMzggYy02LjAzNy0xNC42MzMtODIuNzk2LTEyNi44NDksMjEuMjg3LTExMC4xODNjMy44MTMtMC43ODktMjcuMTQ2LTk5LjAwMi0xMjQuNTUzLTEwMC41OTljLTk3LjM4NS0xLjU5Ny05NC4xOSwxMTkuNzYyLTk0LjE5LDExOS43NjIiIHN0eWxlPSJzdHJva2UtbGluZWpvaW46YmV2ZWwiLz4gPHBhdGggZD0iTTE4OC42MDQsMjc0LjMzNGMtMTMuNTc3LDE1LjE2Ni05LjU4NCwxNy44MjktMzYuNzIzLDIzLjQxN2MtMjcuNDU5LDUuNjYtMTEuMzI2LDE1LjczMy0wLjc5NywxOC4zNjVjMTIuNzY4LDMuMTk1LDQyLjMwNyw3LjcxOCw2Mi4yNjYtMjAuMjI5YzYuMDc4LTguNTA5LTAuMDM2LTIyLjA4Ni04LjM4NS0yNS41NDdjLTQuMDM0LTEuNjcxLTkuNDI4LTMuNzY1LTE2LjM2MSwzLjk5NHoiLz4gPHBhdGggZD0iTTE4Ny43MTUsMjc0LjA2OWMtMS4zNjgtOC45MTcsMi45My0xOS41MjgsNy41MzYtMzEuOTQyYzYuOTIyLTE4LjYyNiwyMi44OTMtMzcuMjU1LDEwLjExNy05Ni4zMzljLTkuNTIzLTQ0LjAyOS03My4zOTYtOS4xNjMtNzMuNDM2LTMuMTkzYy0wLjAzOSw1Ljk2OCwyLjg4OSwzMC4yNi0xLjA2Nyw1OC41NDhjLTUuMTYyLDM2LjkxMywyMy40ODgsNjguMTMyLDU2LjQ3OSw2NC45MzgiLz4gPHBhdGggZD0iTTE3Mi41MTcsMTQxLjdjLTAuMjg4LDIuMDM5LDMuNzMzLDcuNDgsOC45NzYsOC4yMDdjNS4yMzQsMC43Myw5LjcxNC0zLjUyMiw5Ljk5OC01LjU1OWMwLjI4NC0yLjAzOS0zLjczMi00LjI4NS04Ljk3Ny01LjAxNWMtNS4yMzctMC43MzEtOS43MTksMC4zMzMtOS45OTYsMi4zNjd6IiBzdHlsZT0iZmlsbDojRkZGRkZGO3N0cm9rZS13aWR0aDo0LjE1NTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNMzMxLjk0MSwxMzcuNTQzYzAuMjg0LDIuMDM5LTMuNzMyLDcuNDgtOC45NzYsOC4yMDdjLTUuMjM4LDAuNzMtOS43MTgtMy41MjItMTAuMDA1LTUuNTU5Yy0wLjI3Ny0yLjAzOSwzLjc0LTQuMjg1LDguOTc5LTUuMDE1YzUuMjM5LTAuNzMsOS43MTgsMC4zMzMsMTAuMDAyLDIuMzY4eiIgc3R5bGU9ImZpbGw6I0ZGRkZGRjtzdHJva2Utd2lkdGg6Mi4wNzc1O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyIi8+IDxwYXRoIGQ9Ik0zNTAuNjc2LDEyMy40MzJjMC44NjMsMTUuOTk0LTMuNDQ1LDI2Ljg4OC0zLjk4OCw0My45MTRjLTAuODA0LDI0Ljc0OCwxMS43OTksNTMuMDc0LTcuMTkxLDgxLjQzNSIvPiA8cGF0aCBkPSJNMCw2MC4yMzIiIHN0eWxlPSJzdHJva2Utd2lkdGg6MyIvPiA8L2c+PC9zdmc+Cjx0ZXh0IHg9IjcxMiIgeT0iMTAzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjEycHgiPk1hbmFnZWQgUG9zdGdyZVNRTDwvdGV4dD4KPHRleHQgeD0iNzEyIiB5PSIxMjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5Qb3N0Z3JlU1FMIGVuZ2luZTwvdGV4dD4KPHRleHQgeD0iMjAwIiB5PSIxNTgiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4Ij5NQU5BR0VNRU5UIFJFUVVFU1RTIMK3IFZJQSBURU5TT1I5PC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTk2IiB4Mj0iMzAwIiB5Mj0iMTk2IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLW1hbmFnZWQtcG9zdGdyZXNxbCkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8dGV4dCB4PSIyMjciIHk9IjE4OCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGIiPlJEUyBBUEk8L3RleHQ+CjxyZWN0IHg9IjMwNCIgeT0iMTY0IiB3aWR0aD0iMTgwIiBoZWlnaHQ9IjY2IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjM5NCIgeT0iMTkxIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC1zaXplOjEycHgiPlRlbnNvcjk8L3RleHQ+CiAgPHRleHQgeD0iMzk0IiB5PSIyMDgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPnNlcnZpY2UgYWRhcHRlcjwvdGV4dD4KPGxpbmUgeDE9IjQ4NCIgeTE9IjE5NiIgeDI9IjYxMCIgeTI9IjE5NiIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoZC1tYW5hZ2VkLXBvc3RncmVzcWwpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHJlY3QgeD0iNjE0IiB5PSIxNjQiIHdpZHRoPSIxOTYiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iNzEyIiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTEuNXB4Ij5EaWdpdGFsT2NlYW4gZGF0YWJhc2UgQVBJPC90ZXh0Pgo8dGV4dCB4PSI3MTIiIHk9IjIxMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPnRoZSBiYWNrZW5kJ3MgbWFuYWdlbWVudCBBUEk8L3RleHQ+Cjwvc3ZnPg==)

![Database requests (PostgreSQL protocol) connect directly to Managed PostgreSQL. The Tensor9 service adapter translates RDS API management calls to DigitalOcean database API.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoUG9zdGdyZVNRTCBwcm90b2NvbCkgY29ubmVjdCBkaXJlY3RseSB0byBNYW5hZ2VkIFBvc3RncmVTUUwuIFRoZSBUZW5zb3I5IHNlcnZpY2UgYWRhcHRlciB0cmFuc2xhdGVzIFJEUyBBUEkgbWFuYWdlbWVudCBjYWxscyB0byBEaWdpdGFsT2NlYW4gZGF0YWJhc2UgQVBJLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaGQtbWFuYWdlZC1wb3N0Z3Jlc3FsIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM2NDc0OGIiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjgiIHk9IjM0IiB3aWR0aD0iODIwIiBoZWlnaHQ9IjIwNiIgcng9IjE2IiBzdHJva2Utd2lkdGg9IjEuNCIgc3Ryb2tlLWRhc2hhcnJheT0iNSA1IiBzdHlsZT0iZmlsbDojMGYxNzJhO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjI2IiB5PSI1NCIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGI7IGZpbGw6IzZlZTdiNyI+T04gRElHSVRBTE9DRUFOPC90ZXh0PjxzdmcgeD0iNzkyIiB5PSIzNiIgd2lkdGg9IjE2IiBoZWlnaHQ9IjE2IiB2aWV3Qm94PSIwIDAgMzIgMzIiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiIGZpbGw9Im5vbmUiPjxwYXRoIGQ9Ik0xNi4wMjE5IDI1LjgwMzZWMzJDMjYuNDg3NCAzMiAzNC42MzE2IDIxLjg4ODEgMzEuMjA2NSAxMC45MDJDMjkuNjg0MiA2LjExMjE0IDI1Ljg3ODUgMi4yNzI2OCAyMS4wODM0IDAuNzkwMTEyQzEwLjEyMzEgLTIuNjMxMTkgMCA1LjU0MTkyIDAgMTUuOTk1OUg2LjIwMzI0QzYuMjAzMjQgOS40NTc0MSAxMi43MTA5IDQuMzYzNDcgMTkuNjM3MiA2Ljg3MjQzQzIyLjE4NyA3Ljc4NDc4IDI0LjI0MjEgOS44Mzc1NiAyNS4xNTU1IDEyLjM4NDVDMjcuNjY3MiAxOS4zMDMyIDIyLjYwNTcgMjUuODAzNiAxNi4wMjE5IDI1LjgwMzZaIiBzdHlsZT0iZmlsbDojY2JkNWUxIi8+IDxwYXRoIGQ9Ik05Ljg1NTQ3IDI1Ljg0MTdIMTYuMDIwNlYxOS42ODM0SDkuODU1NDdWMjUuODQxN1oiIHN0eWxlPSJmaWxsOiNjYmQ1ZTEiLz4gPHBhdGggZD0iTTkuODU0NzQgMzAuNTkzNEg1LjA5NzY2VjI1Ljg0MTdMOS44NTU0NyAyNS44NDE3TDkuODU0NzQgMzAuNTkzNFoiIHN0eWxlPSJmaWxsOiNjYmQ1ZTEiLz4gPHBhdGggZD0iTTEuMTA5MzggMjUuODQxN0g1LjA2NzI3VjIxLjg4ODJIMS4xMDkzOFYyNS44NDE3WiIgc3R5bGU9ImZpbGw6I2NiZDVlMSIvPjwvc3ZnPgo8cmVjdCB4PSIyNiIgeT0iODgiIHdpZHRoPSIxMjgiIGhlaWdodD0iMTEyIiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjkwIiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTNweCI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIxNDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5Qb3N0Z3JlU1FMIGRyaXZlcjwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjE2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij51bmNoYW5nZWQ8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iODIiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiM2ZWU3YjciPkRBVEFCQVNFIFJFUVVFU1RTIMK3IERJUkVDVCBDT05ORUNUSU9OPC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTA4IiB4Mj0iNjEwIiB5Mj0iMTA4IiBzdHJva2Utd2lkdGg9IjIuMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtbWFuYWdlZC1wb3N0Z3Jlc3FsKSIgc3R5bGU9InN0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjM4MiIgeT0iMTAwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiODsgZmlsbDojNmVlN2I3Ij5Qb3N0Z3JlU1FMIHByb3RvY29sPC90ZXh0Pgo8cmVjdCB4PSI2MTQiIHk9Ijc2IiB3aWR0aD0iMTk2IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+PHN2ZyB4PSI3ODYiIHk9IjU2IiB3aWR0aD0iMjAiIGhlaWdodD0iMjAiIHZpZXdCb3g9IjAgMCA0MzIuMDcxIDQ0NS4zODMiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiPjxnIHN0eWxlPSJmaWxsLXJ1bGU6bm9uemVybztjbGlwLXJ1bGU6bm9uemVybztzdHJva2U6IzAwMDAwMDtzdHJva2UtbWl0ZXJsaW1pdDo0Ij4gPC9nPiA8ZyBzdHlsZT0iZmlsbC1ydWxlOm5vbnplcm87Y2xpcC1ydWxlOm5vbnplcm87ZmlsbDpub25lO3N0cm9rZTojRkZGRkZGO3N0cm9rZS13aWR0aDoxMi40NjUxO3N0cm9rZS1saW5lY2FwOnJvdW5kO3N0cm9rZS1saW5lam9pbjpyb3VuZDtzdHJva2UtbWl0ZXJsaW1pdDo0Ij4gPHBhdGggZD0iTTMyMy4yMDUsMzI0LjIyN2MyLjgzMy0yMy42MDEsMS45ODQtMjcuMDYyLDE5LjU2My0yMy4yMzlsNC40NjMsMC4zOTJjMTMuNTE3LDAuNjE1LDMxLjE5OS0yLjE3NCw0MS41ODctN2MyMi4zNjItMTAuMzc2LDM1LjYyMi0yNy43LDEzLjU3Mi0yMy4xNDhjLTUwLjI5NywxMC4zNzYtNTMuNzU1LTYuNjU1LTUzLjc1NS02LjY1NWM1My4xMTEtNzguODAzLDc1LjMxMy0xNzguODM2LDU2LjE0OS0yMDMuMzIyIEMzNTIuNTE0LTUuNTM0LDI2Mi4wMzYsMjYuMDQ5LDI2MC41MjIsMjYuODY5bC0wLjQ4MiwwLjA4OWMtOS45MzgtMi4wNjItMjEuMDYtMy4yOTQtMzMuNTU0LTMuNDk2Yy0yMi43NjEtMC4zNzQtNDAuMDMyLDUuOTY3LTUzLjEzMywxNS45MDRjMCwwLTE2MS40MDgtNjYuNDk4LTE1My44OTksODMuNjI4YzEuNTk3LDMxLjkzNiw0NS43NzcsMjQxLjY1NSw5OC40NywxNzguMzEgYzE5LjI1OS0yMy4xNjMsMzcuODcxLTQyLjc0OCwzNy44NzEtNDIuNzQ4YzkuMjQyLDYuMTQsMjAuMzA3LDkuMjcyLDMxLjkxMiw4LjE0N2wwLjg5Ny0wLjc2NWMtMC4yODEsMi44NzYtMC4xNTcsNS42ODksMC4zNTksOS4wMTljLTEzLjU3MiwxNS4xNjctOS41ODQsMTcuODMtMzYuNzIzLDIzLjQxNmMtMjcuNDU3LDUuNjU5LTExLjMyNiwxNS43MzQtMC43OTcsMTguMzY3YzEyLjc2OCwzLjE5Myw0Mi4zMDUsNy43MTYsNjIuMjY4LTIwLjIyNCBsLTAuNzk1LDMuMTg4YzUuMzI1LDQuMjYsNC45NjUsMzAuNjE5LDUuNzIsNDkuNDUyYzAuNzU2LDE4LjgzNCwyLjAxNywzNi40MDksNS44NTYsNDYuNzcxYzMuODM5LDEwLjM2LDguMzY5LDM3LjA1LDQ0LjAzNiwyOS40MDZjMjkuODA5LTYuMzg4LDUyLjYtMTUuNTgyLDU0LjY3Ny0xMDEuMTA3IiBzdHlsZT0iZmlsbDojMDAwMDAwO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDozNy4zOTUzO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyIi8+IDxwYXRoIGQ9Ik00MDIuMzk1LDI3MS4yM2MtNTAuMzAyLDEwLjM3Ni01My43Ni02LjY1NS01My43Ni02LjY1NWM1My4xMTEtNzguODA4LDc1LjMxMy0xNzguODQzLDU2LjE1My0yMDMuMzI2Yy01Mi4yNy02Ni43ODUtMTQyLjc1Mi0zNS4yLTE0NC4yNjItMzQuMzhsLTAuNDg2LDAuMDg3Yy05LjkzOC0yLjA2My0yMS4wNi0zLjI5Mi0zMy41Ni0zLjQ5NmMtMjIuNzYxLTAuMzczLTQwLjAyNiw1Ljk2Ny01My4xMjcsMTUuOTAyIGMwLDAtMTYxLjQxMS02Ni40OTUtMTUzLjkwNCw4My42M2MxLjU5NywzMS45MzgsNDUuNzc2LDI0MS42NTcsOTguNDcxLDE3OC4zMTJjMTkuMjYtMjMuMTYzLDM3Ljg2OS00Mi43NDgsMzcuODY5LTQyLjc0OGM5LjI0Myw2LjE0LDIwLjMwOCw5LjI3MiwzMS45MDgsOC4xNDdsMC45MDEtMC43NjVjLTAuMjgsMi44NzYtMC4xNTIsNS42ODksMC4zNjEsOS4wMTljLTEzLjU3NSwxNS4xNjctOS41ODYsMTcuODMtMzYuNzIzLDIzLjQxNiBjLTI3LjQ1OSw1LjY1OS0xMS4zMjgsMTUuNzM0LTAuNzk2LDE4LjM2N2MxMi43NjgsMy4xOTMsNDIuMzA3LDcuNzE2LDYyLjI2Ni0yMC4yMjRsLTAuNzk2LDMuMTg4YzUuMzE5LDQuMjYsOS4wNTQsMjcuNzExLDguNDI4LDQ4Ljk2OWMtMC42MjYsMjEuMjU5LTEuMDQ0LDM1Ljg1NCwzLjE0Nyw0Ny4yNTRjNC4xOTEsMTEuNCw4LjM2OCwzNy4wNSw0NC4wNDIsMjkuNDA2YzI5LjgwOS02LjM4OCw0NS4yNTYtMjIuOTQyLDQ3LjQwNS01MC41NTUgYzEuNTI1LTE5LjYzMSw0Ljk3Ni0xNi43MjksNS4xOTQtMzQuMjhsMi43NjgtOC4zMDljMy4xOTItMjYuNjExLDAuNTA3LTM1LjE5NiwxOC44NzItMzEuMjAzbDQuNDYzLDAuMzkyYzEzLjUxNywwLjYxNSwzMS4yMDgtMi4xNzQsNDEuNTkxLTdjMjIuMzU4LTEwLjM3NiwzNS42MTgtMjcuNywxMy41NzMtMjMuMTQ4eiIgc3R5bGU9ImZpbGw6IzMzNjc5MTtzdHJva2U6bm9uZSIvPiA8cGF0aCBkPSJNMjE1Ljg2NiwyODYuNDg0Yy0xLjM4NSw0OS41MTYsMC4zNDgsOTkuMzc3LDUuMTkzLDExMS40OTVjNC44NDgsMTIuMTE4LDE1LjIyMywzNS42ODgsNTAuOSwyOC4wNDVjMjkuODA2LTYuMzksNDAuNjUxLTE4Ljc1Niw0NS4zNTctNDYuMDUxYzMuNDY2LTIwLjA4MiwxMC4xNDgtNzUuODU0LDExLjAwNS04Ny4yODEiLz4gPHBhdGggZD0iTTE3My4xMDQsMzguMjU2YzAsMC0xNjEuNTIxLTY2LjAxNi0xNTQuMDEyLDg0LjEwOWMxLjU5NywzMS45MzgsNDUuNzc5LDI0MS42NjQsOTguNDczLDE3OC4zMTZjMTkuMjU2LTIzLjE2NiwzNi42NzEtNDEuMzM1LDM2LjY3MS00MS4zMzUiLz4gPHBhdGggZD0iTTI2MC4zNDksMjYuMjA3Yy01LjU5MSwxLjc1Myw4OS44NDgtMzQuODg5LDE0NC4wODcsMzQuNDE3YzE5LjE1OSwyNC40ODQtMy4wNDMsMTI0LjUxOS01Ni4xNTMsMjAzLjMyOSIvPiA8cGF0aCBkPSJNMzQ4LjI4MiwyNjMuOTUzYzAsMCwzLjQ2MSwxNy4wMzYsNTMuNzY0LDYuNjUzYzIyLjA0LTQuNTUyLDguNzc2LDEyLjc3NC0xMy41NzcsMjMuMTU1Yy0xOC4zNDUsOC41MTQtNTkuNDc0LDEwLjY5Ni02MC4xNDYtMS4wNjljLTEuNzI5LTMwLjM1NSwyMS42NDctMjEuMTMzLDE5Ljk2LTI4LjczOWMtMS41MjUtNi44NS0xMS45NzktMTMuNTczLTE4Ljg5NC0zMC4zMzggYy02LjAzNy0xNC42MzMtODIuNzk2LTEyNi44NDksMjEuMjg3LTExMC4xODNjMy44MTMtMC43ODktMjcuMTQ2LTk5LjAwMi0xMjQuNTUzLTEwMC41OTljLTk3LjM4NS0xLjU5Ny05NC4xOSwxMTkuNzYyLTk0LjE5LDExOS43NjIiIHN0eWxlPSJzdHJva2UtbGluZWpvaW46YmV2ZWwiLz4gPHBhdGggZD0iTTE4OC42MDQsMjc0LjMzNGMtMTMuNTc3LDE1LjE2Ni05LjU4NCwxNy44MjktMzYuNzIzLDIzLjQxN2MtMjcuNDU5LDUuNjYtMTEuMzI2LDE1LjczMy0wLjc5NywxOC4zNjVjMTIuNzY4LDMuMTk1LDQyLjMwNyw3LjcxOCw2Mi4yNjYtMjAuMjI5YzYuMDc4LTguNTA5LTAuMDM2LTIyLjA4Ni04LjM4NS0yNS41NDdjLTQuMDM0LTEuNjcxLTkuNDI4LTMuNzY1LTE2LjM2MSwzLjk5NHoiLz4gPHBhdGggZD0iTTE4Ny43MTUsMjc0LjA2OWMtMS4zNjgtOC45MTcsMi45My0xOS41MjgsNy41MzYtMzEuOTQyYzYuOTIyLTE4LjYyNiwyMi44OTMtMzcuMjU1LDEwLjExNy05Ni4zMzljLTkuNTIzLTQ0LjAyOS03My4zOTYtOS4xNjMtNzMuNDM2LTMuMTkzYy0wLjAzOSw1Ljk2OCwyLjg4OSwzMC4yNi0xLjA2Nyw1OC41NDhjLTUuMTYyLDM2LjkxMywyMy40ODgsNjguMTMyLDU2LjQ3OSw2NC45MzgiLz4gPHBhdGggZD0iTTE3Mi41MTcsMTQxLjdjLTAuMjg4LDIuMDM5LDMuNzMzLDcuNDgsOC45NzYsOC4yMDdjNS4yMzQsMC43Myw5LjcxNC0zLjUyMiw5Ljk5OC01LjU1OWMwLjI4NC0yLjAzOS0zLjczMi00LjI4NS04Ljk3Ny01LjAxNWMtNS4yMzctMC43MzEtOS43MTksMC4zMzMtOS45OTYsMi4zNjd6IiBzdHlsZT0iZmlsbDojRkZGRkZGO3N0cm9rZS13aWR0aDo0LjE1NTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNMzMxLjk0MSwxMzcuNTQzYzAuMjg0LDIuMDM5LTMuNzMyLDcuNDgtOC45NzYsOC4yMDdjLTUuMjM4LDAuNzMtOS43MTgtMy41MjItMTAuMDA1LTUuNTU5Yy0wLjI3Ny0yLjAzOSwzLjc0LTQuMjg1LDguOTc5LTUuMDE1YzUuMjM5LTAuNzMsOS43MTgsMC4zMzMsMTAuMDAyLDIuMzY4eiIgc3R5bGU9ImZpbGw6I0ZGRkZGRjtzdHJva2Utd2lkdGg6Mi4wNzc1O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyIi8+IDxwYXRoIGQ9Ik0zNTAuNjc2LDEyMy40MzJjMC44NjMsMTUuOTk0LTMuNDQ1LDI2Ljg4OC0zLjk4OCw0My45MTRjLTAuODA0LDI0Ljc0OCwxMS43OTksNTMuMDc0LTcuMTkxLDgxLjQzNSIvPiA8cGF0aCBkPSJNMCw2MC4yMzIiIHN0eWxlPSJzdHJva2Utd2lkdGg6MyIvPiA8L2c+PC9zdmc+Cjx0ZXh0IHg9IjcxMiIgeT0iMTAzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjEycHgiPk1hbmFnZWQgUG9zdGdyZVNRTDwvdGV4dD4KPHRleHQgeD0iNzEyIiB5PSIxMjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5Qb3N0Z3JlU1FMIGVuZ2luZTwvdGV4dD4KPHRleHQgeD0iMjAwIiB5PSIxNTgiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiIj5NQU5BR0VNRU5UIFJFUVVFU1RTIMK3IFZJQSBURU5TT1I5PC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTk2IiB4Mj0iMzAwIiB5Mj0iMTk2IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLW1hbmFnZWQtcG9zdGdyZXNxbCkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8dGV4dCB4PSIyMjciIHk9IjE4OCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjgiPlJEUyBBUEk8L3RleHQ+CjxyZWN0IHg9IjMwNCIgeT0iMTY0IiB3aWR0aD0iMTgwIiBoZWlnaHQ9IjY2IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjM5NCIgeT0iMTkxIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC1zaXplOjEycHgiPlRlbnNvcjk8L3RleHQ+CiAgPHRleHQgeD0iMzk0IiB5PSIyMDgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPnNlcnZpY2UgYWRhcHRlcjwvdGV4dD4KPGxpbmUgeDE9IjQ4NCIgeTE9IjE5NiIgeDI9IjYxMCIgeTI9IjE5NiIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoZC1tYW5hZ2VkLXBvc3RncmVzcWwpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHJlY3QgeD0iNjE0IiB5PSIxNjQiIHdpZHRoPSIxOTYiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iNzEyIiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTEuNXB4Ij5EaWdpdGFsT2NlYW4gZGF0YWJhc2UgQVBJPC90ZXh0Pgo8dGV4dCB4PSI3MTIiIHk9IjIxMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPnRoZSBiYWNrZW5kJ3MgbWFuYWdlbWVudCBBUEk8L3RleHQ+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 PostgreSQL version and extensions. DigitalOcean offers PgBouncer connection pools; check their transaction and session behavior against how your application uses RDS Proxy.

Connections use DigitalOcean database users, TLS and trusted-source rules.

#### Limitations

Where RDS and DigitalOcean Managed PostgreSQL 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.
* **Aurora shared storage, Serverless v2 scaling, fast clones and reader-promotion ranking are not supported.** DigitalOcean runs a primary database with separate read-only nodes, so these Aurora features have no direct equivalent.

#### 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.

##### Aurora PostgreSQL · Primary allocated compute

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Primary allocated compute. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: nyc; currency: USD.

![Aurora PostgreSQL · 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/a552329bfb4071d1bfe72d370f37391b97e7c40fbbe89055f86729ad223cf8f8-light.svg)

![Aurora PostgreSQL · 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/fa2a3fa5673858b7db8fda40d3221e9b0e9dad7536558793454cbff300627caf-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) | Aurora PostgreSQL | Target scenario | PostgreSQL | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | PostgreSQL (one copy) | 141.50 | 141.50 |
| 0 | 0.00 | PostgreSQL (two copies) | 283.00 | 283.00 |
| 1,460 | 211.70 | PostgreSQL (one copy) | 141.50 | -70.20 |
| 1,460 | 211.70 | PostgreSQL (two copies) | 283.00 | 71.30 |
| 2,920 | 423.40 | PostgreSQL (one copy) | 271.50 | -151.90 |
| 2,920 | 423.40 | PostgreSQL (two copies) | 543.00 | 119.60 |
| 5,840 | 846.80 | PostgreSQL (one copy) | 531.50 | -315.30 |
| 5,840 | 846.80 | PostgreSQL (two copies) | 1,063.00 | 216.20 |
| 11,680 | 1,693.60 | PostgreSQL (one copy) | 1,051.50 | -642.10 |
| 11,680 | 1,693.60 | PostgreSQL (two copies) | 2,103.00 | 409.40 |
| 23,360 | 3,387.20 | PostgreSQL (one copy) | 2,091.50 | -1,295.70 |
| 23,360 | 3,387.20 | PostgreSQL (two copies) | 4,183.00 | 795.80 |
| 46,720 | 6,774.40 | PostgreSQL (one copy) | Unpriced | Unavailable |
| 46,720 | 6,774.40 | PostgreSQL (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 |
| - | - | -: | - |
| PostgreSQL (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| PostgreSQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| PostgreSQL (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| PostgreSQL (one copy) | Origin list price · Database reads | 0 | USD/operations |
| PostgreSQL (one copy) | Origin list price · Database writes | 0 | USD/operations |
| PostgreSQL (one copy) | Target CPU / source CPU | 1 | multiplier |
| PostgreSQL (one copy) | Target RAM / source RAM | 1 | multiplier |
| PostgreSQL (one copy) | Target disk / source disk | 1 | multiplier |
| PostgreSQL (one copy) | Target price guess · read | 0 | USD/read |
| PostgreSQL (one copy) | Target price guess · write | 0 | USD/write |
| PostgreSQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL (one copy) | Target list price · GiB-month | 0.115 | USD/GiB-month |
| PostgreSQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL (one copy) | Target price guess · network GiB | 0 | USD/network GiB |
| PostgreSQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL (one copy) | Target list price · vCPU-hour | 0.0547945 | USD/vCPU-hour |
| PostgreSQL (one copy) | Target list price · GiB-hour | 0.00856164 | USD/GiB-hour |
| PostgreSQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL (one copy) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL (one copy) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL (one copy) | Target monthly base charge | 0 | USD/month |
| PostgreSQL (one copy) | Target service minimum | 135.75 | USD/month |
| PostgreSQL (one copy) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL (one copy) | Minimum primary RAM | 8 | GiB |
| PostgreSQL (one copy) | Minimum primary disk | 100 | GiB |
| PostgreSQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| PostgreSQL (one copy) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL (one copy) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL (one copy) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL (one copy) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| PostgreSQL (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| PostgreSQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| PostgreSQL (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| PostgreSQL (two copies) | Origin list price · Database reads | 0 | USD/operations |
| PostgreSQL (two copies) | Origin list price · Database writes | 0 | USD/operations |
| PostgreSQL (two copies) | Target CPU / source CPU | 1 | multiplier |
| PostgreSQL (two copies) | Target RAM / source RAM | 1 | multiplier |
| PostgreSQL (two copies) | Target disk / source disk | 1 | multiplier |
| PostgreSQL (two copies) | Target price guess · read | 0 | USD/read |
| PostgreSQL (two copies) | Target price guess · write | 0 | USD/write |
| PostgreSQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL (two copies) | Target list price · GiB-month | 0.115 | USD/GiB-month |
| PostgreSQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL (two copies) | Target price guess · network GiB | 0 | USD/network GiB |
| PostgreSQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL (two copies) | Target list price · vCPU-hour | 0.0547945 | USD/vCPU-hour |
| PostgreSQL (two copies) | Target list price · GiB-hour | 0.00856164 | USD/GiB-hour |
| PostgreSQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL (two copies) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL (two copies) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL (two copies) | Target monthly base charge | 0 | USD/month |
| PostgreSQL (two copies) | Target service minimum | 135.75 | USD/month |
| PostgreSQL (two copies) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL (two copies) | Minimum primary RAM | 8 | GiB |
| PostgreSQL (two copies) | Minimum primary disk | 100 | GiB |
| PostgreSQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| PostgreSQL (two copies) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL (two copies) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL (two copies) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL (two copies) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* DigitalOcean Managed PostgreSQL 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 ([https://docs.digitalocean.com/products/databases/postgresql/details/limits/](https://docs.digitalocean.com/products/databases/postgresql/details/limits/)) and storage reaches 30 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-ba4d39626bdb793bf67a00ea7cdd52f6cc0b7013` / `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/).

##### Aurora PostgreSQL · Stored data

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: nyc; currency: USD.

![Aurora PostgreSQL · 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/c007c3375e970209e1ef43e728ab901c897bc16982e1d9721beb6f6c7c85f32b-light.svg)

![Aurora PostgreSQL · 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/45222ae4eaf8a58a2b8685f54651a3034ad2007e9c1eb9039e91d6a8c71264f4-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) | Aurora PostgreSQL | Target scenario | PostgreSQL | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | PostgreSQL (one copy) | 141.50 | 141.50 |
| 0 | 0.00 | PostgreSQL (two copies) | 283.00 | 283.00 |
| 10 | 1.00 | PostgreSQL (one copy) | 141.50 | 140.50 |
| 10 | 1.00 | PostgreSQL (two copies) | 283.00 | 282.00 |
| 100 | 10.00 | PostgreSQL (one copy) | 147.25 | 137.25 |
| 100 | 10.00 | PostgreSQL (two copies) | 294.50 | 284.50 |
| 1,000 | 100.00 | PostgreSQL (one copy) | 276.63 | 176.63 |
| 1,000 | 100.00 | PostgreSQL (two copies) | 553.25 | 453.25 |
| 10,000 | 1,000.00 | PostgreSQL (one copy) | 1,570.38 | 570.38 |
| 10,000 | 1,000.00 | PostgreSQL (two copies) | 3,140.75 | 2,140.75 |
| 100,000 | 10,000.00 | PostgreSQL (one copy) | Unpriced | Unavailable |
| 100,000 | 10,000.00 | PostgreSQL (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 |
| - | - | -: | - |
| PostgreSQL (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| PostgreSQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| PostgreSQL (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| PostgreSQL (one copy) | Origin list price · Database reads | 0 | USD/operations |
| PostgreSQL (one copy) | Origin list price · Database writes | 0 | USD/operations |
| PostgreSQL (one copy) | Target CPU / source CPU | 1 | multiplier |
| PostgreSQL (one copy) | Target RAM / source RAM | 1 | multiplier |
| PostgreSQL (one copy) | Target disk / source disk | 1 | multiplier |
| PostgreSQL (one copy) | Target price guess · read | 0 | USD/read |
| PostgreSQL (one copy) | Target price guess · write | 0 | USD/write |
| PostgreSQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL (one copy) | Target list price · GiB-month | 0.115 | USD/GiB-month |
| PostgreSQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL (one copy) | Target price guess · network GiB | 0 | USD/network GiB |
| PostgreSQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL (one copy) | Target list price · vCPU-hour | 0.0547945 | USD/vCPU-hour |
| PostgreSQL (one copy) | Target list price · GiB-hour | 0.00856164 | USD/GiB-hour |
| PostgreSQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL (one copy) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL (one copy) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL (one copy) | Target monthly base charge | 0 | USD/month |
| PostgreSQL (one copy) | Target service minimum | 135.75 | USD/month |
| PostgreSQL (one copy) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL (one copy) | Minimum primary RAM | 8 | GiB |
| PostgreSQL (one copy) | Minimum primary disk | 100 | GiB |
| PostgreSQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| PostgreSQL (one copy) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL (one copy) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL (one copy) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL (one copy) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| PostgreSQL (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| PostgreSQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| PostgreSQL (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| PostgreSQL (two copies) | Origin list price · Database reads | 0 | USD/operations |
| PostgreSQL (two copies) | Origin list price · Database writes | 0 | USD/operations |
| PostgreSQL (two copies) | Target CPU / source CPU | 1 | multiplier |
| PostgreSQL (two copies) | Target RAM / source RAM | 1 | multiplier |
| PostgreSQL (two copies) | Target disk / source disk | 1 | multiplier |
| PostgreSQL (two copies) | Target price guess · read | 0 | USD/read |
| PostgreSQL (two copies) | Target price guess · write | 0 | USD/write |
| PostgreSQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL (two copies) | Target list price · GiB-month | 0.115 | USD/GiB-month |
| PostgreSQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL (two copies) | Target price guess · network GiB | 0 | USD/network GiB |
| PostgreSQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL (two copies) | Target list price · vCPU-hour | 0.0547945 | USD/vCPU-hour |
| PostgreSQL (two copies) | Target list price · GiB-hour | 0.00856164 | USD/GiB-hour |
| PostgreSQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL (two copies) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL (two copies) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL (two copies) | Target monthly base charge | 0 | USD/month |
| PostgreSQL (two copies) | Target service minimum | 135.75 | USD/month |
| PostgreSQL (two copies) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL (two copies) | Minimum primary RAM | 8 | GiB |
| PostgreSQL (two copies) | Minimum primary disk | 100 | GiB |
| PostgreSQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| PostgreSQL (two copies) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL (two copies) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL (two copies) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL (two copies) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* DigitalOcean Managed PostgreSQL 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 ([https://docs.digitalocean.com/products/databases/postgresql/details/limits/](https://docs.digitalocean.com/products/databases/postgresql/details/limits/)) and storage reaches 30 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-ba4d39626bdb793bf67a00ea7cdd52f6cc0b7013` / `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/).

##### Aurora PostgreSQL · Database writes

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Database writes. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: nyc; currency: USD.

![Aurora PostgreSQL · 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/42b38caa3298a28bf6860ae9a304f49d1bf85db2069d4b6710ef623fdd702374-light.svg)

![Aurora PostgreSQL · 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/cc8f874dd8ad59153eb9158b278721b90a311510b958b3770a54291a9e46c57c-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) | Aurora PostgreSQL | Target scenario | PostgreSQL | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | PostgreSQL (one copy) | 141.50 | 141.50 |
| 0 | 0.00 | PostgreSQL (two copies) | 283.00 | 283.00 |
| 1 | 0.00 | PostgreSQL (one copy) | 141.50 | 141.50 |
| 1 | 0.00 | PostgreSQL (two copies) | 283.00 | 283.00 |
| 10 | 0.00 | PostgreSQL (one copy) | 141.50 | 141.50 |
| 10 | 0.00 | PostgreSQL (two copies) | 283.00 | 283.00 |
| 100 | 0.00 | PostgreSQL (one copy) | 141.50 | 141.50 |
| 100 | 0.00 | PostgreSQL (two copies) | 283.00 | 283.00 |
| 1,000 | 0.00 | PostgreSQL (one copy) | 141.50 | 141.50 |
| 1,000 | 0.00 | PostgreSQL (two copies) | 283.00 | 283.00 |
| 10,000 | 0.00 | PostgreSQL (one copy) | 141.50 | 141.50 |
| 10,000 | 0.00 | PostgreSQL (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 |
| - | - | -: | - |
| PostgreSQL (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| PostgreSQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| PostgreSQL (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| PostgreSQL (one copy) | Origin list price · Database reads | 0 | USD/operations |
| PostgreSQL (one copy) | Origin list price · Database writes | 0 | USD/operations |
| PostgreSQL (one copy) | Target CPU / source CPU | 1 | multiplier |
| PostgreSQL (one copy) | Target RAM / source RAM | 1 | multiplier |
| PostgreSQL (one copy) | Target disk / source disk | 1 | multiplier |
| PostgreSQL (one copy) | Target price guess · read | 0 | USD/read |
| PostgreSQL (one copy) | Target price guess · write | 0 | USD/write |
| PostgreSQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL (one copy) | Target list price · GiB-month | 0.115 | USD/GiB-month |
| PostgreSQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL (one copy) | Target price guess · network GiB | 0 | USD/network GiB |
| PostgreSQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL (one copy) | Target list price · vCPU-hour | 0.0547945 | USD/vCPU-hour |
| PostgreSQL (one copy) | Target list price · GiB-hour | 0.00856164 | USD/GiB-hour |
| PostgreSQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL (one copy) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL (one copy) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL (one copy) | Target monthly base charge | 0 | USD/month |
| PostgreSQL (one copy) | Target service minimum | 135.75 | USD/month |
| PostgreSQL (one copy) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL (one copy) | Minimum primary RAM | 8 | GiB |
| PostgreSQL (one copy) | Minimum primary disk | 100 | GiB |
| PostgreSQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| PostgreSQL (one copy) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL (one copy) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL (one copy) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL (one copy) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| PostgreSQL (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| PostgreSQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| PostgreSQL (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| PostgreSQL (two copies) | Origin list price · Database reads | 0 | USD/operations |
| PostgreSQL (two copies) | Origin list price · Database writes | 0 | USD/operations |
| PostgreSQL (two copies) | Target CPU / source CPU | 1 | multiplier |
| PostgreSQL (two copies) | Target RAM / source RAM | 1 | multiplier |
| PostgreSQL (two copies) | Target disk / source disk | 1 | multiplier |
| PostgreSQL (two copies) | Target price guess · read | 0 | USD/read |
| PostgreSQL (two copies) | Target price guess · write | 0 | USD/write |
| PostgreSQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL (two copies) | Target list price · GiB-month | 0.115 | USD/GiB-month |
| PostgreSQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL (two copies) | Target price guess · network GiB | 0 | USD/network GiB |
| PostgreSQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL (two copies) | Target list price · vCPU-hour | 0.0547945 | USD/vCPU-hour |
| PostgreSQL (two copies) | Target list price · GiB-hour | 0.00856164 | USD/GiB-hour |
| PostgreSQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL (two copies) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL (two copies) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL (two copies) | Target monthly base charge | 0 | USD/month |
| PostgreSQL (two copies) | Target service minimum | 135.75 | USD/month |
| PostgreSQL (two copies) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL (two copies) | Minimum primary RAM | 8 | GiB |
| PostgreSQL (two copies) | Minimum primary disk | 100 | GiB |
| PostgreSQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| PostgreSQL (two copies) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL (two copies) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL (two copies) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL (two copies) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* DigitalOcean Managed PostgreSQL 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 ([https://docs.digitalocean.com/products/databases/postgresql/details/limits/](https://docs.digitalocean.com/products/databases/postgresql/details/limits/)) and storage reaches 30 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-ba4d39626bdb793bf67a00ea7cdd52f6cc0b7013` / `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/).

**Aurora PostgreSQL → PostgreSQL: 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.145 | USD/vCPU-hours |
| Origin list price · Primary memory | 0 | USD/GiB-hours |
| Origin list price · Primary provisioned storage | 0.1 | 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.

* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.

* DigitalOcean Managed PostgreSQL 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 ([https://docs.digitalocean.com/products/databases/postgresql/details/limits/](https://docs.digitalocean.com/products/databases/postgresql/details/limits/)) and storage reaches 30 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-ba4d39626bdb793bf67a00ea7cdd52f6cc0b7013` / `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 PostgreSQL

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| AWS/Aurora-proprietary SQL: aws\_s3.*, aws\_lambda.invoke, Aurora ML (aws\_sagemaker / aws\_comprehend), aurora\_* / apg\_plan\_mgmt | SQL functions | Out of scope | Full surface | AWS and Aurora extension functions with no counterpart on vanilla PostgreSQL; a query calling them fails |
| pgwire protocol (application SQL) | Wire protocol | Supported | Common | wire-compatible PostgreSQL; application SQL is unchanged |

#### How it works

Your application's PostgreSQL driver connects directly to Cloud SQL for PostgreSQL. These database requests are the **data plane**. The driver and the PostgreSQL wire protocol stay the same, and Tensor9 adds no proxy, translation or latency to your queries.

Management requests, such as snapshots, restores, replicas, failover and configuration changes, are the **control plane**. Tensor9 runs the RDS API in the customer's Cloud Adapter deployment and translates each of these requests to the backend's management API. The sections below list which operations work and which return an error.

![Database requests (SQL over pgwire) connect directly to Cloud SQL. The Tensor9 service adapter translates RDS API management calls to Cloud SQL admin API.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgcGd3aXJlKSBjb25uZWN0IGRpcmVjdGx5IHRvIENsb3VkIFNRTC4gVGhlIFRlbnNvcjkgc2VydmljZSBhZGFwdGVyIHRyYW5zbGF0ZXMgUkRTIEFQSSBtYW5hZ2VtZW50IGNhbGxzIHRvIENsb3VkIFNRTCBhZG1pbiBBUEkuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojMzM0MTU1fTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImFoZC1jbG91ZC1zcWwiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjciIG1hcmtlckhlaWdodD0iNyIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6Izk0YTNiOCIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iOCIgeT0iMzQiIHdpZHRoPSI4MjAiIGhlaWdodD0iMjA2IiByeD0iMTYiIHN0cm9rZS13aWR0aD0iMS40IiBzdHJva2UtZGFzaGFycmF5PSI1IDUiIHN0eWxlPSJmaWxsOiNmOGZhZmM7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iMjYiIHk9IjU0IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzk0YTNiODsgZmlsbDojMDQ3ODU3Ij5PTiBHT09HTEUgQ0xPVUQ8L3RleHQ+PHN2ZyB4PSI3OTIiIHk9IjM2IiB3aWR0aD0iMTYiIGhlaWdodD0iMTYiIHZpZXdCb3g9IjAgLTI1IDI1NiAyNTYiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiPjxnPiA8cGF0aCBkPSJNMTcwLjI1MTcsNTYuODE4NiBMMTkyLjUwNDcsMzQuNTY1NiBMMTkzLjk4NzcsMjUuMTk1NiBDMTUzLjQzNjcsLTExLjY3NzQgODguOTc1NywtNy40OTY0IDUyLjQyMDcsMzMuOTE5NiBDNDIuMjY2Nyw0NS40MjI2IDM0LjczMzcsNTkuNzYzNiAzMC43MTY3LDc0LjU3MjYgTDM4LjY4NjcsNzMuNDQ5NiBMODMuMTkxNyw2Ni4xMTA2IEw4Ni42Mjc3LDYyLjU5NjYgQzEwNi40MjQ3LDQwLjg1NDYgMTM5Ljg5NzcsMzcuOTI5NiAxNjIuNzU1Nyw1Ni40Mjg2IEwxNzAuMjUxNyw1Ni44MTg2IFoiIGZpbGw9IiNFQTQzMzUiPiA8L3BhdGg+IDxwYXRoIGQ9Ik0yMjQuMjA0OCw3My45MTgyIEMyMTkuMDg5OCw1NS4wODIyIDIwOC41ODg4LDM4LjE0OTIgMTkzLjk4NzgsMjUuMTk2MiBMMTYyLjc1NTgsNTYuNDI4MiBDMTc1Ljk0MzgsNjcuMjA0MiAxODMuNDU2OCw4My40MzgyIDE4My4xMzQ4LDEwMC40NjUyIEwxODMuMTM0OCwxMDYuMDA5MiBDMTk4LjQ4NTgsMTA2LjAwOTIgMjEwLjkzMTgsMTE4LjQ1NDIgMjEwLjkzMTgsMTMzLjgwNTIgQzIxMC45MzE4LDE0OS4xNTcyIDE5OC40ODU4LDE2MS4yOTAyIDE4My4xMzQ4LDE2MS4yOTAyIEwxMjcuNDYzOCwxNjEuMjkwMiBMMTIxLjk5NzgsMTY3LjIyNDIgTDEyMS45OTc4LDIwMC41NjQyIEwxMjcuNDYzOCwyMDUuNzk1MiBMMTgzLjEzNDgsMjA1Ljc5NTIgQzIyMy4wNjQ4LDIwNi4xMDYyIDI1NS42ODY4LDE3NC4zMDEyIDI1NS45OTc4LDEzNC4zNzEyIEMyNTYuMTg1OCwxMTAuMTY4MiAyNDQuMjUyOCw4Ny40NzgyIDIyNC4yMDQ4LDczLjkxODIiIGZpbGw9IiM0Mjg1RjQiPiA8L3BhdGg+IDxwYXRoIGQ9Ik03MS44NzA0LDIwNS43OTU3IEwxMjcuNDYzNCwyMDUuNzk1NyBMMTI3LjQ2MzQsMTYxLjI4OTcgTDcxLjg3MDQsMTYxLjI4OTcgQzY3LjkwOTQsMTYxLjI4ODcgNjQuMDczNCwxNjAuNDM3NyA2MC40NzE0LDE1OC43OTE3IEw1Mi41ODQ0LDE2MS4yMTE3IEwzMC4xNzU0LDE4My40NjQ3IEwyOC4yMjM0LDE5MS4wMzg3IEM0MC43OTA0LDIwMC41Mjc3IDU2LjEyMzQsMjA1Ljg2MzcgNzEuODcwNCwyMDUuNzk1NyIgZmlsbD0iIzM0QTg1MyI+IDwvcGF0aD4gPHBhdGggZD0iTTcxLjg3MDQsNjEuNDI1NSBDMzEuOTM5NCw2MS42NjM1IC0wLjIzNjYsOTQuMjI3NSAwLjAwMTQsMTM0LjE1NzUgQzAuMTM0NCwxNTYuNDU1NSAxMC41NDg0LDE3Ny40NDU1IDI4LjIyMzQsMTkxLjAzODUgTDYwLjQ3MTQsMTU4Ljc5MTUgQzQ2LjQ4MDQsMTUyLjQ3MDUgNDAuMjYzNCwxMzYuMDA1NSA0Ni41ODQ0LDEyMi4wMTU1IEM1Mi45MDQ0LDEwOC4wMjU1IDY5LjM3MDQsMTAxLjgwODUgODMuMzU5NCwxMDguMTI4NSBDODkuNTI0NCwxMTAuOTEzNSA5NC40NjE0LDExNS44NTE1IDk3LjI0NjQsMTIyLjAxNTUgTDEyOS40OTQ0LDg5Ljc2ODUgQzExNS43NzM0LDcxLjgzMTUgOTQuNDUzNCw2MS4zNDQ1IDcxLjg3MDQsNjEuNDI1NSIgZmlsbD0iI0ZCQkMwNSI+IDwvcGF0aD4gPC9nPjwvc3ZnPgo8cmVjdCB4PSIyNiIgeT0iODgiIHdpZHRoPSIxMjgiIGhlaWdodD0iMTEyIiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjkwIiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTNweCI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIxNDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5Qb3N0Z3JlU1FMIGRyaXZlcjwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjE2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij51bmNoYW5nZWQ8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iODIiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4OyBmaWxsOiMwNDc4NTciPkRBVEFCQVNFIFJFUVVFU1RTIMK3IERJUkVDVCBDT05ORUNUSU9OPC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTA4IiB4Mj0iNjEwIiB5Mj0iMTA4IiBzdHJva2Utd2lkdGg9IjIuMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtY2xvdWQtc3FsKSIgc3R5bGU9InN0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjM4MiIgeT0iMTAwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YjsgZmlsbDojMDQ3ODU3Ij5TUUwgb3ZlciBwZ3dpcmU8L3RleHQ+CjxyZWN0IHg9IjYxNCIgeT0iNzYiIHdpZHRoPSIxOTYiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz48c3ZnIHg9Ijc4NiIgeT0iNTYiIHdpZHRoPSIyMCIgaGVpZ2h0PSIyMCIgdmlld0JveD0iMCAwIDQzMi4wNzEgNDQ1LjM4MyIgcHJlc2VydmVBc3BlY3RSYXRpbz0ieE1pZFlNaWQgbWVldCI+PGcgc3R5bGU9ImZpbGwtcnVsZTpub256ZXJvO2NsaXAtcnVsZTpub256ZXJvO3N0cm9rZTojMDAwMDAwO3N0cm9rZS1taXRlcmxpbWl0OjQiPiA8L2c+IDxnIHN0eWxlPSJmaWxsLXJ1bGU6bm9uemVybztjbGlwLXJ1bGU6bm9uemVybztmaWxsOm5vbmU7c3Ryb2tlOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjEyLjQ2NTE7c3Ryb2tlLWxpbmVjYXA6cm91bmQ7c3Ryb2tlLWxpbmVqb2luOnJvdW5kO3N0cm9rZS1taXRlcmxpbWl0OjQiPiA8cGF0aCBkPSJNMzIzLjIwNSwzMjQuMjI3YzIuODMzLTIzLjYwMSwxLjk4NC0yNy4wNjIsMTkuNTYzLTIzLjIzOWw0LjQ2MywwLjM5MmMxMy41MTcsMC42MTUsMzEuMTk5LTIuMTc0LDQxLjU4Ny03YzIyLjM2Mi0xMC4zNzYsMzUuNjIyLTI3LjcsMTMuNTcyLTIzLjE0OGMtNTAuMjk3LDEwLjM3Ni01My43NTUtNi42NTUtNTMuNzU1LTYuNjU1YzUzLjExMS03OC44MDMsNzUuMzEzLTE3OC44MzYsNTYuMTQ5LTIwMy4zMjIgQzM1Mi41MTQtNS41MzQsMjYyLjAzNiwyNi4wNDksMjYwLjUyMiwyNi44NjlsLTAuNDgyLDAuMDg5Yy05LjkzOC0yLjA2Mi0yMS4wNi0zLjI5NC0zMy41NTQtMy40OTZjLTIyLjc2MS0wLjM3NC00MC4wMzIsNS45NjctNTMuMTMzLDE1LjkwNGMwLDAtMTYxLjQwOC02Ni40OTgtMTUzLjg5OSw4My42MjhjMS41OTcsMzEuOTM2LDQ1Ljc3NywyNDEuNjU1LDk4LjQ3LDE3OC4zMSBjMTkuMjU5LTIzLjE2MywzNy44NzEtNDIuNzQ4LDM3Ljg3MS00Mi43NDhjOS4yNDIsNi4xNCwyMC4zMDcsOS4yNzIsMzEuOTEyLDguMTQ3bDAuODk3LTAuNzY1Yy0wLjI4MSwyLjg3Ni0wLjE1Nyw1LjY4OSwwLjM1OSw5LjAxOWMtMTMuNTcyLDE1LjE2Ny05LjU4NCwxNy44My0zNi43MjMsMjMuNDE2Yy0yNy40NTcsNS42NTktMTEuMzI2LDE1LjczNC0wLjc5NywxOC4zNjdjMTIuNzY4LDMuMTkzLDQyLjMwNSw3LjcxNiw2Mi4yNjgtMjAuMjI0IGwtMC43OTUsMy4xODhjNS4zMjUsNC4yNiw0Ljk2NSwzMC42MTksNS43Miw0OS40NTJjMC43NTYsMTguODM0LDIuMDE3LDM2LjQwOSw1Ljg1Niw0Ni43NzFjMy44MzksMTAuMzYsOC4zNjksMzcuMDUsNDQuMDM2LDI5LjQwNmMyOS44MDktNi4zODgsNTIuNi0xNS41ODIsNTQuNjc3LTEwMS4xMDciIHN0eWxlPSJmaWxsOiMwMDAwMDA7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjM3LjM5NTM7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTQwMi4zOTUsMjcxLjIzYy01MC4zMDIsMTAuMzc2LTUzLjc2LTYuNjU1LTUzLjc2LTYuNjU1YzUzLjExMS03OC44MDgsNzUuMzEzLTE3OC44NDMsNTYuMTUzLTIwMy4zMjZjLTUyLjI3LTY2Ljc4NS0xNDIuNzUyLTM1LjItMTQ0LjI2Mi0zNC4zOGwtMC40ODYsMC4wODdjLTkuOTM4LTIuMDYzLTIxLjA2LTMuMjkyLTMzLjU2LTMuNDk2Yy0yMi43NjEtMC4zNzMtNDAuMDI2LDUuOTY3LTUzLjEyNywxNS45MDIgYzAsMC0xNjEuNDExLTY2LjQ5NS0xNTMuOTA0LDgzLjYzYzEuNTk3LDMxLjkzOCw0NS43NzYsMjQxLjY1Nyw5OC40NzEsMTc4LjMxMmMxOS4yNi0yMy4xNjMsMzcuODY5LTQyLjc0OCwzNy44NjktNDIuNzQ4YzkuMjQzLDYuMTQsMjAuMzA4LDkuMjcyLDMxLjkwOCw4LjE0N2wwLjkwMS0wLjc2NWMtMC4yOCwyLjg3Ni0wLjE1Miw1LjY4OSwwLjM2MSw5LjAxOWMtMTMuNTc1LDE1LjE2Ny05LjU4NiwxNy44My0zNi43MjMsMjMuNDE2IGMtMjcuNDU5LDUuNjU5LTExLjMyOCwxNS43MzQtMC43OTYsMTguMzY3YzEyLjc2OCwzLjE5Myw0Mi4zMDcsNy43MTYsNjIuMjY2LTIwLjIyNGwtMC43OTYsMy4xODhjNS4zMTksNC4yNiw5LjA1NCwyNy43MTEsOC40MjgsNDguOTY5Yy0wLjYyNiwyMS4yNTktMS4wNDQsMzUuODU0LDMuMTQ3LDQ3LjI1NGM0LjE5MSwxMS40LDguMzY4LDM3LjA1LDQ0LjA0MiwyOS40MDZjMjkuODA5LTYuMzg4LDQ1LjI1Ni0yMi45NDIsNDcuNDA1LTUwLjU1NSBjMS41MjUtMTkuNjMxLDQuOTc2LTE2LjcyOSw1LjE5NC0zNC4yOGwyLjc2OC04LjMwOWMzLjE5Mi0yNi42MTEsMC41MDctMzUuMTk2LDE4Ljg3Mi0zMS4yMDNsNC40NjMsMC4zOTJjMTMuNTE3LDAuNjE1LDMxLjIwOC0yLjE3NCw0MS41OTEtN2MyMi4zNTgtMTAuMzc2LDM1LjYxOC0yNy43LDEzLjU3My0yMy4xNDh6IiBzdHlsZT0iZmlsbDojMzM2NzkxO3N0cm9rZTpub25lIi8+IDxwYXRoIGQ9Ik0yMTUuODY2LDI4Ni40ODRjLTEuMzg1LDQ5LjUxNiwwLjM0OCw5OS4zNzcsNS4xOTMsMTExLjQ5NWM0Ljg0OCwxMi4xMTgsMTUuMjIzLDM1LjY4OCw1MC45LDI4LjA0NWMyOS44MDYtNi4zOSw0MC42NTEtMTguNzU2LDQ1LjM1Ny00Ni4wNTFjMy40NjYtMjAuMDgyLDEwLjE0OC03NS44NTQsMTEuMDA1LTg3LjI4MSIvPiA8cGF0aCBkPSJNMTczLjEwNCwzOC4yNTZjMCwwLTE2MS41MjEtNjYuMDE2LTE1NC4wMTIsODQuMTA5YzEuNTk3LDMxLjkzOCw0NS43NzksMjQxLjY2NCw5OC40NzMsMTc4LjMxNmMxOS4yNTYtMjMuMTY2LDM2LjY3MS00MS4zMzUsMzYuNjcxLTQxLjMzNSIvPiA8cGF0aCBkPSJNMjYwLjM0OSwyNi4yMDdjLTUuNTkxLDEuNzUzLDg5Ljg0OC0zNC44ODksMTQ0LjA4NywzNC40MTdjMTkuMTU5LDI0LjQ4NC0zLjA0MywxMjQuNTE5LTU2LjE1MywyMDMuMzI5Ii8+IDxwYXRoIGQ9Ik0zNDguMjgyLDI2My45NTNjMCwwLDMuNDYxLDE3LjAzNiw1My43NjQsNi42NTNjMjIuMDQtNC41NTIsOC43NzYsMTIuNzc0LTEzLjU3NywyMy4xNTVjLTE4LjM0NSw4LjUxNC01OS40NzQsMTAuNjk2LTYwLjE0Ni0xLjA2OWMtMS43MjktMzAuMzU1LDIxLjY0Ny0yMS4xMzMsMTkuOTYtMjguNzM5Yy0xLjUyNS02Ljg1LTExLjk3OS0xMy41NzMtMTguODk0LTMwLjMzOCBjLTYuMDM3LTE0LjYzMy04Mi43OTYtMTI2Ljg0OSwyMS4yODctMTEwLjE4M2MzLjgxMy0wLjc4OS0yNy4xNDYtOTkuMDAyLTEyNC41NTMtMTAwLjU5OWMtOTcuMzg1LTEuNTk3LTk0LjE5LDExOS43NjItOTQuMTksMTE5Ljc2MiIgc3R5bGU9InN0cm9rZS1saW5lam9pbjpiZXZlbCIvPiA8cGF0aCBkPSJNMTg4LjYwNCwyNzQuMzM0Yy0xMy41NzcsMTUuMTY2LTkuNTg0LDE3LjgyOS0zNi43MjMsMjMuNDE3Yy0yNy40NTksNS42Ni0xMS4zMjYsMTUuNzMzLTAuNzk3LDE4LjM2NWMxMi43NjgsMy4xOTUsNDIuMzA3LDcuNzE4LDYyLjI2Ni0yMC4yMjljNi4wNzgtOC41MDktMC4wMzYtMjIuMDg2LTguMzg1LTI1LjU0N2MtNC4wMzQtMS42NzEtOS40MjgtMy43NjUtMTYuMzYxLDMuOTk0eiIvPiA8cGF0aCBkPSJNMTg3LjcxNSwyNzQuMDY5Yy0xLjM2OC04LjkxNywyLjkzLTE5LjUyOCw3LjUzNi0zMS45NDJjNi45MjItMTguNjI2LDIyLjg5My0zNy4yNTUsMTAuMTE3LTk2LjMzOWMtOS41MjMtNDQuMDI5LTczLjM5Ni05LjE2My03My40MzYtMy4xOTNjLTAuMDM5LDUuOTY4LDIuODg5LDMwLjI2LTEuMDY3LDU4LjU0OGMtNS4xNjIsMzYuOTEzLDIzLjQ4OCw2OC4xMzIsNTYuNDc5LDY0LjkzOCIvPiA8cGF0aCBkPSJNMTcyLjUxNywxNDEuN2MtMC4yODgsMi4wMzksMy43MzMsNy40OCw4Ljk3Niw4LjIwN2M1LjIzNCwwLjczLDkuNzE0LTMuNTIyLDkuOTk4LTUuNTU5YzAuMjg0LTIuMDM5LTMuNzMyLTQuMjg1LTguOTc3LTUuMDE1Yy01LjIzNy0wLjczMS05LjcxOSwwLjMzMy05Ljk5NiwyLjM2N3oiIHN0eWxlPSJmaWxsOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjQuMTU1O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyIi8+IDxwYXRoIGQ9Ik0zMzEuOTQxLDEzNy41NDNjMC4yODQsMi4wMzktMy43MzIsNy40OC04Ljk3Niw4LjIwN2MtNS4yMzgsMC43My05LjcxOC0zLjUyMi0xMC4wMDUtNS41NTljLTAuMjc3LTIuMDM5LDMuNzQtNC4yODUsOC45NzktNS4wMTVjNS4yMzktMC43Myw5LjcxOCwwLjMzMywxMC4wMDIsMi4zNjh6IiBzdHlsZT0iZmlsbDojRkZGRkZGO3N0cm9rZS13aWR0aDoyLjA3NzU7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTM1MC42NzYsMTIzLjQzMmMwLjg2MywxNS45OTQtMy40NDUsMjYuODg4LTMuOTg4LDQzLjkxNGMtMC44MDQsMjQuNzQ4LDExLjc5OSw1My4wNzQtNy4xOTEsODEuNDM1Ii8+IDxwYXRoIGQ9Ik0wLDYwLjIzMiIgc3R5bGU9InN0cm9rZS13aWR0aDozIi8+IDwvZz48L3N2Zz4KPHRleHQgeD0iNzEyIiB5PSIxMDMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTJweCI+Q2xvdWQgU1FMPC90ZXh0Pgo8dGV4dCB4PSI3MTIiIHk9IjEyMiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPlBvc3RncmVTUUwgZW5naW5lPC90ZXh0Pgo8dGV4dCB4PSIyMDAiIHk9IjE1OCIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjgiPk1BTkFHRU1FTlQgUkVRVUVTVFMgwrcgVklBIFRFTlNPUjk8L3RleHQ+CjxsaW5lIHgxPSIxNTQiIHkxPSIxOTYiIHgyPSIzMDAiIHkyPSIxOTYiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtY2xvdWQtc3FsKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjIyNyIgeT0iMTg4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YiI+UkRTIEFQSTwvdGV4dD4KPHJlY3QgeD0iMzA0IiB5PSIxNjQiIHdpZHRoPSIxODAiIGhlaWdodD0iNjYiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iMzk0IiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSIzOTQiIHk9IjIwOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+c2VydmljZSBhZGFwdGVyPC90ZXh0Pgo8bGluZSB4MT0iNDg0IiB5MT0iMTk2IiB4Mj0iNjEwIiB5Mj0iMTk2IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLWNsb3VkLXNxbCkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8cmVjdCB4PSI2MTQiIHk9IjE2NCIgd2lkdGg9IjE5NiIgaGVpZ2h0PSI2NCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSI3MTIiIHk9IjE5MSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMS41cHgiPkNsb3VkIFNRTCBhZG1pbiBBUEk8L3RleHQ+Cjx0ZXh0IHg9IjcxMiIgeT0iMjEwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+dGhlIGJhY2tlbmQncyBtYW5hZ2VtZW50IEFQSTwvdGV4dD4KPC9zdmc+)

![Database requests (SQL over pgwire) connect directly to Cloud SQL. The Tensor9 service adapter translates RDS API management calls to Cloud SQL admin API.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgcGd3aXJlKSBjb25uZWN0IGRpcmVjdGx5IHRvIENsb3VkIFNRTC4gVGhlIFRlbnNvcjkgc2VydmljZSBhZGFwdGVyIHRyYW5zbGF0ZXMgUkRTIEFQSSBtYW5hZ2VtZW50IGNhbGxzIHRvIENsb3VkIFNRTCBhZG1pbiBBUEkuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojY2JkNWUxfTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImFoZC1jbG91ZC1zcWwiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjciIG1hcmtlckhlaWdodD0iNyIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6IzY0NzQ4YiIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iOCIgeT0iMzQiIHdpZHRoPSI4MjAiIGhlaWdodD0iMjA2IiByeD0iMTYiIHN0cm9rZS13aWR0aD0iMS40IiBzdHJva2UtZGFzaGFycmF5PSI1IDUiIHN0eWxlPSJmaWxsOiMwZjE3MmE7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iMjYiIHk9IjU0IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzY0NzQ4YjsgZmlsbDojNmVlN2I3Ij5PTiBHT09HTEUgQ0xPVUQ8L3RleHQ+PHN2ZyB4PSI3OTIiIHk9IjM2IiB3aWR0aD0iMTYiIGhlaWdodD0iMTYiIHZpZXdCb3g9IjAgLTI1IDI1NiAyNTYiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiPjxnPiA8cGF0aCBkPSJNMTcwLjI1MTcsNTYuODE4NiBMMTkyLjUwNDcsMzQuNTY1NiBMMTkzLjk4NzcsMjUuMTk1NiBDMTUzLjQzNjcsLTExLjY3NzQgODguOTc1NywtNy40OTY0IDUyLjQyMDcsMzMuOTE5NiBDNDIuMjY2Nyw0NS40MjI2IDM0LjczMzcsNTkuNzYzNiAzMC43MTY3LDc0LjU3MjYgTDM4LjY4NjcsNzMuNDQ5NiBMODMuMTkxNyw2Ni4xMTA2IEw4Ni42Mjc3LDYyLjU5NjYgQzEwNi40MjQ3LDQwLjg1NDYgMTM5Ljg5NzcsMzcuOTI5NiAxNjIuNzU1Nyw1Ni40Mjg2IEwxNzAuMjUxNyw1Ni44MTg2IFoiIGZpbGw9IiNFQTQzMzUiPiA8L3BhdGg+IDxwYXRoIGQ9Ik0yMjQuMjA0OCw3My45MTgyIEMyMTkuMDg5OCw1NS4wODIyIDIwOC41ODg4LDM4LjE0OTIgMTkzLjk4NzgsMjUuMTk2MiBMMTYyLjc1NTgsNTYuNDI4MiBDMTc1Ljk0MzgsNjcuMjA0MiAxODMuNDU2OCw4My40MzgyIDE4My4xMzQ4LDEwMC40NjUyIEwxODMuMTM0OCwxMDYuMDA5MiBDMTk4LjQ4NTgsMTA2LjAwOTIgMjEwLjkzMTgsMTE4LjQ1NDIgMjEwLjkzMTgsMTMzLjgwNTIgQzIxMC45MzE4LDE0OS4xNTcyIDE5OC40ODU4LDE2MS4yOTAyIDE4My4xMzQ4LDE2MS4yOTAyIEwxMjcuNDYzOCwxNjEuMjkwMiBMMTIxLjk5NzgsMTY3LjIyNDIgTDEyMS45OTc4LDIwMC41NjQyIEwxMjcuNDYzOCwyMDUuNzk1MiBMMTgzLjEzNDgsMjA1Ljc5NTIgQzIyMy4wNjQ4LDIwNi4xMDYyIDI1NS42ODY4LDE3NC4zMDEyIDI1NS45OTc4LDEzNC4zNzEyIEMyNTYuMTg1OCwxMTAuMTY4MiAyNDQuMjUyOCw4Ny40NzgyIDIyNC4yMDQ4LDczLjkxODIiIGZpbGw9IiM0Mjg1RjQiPiA8L3BhdGg+IDxwYXRoIGQ9Ik03MS44NzA0LDIwNS43OTU3IEwxMjcuNDYzNCwyMDUuNzk1NyBMMTI3LjQ2MzQsMTYxLjI4OTcgTDcxLjg3MDQsMTYxLjI4OTcgQzY3LjkwOTQsMTYxLjI4ODcgNjQuMDczNCwxNjAuNDM3NyA2MC40NzE0LDE1OC43OTE3IEw1Mi41ODQ0LDE2MS4yMTE3IEwzMC4xNzU0LDE4My40NjQ3IEwyOC4yMjM0LDE5MS4wMzg3IEM0MC43OTA0LDIwMC41Mjc3IDU2LjEyMzQsMjA1Ljg2MzcgNzEuODcwNCwyMDUuNzk1NyIgZmlsbD0iIzM0QTg1MyI+IDwvcGF0aD4gPHBhdGggZD0iTTcxLjg3MDQsNjEuNDI1NSBDMzEuOTM5NCw2MS42NjM1IC0wLjIzNjYsOTQuMjI3NSAwLjAwMTQsMTM0LjE1NzUgQzAuMTM0NCwxNTYuNDU1NSAxMC41NDg0LDE3Ny40NDU1IDI4LjIyMzQsMTkxLjAzODUgTDYwLjQ3MTQsMTU4Ljc5MTUgQzQ2LjQ4MDQsMTUyLjQ3MDUgNDAuMjYzNCwxMzYuMDA1NSA0Ni41ODQ0LDEyMi4wMTU1IEM1Mi45MDQ0LDEwOC4wMjU1IDY5LjM3MDQsMTAxLjgwODUgODMuMzU5NCwxMDguMTI4NSBDODkuNTI0NCwxMTAuOTEzNSA5NC40NjE0LDExNS44NTE1IDk3LjI0NjQsMTIyLjAxNTUgTDEyOS40OTQ0LDg5Ljc2ODUgQzExNS43NzM0LDcxLjgzMTUgOTQuNDUzNCw2MS4zNDQ1IDcxLjg3MDQsNjEuNDI1NSIgZmlsbD0iI0ZCQkMwNSI+IDwvcGF0aD4gPC9nPjwvc3ZnPgo8cmVjdCB4PSIyNiIgeT0iODgiIHdpZHRoPSIxMjgiIGhlaWdodD0iMTEyIiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjkwIiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTNweCI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIxNDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5Qb3N0Z3JlU1FMIGRyaXZlcjwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjE2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij51bmNoYW5nZWQ8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iODIiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiM2ZWU3YjciPkRBVEFCQVNFIFJFUVVFU1RTIMK3IERJUkVDVCBDT05ORUNUSU9OPC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTA4IiB4Mj0iNjEwIiB5Mj0iMTA4IiBzdHJva2Utd2lkdGg9IjIuMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtY2xvdWQtc3FsKSIgc3R5bGU9InN0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjM4MiIgeT0iMTAwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiODsgZmlsbDojNmVlN2I3Ij5TUUwgb3ZlciBwZ3dpcmU8L3RleHQ+CjxyZWN0IHg9IjYxNCIgeT0iNzYiIHdpZHRoPSIxOTYiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz48c3ZnIHg9Ijc4NiIgeT0iNTYiIHdpZHRoPSIyMCIgaGVpZ2h0PSIyMCIgdmlld0JveD0iMCAwIDQzMi4wNzEgNDQ1LjM4MyIgcHJlc2VydmVBc3BlY3RSYXRpbz0ieE1pZFlNaWQgbWVldCI+PGcgc3R5bGU9ImZpbGwtcnVsZTpub256ZXJvO2NsaXAtcnVsZTpub256ZXJvO3N0cm9rZTojMDAwMDAwO3N0cm9rZS1taXRlcmxpbWl0OjQiPiA8L2c+IDxnIHN0eWxlPSJmaWxsLXJ1bGU6bm9uemVybztjbGlwLXJ1bGU6bm9uemVybztmaWxsOm5vbmU7c3Ryb2tlOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjEyLjQ2NTE7c3Ryb2tlLWxpbmVjYXA6cm91bmQ7c3Ryb2tlLWxpbmVqb2luOnJvdW5kO3N0cm9rZS1taXRlcmxpbWl0OjQiPiA8cGF0aCBkPSJNMzIzLjIwNSwzMjQuMjI3YzIuODMzLTIzLjYwMSwxLjk4NC0yNy4wNjIsMTkuNTYzLTIzLjIzOWw0LjQ2MywwLjM5MmMxMy41MTcsMC42MTUsMzEuMTk5LTIuMTc0LDQxLjU4Ny03YzIyLjM2Mi0xMC4zNzYsMzUuNjIyLTI3LjcsMTMuNTcyLTIzLjE0OGMtNTAuMjk3LDEwLjM3Ni01My43NTUtNi42NTUtNTMuNzU1LTYuNjU1YzUzLjExMS03OC44MDMsNzUuMzEzLTE3OC44MzYsNTYuMTQ5LTIwMy4zMjIgQzM1Mi41MTQtNS41MzQsMjYyLjAzNiwyNi4wNDksMjYwLjUyMiwyNi44NjlsLTAuNDgyLDAuMDg5Yy05LjkzOC0yLjA2Mi0yMS4wNi0zLjI5NC0zMy41NTQtMy40OTZjLTIyLjc2MS0wLjM3NC00MC4wMzIsNS45NjctNTMuMTMzLDE1LjkwNGMwLDAtMTYxLjQwOC02Ni40OTgtMTUzLjg5OSw4My42MjhjMS41OTcsMzEuOTM2LDQ1Ljc3NywyNDEuNjU1LDk4LjQ3LDE3OC4zMSBjMTkuMjU5LTIzLjE2MywzNy44NzEtNDIuNzQ4LDM3Ljg3MS00Mi43NDhjOS4yNDIsNi4xNCwyMC4zMDcsOS4yNzIsMzEuOTEyLDguMTQ3bDAuODk3LTAuNzY1Yy0wLjI4MSwyLjg3Ni0wLjE1Nyw1LjY4OSwwLjM1OSw5LjAxOWMtMTMuNTcyLDE1LjE2Ny05LjU4NCwxNy44My0zNi43MjMsMjMuNDE2Yy0yNy40NTcsNS42NTktMTEuMzI2LDE1LjczNC0wLjc5NywxOC4zNjdjMTIuNzY4LDMuMTkzLDQyLjMwNSw3LjcxNiw2Mi4yNjgtMjAuMjI0IGwtMC43OTUsMy4xODhjNS4zMjUsNC4yNiw0Ljk2NSwzMC42MTksNS43Miw0OS40NTJjMC43NTYsMTguODM0LDIuMDE3LDM2LjQwOSw1Ljg1Niw0Ni43NzFjMy44MzksMTAuMzYsOC4zNjksMzcuMDUsNDQuMDM2LDI5LjQwNmMyOS44MDktNi4zODgsNTIuNi0xNS41ODIsNTQuNjc3LTEwMS4xMDciIHN0eWxlPSJmaWxsOiMwMDAwMDA7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjM3LjM5NTM7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTQwMi4zOTUsMjcxLjIzYy01MC4zMDIsMTAuMzc2LTUzLjc2LTYuNjU1LTUzLjc2LTYuNjU1YzUzLjExMS03OC44MDgsNzUuMzEzLTE3OC44NDMsNTYuMTUzLTIwMy4zMjZjLTUyLjI3LTY2Ljc4NS0xNDIuNzUyLTM1LjItMTQ0LjI2Mi0zNC4zOGwtMC40ODYsMC4wODdjLTkuOTM4LTIuMDYzLTIxLjA2LTMuMjkyLTMzLjU2LTMuNDk2Yy0yMi43NjEtMC4zNzMtNDAuMDI2LDUuOTY3LTUzLjEyNywxNS45MDIgYzAsMC0xNjEuNDExLTY2LjQ5NS0xNTMuOTA0LDgzLjYzYzEuNTk3LDMxLjkzOCw0NS43NzYsMjQxLjY1Nyw5OC40NzEsMTc4LjMxMmMxOS4yNi0yMy4xNjMsMzcuODY5LTQyLjc0OCwzNy44NjktNDIuNzQ4YzkuMjQzLDYuMTQsMjAuMzA4LDkuMjcyLDMxLjkwOCw4LjE0N2wwLjkwMS0wLjc2NWMtMC4yOCwyLjg3Ni0wLjE1Miw1LjY4OSwwLjM2MSw5LjAxOWMtMTMuNTc1LDE1LjE2Ny05LjU4NiwxNy44My0zNi43MjMsMjMuNDE2IGMtMjcuNDU5LDUuNjU5LTExLjMyOCwxNS43MzQtMC43OTYsMTguMzY3YzEyLjc2OCwzLjE5Myw0Mi4zMDcsNy43MTYsNjIuMjY2LTIwLjIyNGwtMC43OTYsMy4xODhjNS4zMTksNC4yNiw5LjA1NCwyNy43MTEsOC40MjgsNDguOTY5Yy0wLjYyNiwyMS4yNTktMS4wNDQsMzUuODU0LDMuMTQ3LDQ3LjI1NGM0LjE5MSwxMS40LDguMzY4LDM3LjA1LDQ0LjA0MiwyOS40MDZjMjkuODA5LTYuMzg4LDQ1LjI1Ni0yMi45NDIsNDcuNDA1LTUwLjU1NSBjMS41MjUtMTkuNjMxLDQuOTc2LTE2LjcyOSw1LjE5NC0zNC4yOGwyLjc2OC04LjMwOWMzLjE5Mi0yNi42MTEsMC41MDctMzUuMTk2LDE4Ljg3Mi0zMS4yMDNsNC40NjMsMC4zOTJjMTMuNTE3LDAuNjE1LDMxLjIwOC0yLjE3NCw0MS41OTEtN2MyMi4zNTgtMTAuMzc2LDM1LjYxOC0yNy43LDEzLjU3My0yMy4xNDh6IiBzdHlsZT0iZmlsbDojMzM2NzkxO3N0cm9rZTpub25lIi8+IDxwYXRoIGQ9Ik0yMTUuODY2LDI4Ni40ODRjLTEuMzg1LDQ5LjUxNiwwLjM0OCw5OS4zNzcsNS4xOTMsMTExLjQ5NWM0Ljg0OCwxMi4xMTgsMTUuMjIzLDM1LjY4OCw1MC45LDI4LjA0NWMyOS44MDYtNi4zOSw0MC42NTEtMTguNzU2LDQ1LjM1Ny00Ni4wNTFjMy40NjYtMjAuMDgyLDEwLjE0OC03NS44NTQsMTEuMDA1LTg3LjI4MSIvPiA8cGF0aCBkPSJNMTczLjEwNCwzOC4yNTZjMCwwLTE2MS41MjEtNjYuMDE2LTE1NC4wMTIsODQuMTA5YzEuNTk3LDMxLjkzOCw0NS43NzksMjQxLjY2NCw5OC40NzMsMTc4LjMxNmMxOS4yNTYtMjMuMTY2LDM2LjY3MS00MS4zMzUsMzYuNjcxLTQxLjMzNSIvPiA8cGF0aCBkPSJNMjYwLjM0OSwyNi4yMDdjLTUuNTkxLDEuNzUzLDg5Ljg0OC0zNC44ODksMTQ0LjA4NywzNC40MTdjMTkuMTU5LDI0LjQ4NC0zLjA0MywxMjQuNTE5LTU2LjE1MywyMDMuMzI5Ii8+IDxwYXRoIGQ9Ik0zNDguMjgyLDI2My45NTNjMCwwLDMuNDYxLDE3LjAzNiw1My43NjQsNi42NTNjMjIuMDQtNC41NTIsOC43NzYsMTIuNzc0LTEzLjU3NywyMy4xNTVjLTE4LjM0NSw4LjUxNC01OS40NzQsMTAuNjk2LTYwLjE0Ni0xLjA2OWMtMS43MjktMzAuMzU1LDIxLjY0Ny0yMS4xMzMsMTkuOTYtMjguNzM5Yy0xLjUyNS02Ljg1LTExLjk3OS0xMy41NzMtMTguODk0LTMwLjMzOCBjLTYuMDM3LTE0LjYzMy04Mi43OTYtMTI2Ljg0OSwyMS4yODctMTEwLjE4M2MzLjgxMy0wLjc4OS0yNy4xNDYtOTkuMDAyLTEyNC41NTMtMTAwLjU5OWMtOTcuMzg1LTEuNTk3LTk0LjE5LDExOS43NjItOTQuMTksMTE5Ljc2MiIgc3R5bGU9InN0cm9rZS1saW5lam9pbjpiZXZlbCIvPiA8cGF0aCBkPSJNMTg4LjYwNCwyNzQuMzM0Yy0xMy41NzcsMTUuMTY2LTkuNTg0LDE3LjgyOS0zNi43MjMsMjMuNDE3Yy0yNy40NTksNS42Ni0xMS4zMjYsMTUuNzMzLTAuNzk3LDE4LjM2NWMxMi43NjgsMy4xOTUsNDIuMzA3LDcuNzE4LDYyLjI2Ni0yMC4yMjljNi4wNzgtOC41MDktMC4wMzYtMjIuMDg2LTguMzg1LTI1LjU0N2MtNC4wMzQtMS42NzEtOS40MjgtMy43NjUtMTYuMzYxLDMuOTk0eiIvPiA8cGF0aCBkPSJNMTg3LjcxNSwyNzQuMDY5Yy0xLjM2OC04LjkxNywyLjkzLTE5LjUyOCw3LjUzNi0zMS45NDJjNi45MjItMTguNjI2LDIyLjg5My0zNy4yNTUsMTAuMTE3LTk2LjMzOWMtOS41MjMtNDQuMDI5LTczLjM5Ni05LjE2My03My40MzYtMy4xOTNjLTAuMDM5LDUuOTY4LDIuODg5LDMwLjI2LTEuMDY3LDU4LjU0OGMtNS4xNjIsMzYuOTEzLDIzLjQ4OCw2OC4xMzIsNTYuNDc5LDY0LjkzOCIvPiA8cGF0aCBkPSJNMTcyLjUxNywxNDEuN2MtMC4yODgsMi4wMzksMy43MzMsNy40OCw4Ljk3Niw4LjIwN2M1LjIzNCwwLjczLDkuNzE0LTMuNTIyLDkuOTk4LTUuNTU5YzAuMjg0LTIuMDM5LTMuNzMyLTQuMjg1LTguOTc3LTUuMDE1Yy01LjIzNy0wLjczMS05LjcxOSwwLjMzMy05Ljk5NiwyLjM2N3oiIHN0eWxlPSJmaWxsOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjQuMTU1O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyIi8+IDxwYXRoIGQ9Ik0zMzEuOTQxLDEzNy41NDNjMC4yODQsMi4wMzktMy43MzIsNy40OC04Ljk3Niw4LjIwN2MtNS4yMzgsMC43My05LjcxOC0zLjUyMi0xMC4wMDUtNS41NTljLTAuMjc3LTIuMDM5LDMuNzQtNC4yODUsOC45NzktNS4wMTVjNS4yMzktMC43Myw5LjcxOCwwLjMzMywxMC4wMDIsMi4zNjh6IiBzdHlsZT0iZmlsbDojRkZGRkZGO3N0cm9rZS13aWR0aDoyLjA3NzU7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTM1MC42NzYsMTIzLjQzMmMwLjg2MywxNS45OTQtMy40NDUsMjYuODg4LTMuOTg4LDQzLjkxNGMtMC44MDQsMjQuNzQ4LDExLjc5OSw1My4wNzQtNy4xOTEsODEuNDM1Ii8+IDxwYXRoIGQ9Ik0wLDYwLjIzMiIgc3R5bGU9InN0cm9rZS13aWR0aDozIi8+IDwvZz48L3N2Zz4KPHRleHQgeD0iNzEyIiB5PSIxMDMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTJweCI+Q2xvdWQgU1FMPC90ZXh0Pgo8dGV4dCB4PSI3MTIiIHk9IjEyMiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPlBvc3RncmVTUUwgZW5naW5lPC90ZXh0Pgo8dGV4dCB4PSIyMDAiIHk9IjE1OCIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGIiPk1BTkFHRU1FTlQgUkVRVUVTVFMgwrcgVklBIFRFTlNPUjk8L3RleHQ+CjxsaW5lIHgxPSIxNTQiIHkxPSIxOTYiIHgyPSIzMDAiIHkyPSIxOTYiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtY2xvdWQtc3FsKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjIyNyIgeT0iMTg4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiOCI+UkRTIEFQSTwvdGV4dD4KPHJlY3QgeD0iMzA0IiB5PSIxNjQiIHdpZHRoPSIxODAiIGhlaWdodD0iNjYiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iMzk0IiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSIzOTQiIHk9IjIwOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+c2VydmljZSBhZGFwdGVyPC90ZXh0Pgo8bGluZSB4MT0iNDg0IiB5MT0iMTk2IiB4Mj0iNjEwIiB5Mj0iMTk2IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLWNsb3VkLXNxbCkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8cmVjdCB4PSI2MTQiIHk9IjE2NCIgd2lkdGg9IjE5NiIgaGVpZ2h0PSI2NCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSI3MTIiIHk9IjE5MSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMS41cHgiPkNsb3VkIFNRTCBhZG1pbiBBUEk8L3RleHQ+Cjx0ZXh0IHg9IjcxMiIgeT0iMjEwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+dGhlIGJhY2tlbmQncyBtYW5hZ2VtZW50IEFQSTwvdGV4dD4KPC9zdmc+)

Queries reach the database directly; only the management calls are translated.

#### Database connections

Aurora stores data in an AWS-specific storage layer, but your application reaches it over the standard PostgreSQL wire protocol, which Cloud SQL for PostgreSQL also supports. Your SQL, drivers, object-relational mappers (ORMs), prepared statements, data types and transaction behavior stay the same; only the storage underneath changes.

AWS and Aurora add SQL functions for moving data through S3, invoking Lambda and machine learning. These functions do not exist on the backend, so a query that calls them returns an error.

#### Database management

At runtime your application and tools keep making the same RDS calls: describe the cluster, take a snapshot, restore to a point in time, add a reader, trigger a failover, stop and start, change the instance class or a parameter. For each supported operation, the adapter accepts the RDS request, returns the RDS response format, and performs the operation on Cloud SQL: on-demand backups and restores, point-in-time restore, read replicas, manual failover, stop / start, and machine-type, storage and database-flag updates.

The adapter also runs the Aurora Data API (SQL over HTTPS, transactions included), executing each statement over a native connection to the backend database. The adapter also handles Aurora's global database. Cloud SQL has no global-cluster object, so Tensor9 keeps the global cluster itself and maps its members and role changes onto Cloud SQL's cross-region read replicas. The backend's managed promote handles planned switchover and unplanned failover.

With Max, your tools call `CreateDBCluster` and `CreateDBInstance` through the RDS adapter to create a logical Aurora cluster and its members on Cloud SQL. Tensor9 keeps a durable record of the logical cluster and its members and reconciles the Cloud SQL resources with it: it records each accepted request, then creates or removes the Cloud SQL resources in the background. `DescribeDBClusters` and `DescribeDBInstances` report status and endpoints. `DeleteDBInstance` removes members; `DeleteDBCluster` removes the cluster once its members are gone. Your application's SQL connection still goes directly to the database. With the Infrastructure-only option, Tensor9 compiles the declared cluster into Cloud SQL resources, which you manage with Google's own tools; runtime RDS API calls require Max.

![The Tensor9 service adapter handles RDS management requests using Cloud SQL admin API and returns RDS responses.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTk2IiB2aWV3Qm94PSIwIDAgODM2IDE5NiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgaGFuZGxlcyBSRFMgbWFuYWdlbWVudCByZXF1ZXN0cyB1c2luZyBDbG91ZCBTUUwgYWRtaW4gQVBJIGFuZCByZXR1cm5zIFJEUyByZXNwb25zZXMuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojMzM0MTU1fTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImFoYy1yZHMtY2xvdWQtc3FsLWFkbWluLWFwaSIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNyIgbWFya2VySGVpZ2h0PSI3IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+PHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBzdHlsZT0iZmlsbDojOTRhM2I4Ii8+PC9tYXJrZXI+PC9kZWZzPgo8cmVjdCB4PSIxNiIgeT0iMzQiIHdpZHRoPSIyMzYiIGhlaWdodD0iMTI4IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjEzNCIgeT0iNjAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTIuNXB4Ij5SRFMgbWFuYWdlbWVudCBjYWxsPC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9IjgyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+c25hcHNob3QgwrcgcG9pbnQtaW4tdGltZSByZXN0b3JlPC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9Ijk5IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+cmVhZGVyIMK3IGZhaWxvdmVyIMK3IGdsb2JhbCBkYXRhYmFzZTwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSIxMTYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5EYXRhIEFQSSDCtyBwYXJhbWV0ZXJzPC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9IjE0MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGIiPnNhbWUgcmVxdWVzdCAvIHJlc3BvbnNlIHNoYXBlczwvdGV4dD4KPGxpbmUgeDE9IjI1MiIgeTE9Ijc0IiB4Mj0iMzE0IiB5Mj0iNzQiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWNsb3VkLXNxbC1hZG1pbi1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPGxpbmUgeDE9IjMxOCIgeTE9IjEyOCIgeDI9IjI1NiIgeTI9IjEyOCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtY2xvdWQtc3FsLWFkbWluLWFwaSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8cmVjdCB4PSIzMTgiIHk9IjU0IiB3aWR0aD0iMjA0IiBoZWlnaHQ9Ijg4IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjQyMCIgeT0iOTQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSI0MjAiIHk9IjExMiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+c2VydmljZSBhZGFwdGVyPC90ZXh0Pgo8bGluZSB4MT0iNTIyIiB5MT0iNzQiIHgyPSI1ODQiIHkyPSI3NCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtY2xvdWQtc3FsLWFkbWluLWFwaSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8bGluZSB4MT0iNTg4IiB5MT0iMTI4IiB4Mj0iNTI2IiB5Mj0iMTI4IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhjLXJkcy1jbG91ZC1zcWwtYWRtaW4tYXBpKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxyZWN0IHg9IjU4OCIgeT0iMzQiIHdpZHRoPSIyMzIiIGhlaWdodD0iMTI4IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjcwNCIgeT0iNjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTJweCI+Q2xvdWQgU1FMIGFkbWluIEFQSTwvdGV4dD4KPHRleHQgeD0iNzA0IiB5PSI5NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPmJhY2t1cHMgwrcgcmVzdG9yZXMgwrcgcmVwbGljYXM8L3RleHQ+Cjx0ZXh0IHg9IjcwNCIgeT0iMTExIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+ZmFpbG92ZXIgwrcgdXBkYXRlcyDCtyBmbGFnczwvdGV4dD4KPC9zdmc+)

![The Tensor9 service adapter handles RDS management requests using Cloud SQL admin API and returns RDS responses.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTk2IiB2aWV3Qm94PSIwIDAgODM2IDE5NiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgaGFuZGxlcyBSRFMgbWFuYWdlbWVudCByZXF1ZXN0cyB1c2luZyBDbG91ZCBTUUwgYWRtaW4gQVBJIGFuZCByZXR1cm5zIFJEUyByZXNwb25zZXMuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojY2JkNWUxfTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImFoYy1yZHMtY2xvdWQtc3FsLWFkbWluLWFwaSIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNyIgbWFya2VySGVpZ2h0PSI3IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+PHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBzdHlsZT0iZmlsbDojNjQ3NDhiIi8+PC9tYXJrZXI+PC9kZWZzPgo8cmVjdCB4PSIxNiIgeT0iMzQiIHdpZHRoPSIyMzYiIGhlaWdodD0iMTI4IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjEzNCIgeT0iNjAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTIuNXB4Ij5SRFMgbWFuYWdlbWVudCBjYWxsPC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9IjgyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+c25hcHNob3QgwrcgcG9pbnQtaW4tdGltZSByZXN0b3JlPC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9Ijk5IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+cmVhZGVyIMK3IGZhaWxvdmVyIMK3IGdsb2JhbCBkYXRhYmFzZTwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSIxMTYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5EYXRhIEFQSSDCtyBwYXJhbWV0ZXJzPC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9IjE0MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjgiPnNhbWUgcmVxdWVzdCAvIHJlc3BvbnNlIHNoYXBlczwvdGV4dD4KPGxpbmUgeDE9IjI1MiIgeTE9Ijc0IiB4Mj0iMzE0IiB5Mj0iNzQiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWNsb3VkLXNxbC1hZG1pbi1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPGxpbmUgeDE9IjMxOCIgeTE9IjEyOCIgeDI9IjI1NiIgeTI9IjEyOCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtY2xvdWQtc3FsLWFkbWluLWFwaSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8cmVjdCB4PSIzMTgiIHk9IjU0IiB3aWR0aD0iMjA0IiBoZWlnaHQ9Ijg4IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjQyMCIgeT0iOTQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSI0MjAiIHk9IjExMiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+c2VydmljZSBhZGFwdGVyPC90ZXh0Pgo8bGluZSB4MT0iNTIyIiB5MT0iNzQiIHgyPSI1ODQiIHkyPSI3NCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtY2xvdWQtc3FsLWFkbWluLWFwaSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8bGluZSB4MT0iNTg4IiB5MT0iMTI4IiB4Mj0iNTI2IiB5Mj0iMTI4IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhjLXJkcy1jbG91ZC1zcWwtYWRtaW4tYXBpKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxyZWN0IHg9IjU4OCIgeT0iMzQiIHdpZHRoPSIyMzIiIGhlaWdodD0iMTI4IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjcwNCIgeT0iNjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTJweCI+Q2xvdWQgU1FMIGFkbWluIEFQSTwvdGV4dD4KPHRleHQgeD0iNzA0IiB5PSI5NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPmJhY2t1cHMgwrcgcmVzdG9yZXMgwrcgcmVwbGljYXM8L3RleHQ+Cjx0ZXh0IHg9IjcwNCIgeT0iMTExIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+ZmFpbG92ZXIgwrcgdXBkYXRlcyDCtyBmbGFnczwvdGV4dD4KPC9zdmc+)

Tensor9 translates RDS management requests to the backend API and returns RDS responses.

#### Limitations

Where Aurora and Cloud SQL differ

* **Aurora-specific settings are not supported.** Failover priority / promotion tiers, Serverless v2 autoscaling, global write forwarding and I/O-Optimized storage have no Cloud SQL equivalent.
* **Event subscriptions are not supported.** RDS event notifications publish to SNS. Cloud Monitoring works differently and has no direct equivalent.
* **Parameter groups behave differently: Tensor9 keeps the group and applies its settings as flags.** Tensor9 keeps named parameter groups and their overrides. Supported explicit PostgreSQL parameters become Cloud SQL database flags; the group object itself stays with Tensor9 and is not created on Cloud SQL. The group family must match the PostgreSQL version, and Cloud SQL's limits on allowed values and restarts still apply. RDS-specific parameters and settings outside the backend's settable list are rejected.

#### Other considerations

**Migration.** Moving the data is a one-time step, covered by this page's migration note: a logical dump and restore, or logical replication for a short cutover. This page describes how things work after cutover.

**Operations.** The customer owns the Cloud SQL service in their Google Cloud project. Maintenance windows, quotas and pricing are Google's.

**Features and capacity.** The comparison table on this page lists feature and high-availability differences. Check the backend's pricing and capacity limits when you size the deployment.

#### 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.

##### Aurora PostgreSQL · Primary allocated compute

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Primary allocated compute. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Aurora PostgreSQL · 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/151f25fda3f7ba7364b0cdf310ccea20c78089a941b8cacfa03f56eb13d9c1fd-light.svg)

![Aurora PostgreSQL · 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/6820c719b5dabd6951bff175d29bcddb9d3f87037b5a2ac7cd6892b0206e769f-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) | Aurora PostgreSQL | Target scenario | Cloud SQL for PostgreSQL | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Cloud SQL for PostgreSQL (one copy) | 118.18 | 118.18 |
| 0 | 0.00 | Cloud SQL for PostgreSQL (two copies) | 236.36 | 236.36 |
| 1,460 | 211.70 | Cloud SQL for PostgreSQL (one copy) | 118.18 | -93.52 |
| 1,460 | 211.70 | Cloud SQL for PostgreSQL (two copies) | 236.36 | 24.66 |
| 2,920 | 423.40 | Cloud SQL for PostgreSQL (one copy) | 219.36 | -204.04 |
| 2,920 | 423.40 | Cloud SQL for PostgreSQL (two copies) | 438.71 | 15.31 |
| 5,840 | 846.80 | Cloud SQL for PostgreSQL (one copy) | 421.71 | -425.09 |
| 5,840 | 846.80 | Cloud SQL for PostgreSQL (two copies) | 843.42 | -3.38 |
| 11,680 | 1,693.60 | Cloud SQL for PostgreSQL (one copy) | 826.42 | -867.18 |
| 11,680 | 1,693.60 | Cloud SQL for PostgreSQL (two copies) | 1,652.85 | -40.75 |
| 23,360 | 3,387.20 | Cloud SQL for PostgreSQL (one copy) | 1,635.85 | -1,751.35 |
| 23,360 | 3,387.20 | Cloud SQL for PostgreSQL (two copies) | 3,271.70 | -115.50 |
| 46,720 | 6,774.40 | Cloud SQL for PostgreSQL (one copy) | 3,254.70 | -3,519.70 |
| 46,720 | 6,774.40 | Cloud SQL for PostgreSQL (two copies) | 6,509.39 | -265.01 |

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 PostgreSQL (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| Cloud SQL for PostgreSQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| Cloud SQL for PostgreSQL (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Origin list price · Database reads | 0 | USD/operations |
| Cloud SQL for PostgreSQL (one copy) | Origin list price · Database writes | 0 | USD/operations |
| Cloud SQL for PostgreSQL (one copy) | Target CPU / source CPU | 1 | multiplier |
| Cloud SQL for PostgreSQL (one copy) | Target RAM / source RAM | 1 | multiplier |
| Cloud SQL for PostgreSQL (one copy) | Target disk / source disk | 1 | multiplier |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · read | 0 | USD/read |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · write | 0 | USD/write |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| Cloud SQL for PostgreSQL (one copy) | Target list price · GiB-month | 0.17 | USD/GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Cloud SQL for PostgreSQL (one copy) | Target list price · network GiB | 0.19 | USD/network GiB |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour |
| Cloud SQL for PostgreSQL (one copy) | Target list price · GiB-hour | 0.007 | USD/GiB-hour |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · input token | 0 | USD/input token |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · output token | 0 | USD/output token |
| Cloud SQL for PostgreSQL (one copy) | Target monthly base charge | 0 | USD/month |
| Cloud SQL for PostgreSQL (one copy) | Target service minimum | 9.365 | USD/month |
| Cloud SQL for PostgreSQL (one copy) | Minimum primary CPU | 2 | vCPU |
| Cloud SQL for PostgreSQL (one copy) | Minimum primary RAM | 8 | GiB |
| Cloud SQL for PostgreSQL (one copy) | Minimum primary disk | 100 | GiB |
| Cloud SQL for PostgreSQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Cloud SQL for PostgreSQL (one copy) | Allocated share of provisioned cost | 1 | fraction |
| Cloud SQL for PostgreSQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Cloud SQL for PostgreSQL (one copy) | Planning peak / mean work | 2 | multiplier |
| Cloud SQL for PostgreSQL (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| Cloud SQL for PostgreSQL (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| Cloud SQL for PostgreSQL (one copy) | Planning disk utilization | 0.8 | fraction |
| Cloud SQL for PostgreSQL (one copy) | Maintenance and log disk reserve | 20 | GiB |
| Cloud SQL for PostgreSQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Cloud SQL for PostgreSQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Cloud SQL for PostgreSQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Cloud SQL for PostgreSQL (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| Cloud SQL for PostgreSQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| Cloud SQL for PostgreSQL (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| Cloud SQL for PostgreSQL (two copies) | Origin list price · Database reads | 0 | USD/operations |
| Cloud SQL for PostgreSQL (two copies) | Origin list price · Database writes | 0 | USD/operations |
| Cloud SQL for PostgreSQL (two copies) | Target CPU / source CPU | 1 | multiplier |
| Cloud SQL for PostgreSQL (two copies) | Target RAM / source RAM | 1 | multiplier |
| Cloud SQL for PostgreSQL (two copies) | Target disk / source disk | 1 | multiplier |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · read | 0 | USD/read |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · write | 0 | USD/write |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| Cloud SQL for PostgreSQL (two copies) | Target list price · GiB-month | 0.17 | USD/GiB-month |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Cloud SQL for PostgreSQL (two copies) | Target list price · network GiB | 0.19 | USD/network GiB |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Cloud SQL for PostgreSQL (two copies) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour |
| Cloud SQL for PostgreSQL (two copies) | Target list price · GiB-hour | 0.007 | USD/GiB-hour |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · input token | 0 | USD/input token |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · output token | 0 | USD/output token |
| Cloud SQL for PostgreSQL (two copies) | Target monthly base charge | 0 | USD/month |
| Cloud SQL for PostgreSQL (two copies) | Target service minimum | 9.365 | USD/month |
| Cloud SQL for PostgreSQL (two copies) | Minimum primary CPU | 2 | vCPU |
| Cloud SQL for PostgreSQL (two copies) | Minimum primary RAM | 8 | GiB |
| Cloud SQL for PostgreSQL (two copies) | Minimum primary disk | 100 | GiB |
| Cloud SQL for PostgreSQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Cloud SQL for PostgreSQL (two copies) | Allocated share of provisioned cost | 1 | fraction |
| Cloud SQL for PostgreSQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Cloud SQL for PostgreSQL (two copies) | Planning peak / mean work | 2 | multiplier |
| Cloud SQL for PostgreSQL (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| Cloud SQL for PostgreSQL (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| Cloud SQL for PostgreSQL (two copies) | Planning disk utilization | 0.8 | fraction |
| Cloud SQL for PostgreSQL (two copies) | Maintenance and log disk reserve | 20 | GiB |
| Cloud SQL for PostgreSQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Cloud SQL for PostgreSQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Cloud SQL for PostgreSQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Cloud SQL for PostgreSQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Cloud SQL for PostgreSQL (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* Cloud SQL Enterprise edition (PostgreSQL) 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-42ce840602ccc44a14430c68c1039d2af3889c41` / `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).

##### Aurora PostgreSQL · Stored data

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Aurora PostgreSQL · 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/9fcef9ee08edd8ce75c53a5b5b8562dc18df7b967672348232096736a6793612-light.svg)

![Aurora PostgreSQL · 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/faa530de9573224655bde3a06f3a882ce7de2c3fae413a261ae146284e91ab5f-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) | Aurora PostgreSQL | Target scenario | Cloud SQL for PostgreSQL | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Cloud SQL for PostgreSQL (one copy) | 118.18 | 118.18 |
| 0 | 0.00 | Cloud SQL for PostgreSQL (two copies) | 236.36 | 236.36 |
| 10 | 1.00 | Cloud SQL for PostgreSQL (one copy) | 118.18 | 117.18 |
| 10 | 1.00 | Cloud SQL for PostgreSQL (two copies) | 236.36 | 235.36 |
| 100 | 10.00 | Cloud SQL for PostgreSQL (one copy) | 126.68 | 116.68 |
| 100 | 10.00 | Cloud SQL for PostgreSQL (two copies) | 253.36 | 243.36 |
| 1,000 | 100.00 | Cloud SQL for PostgreSQL (one copy) | 317.93 | 217.93 |
| 1,000 | 100.00 | Cloud SQL for PostgreSQL (two copies) | 635.86 | 535.86 |
| 10,000 | 1,000.00 | Cloud SQL for PostgreSQL (one copy) | 2,230.43 | 1,230.43 |
| 10,000 | 1,000.00 | Cloud SQL for PostgreSQL (two copies) | 4,460.86 | 3,460.86 |
| 100,000 | 10,000.00 | Cloud SQL for PostgreSQL (one copy) | Unpriced | Unavailable |
| 100,000 | 10,000.00 | Cloud SQL for PostgreSQL (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 PostgreSQL (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| Cloud SQL for PostgreSQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| Cloud SQL for PostgreSQL (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Origin list price · Database reads | 0 | USD/operations |
| Cloud SQL for PostgreSQL (one copy) | Origin list price · Database writes | 0 | USD/operations |
| Cloud SQL for PostgreSQL (one copy) | Target CPU / source CPU | 1 | multiplier |
| Cloud SQL for PostgreSQL (one copy) | Target RAM / source RAM | 1 | multiplier |
| Cloud SQL for PostgreSQL (one copy) | Target disk / source disk | 1 | multiplier |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · read | 0 | USD/read |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · write | 0 | USD/write |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| Cloud SQL for PostgreSQL (one copy) | Target list price · GiB-month | 0.17 | USD/GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Cloud SQL for PostgreSQL (one copy) | Target list price · network GiB | 0.19 | USD/network GiB |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour |
| Cloud SQL for PostgreSQL (one copy) | Target list price · GiB-hour | 0.007 | USD/GiB-hour |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · input token | 0 | USD/input token |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · output token | 0 | USD/output token |
| Cloud SQL for PostgreSQL (one copy) | Target monthly base charge | 0 | USD/month |
| Cloud SQL for PostgreSQL (one copy) | Target service minimum | 9.365 | USD/month |
| Cloud SQL for PostgreSQL (one copy) | Minimum primary CPU | 2 | vCPU |
| Cloud SQL for PostgreSQL (one copy) | Minimum primary RAM | 8 | GiB |
| Cloud SQL for PostgreSQL (one copy) | Minimum primary disk | 100 | GiB |
| Cloud SQL for PostgreSQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Cloud SQL for PostgreSQL (one copy) | Allocated share of provisioned cost | 1 | fraction |
| Cloud SQL for PostgreSQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Cloud SQL for PostgreSQL (one copy) | Planning peak / mean work | 2 | multiplier |
| Cloud SQL for PostgreSQL (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| Cloud SQL for PostgreSQL (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| Cloud SQL for PostgreSQL (one copy) | Planning disk utilization | 0.8 | fraction |
| Cloud SQL for PostgreSQL (one copy) | Maintenance and log disk reserve | 20 | GiB |
| Cloud SQL for PostgreSQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Cloud SQL for PostgreSQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Cloud SQL for PostgreSQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Cloud SQL for PostgreSQL (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| Cloud SQL for PostgreSQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| Cloud SQL for PostgreSQL (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| Cloud SQL for PostgreSQL (two copies) | Origin list price · Database reads | 0 | USD/operations |
| Cloud SQL for PostgreSQL (two copies) | Origin list price · Database writes | 0 | USD/operations |
| Cloud SQL for PostgreSQL (two copies) | Target CPU / source CPU | 1 | multiplier |
| Cloud SQL for PostgreSQL (two copies) | Target RAM / source RAM | 1 | multiplier |
| Cloud SQL for PostgreSQL (two copies) | Target disk / source disk | 1 | multiplier |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · read | 0 | USD/read |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · write | 0 | USD/write |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| Cloud SQL for PostgreSQL (two copies) | Target list price · GiB-month | 0.17 | USD/GiB-month |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Cloud SQL for PostgreSQL (two copies) | Target list price · network GiB | 0.19 | USD/network GiB |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Cloud SQL for PostgreSQL (two copies) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour |
| Cloud SQL for PostgreSQL (two copies) | Target list price · GiB-hour | 0.007 | USD/GiB-hour |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · input token | 0 | USD/input token |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · output token | 0 | USD/output token |
| Cloud SQL for PostgreSQL (two copies) | Target monthly base charge | 0 | USD/month |
| Cloud SQL for PostgreSQL (two copies) | Target service minimum | 9.365 | USD/month |
| Cloud SQL for PostgreSQL (two copies) | Minimum primary CPU | 2 | vCPU |
| Cloud SQL for PostgreSQL (two copies) | Minimum primary RAM | 8 | GiB |
| Cloud SQL for PostgreSQL (two copies) | Minimum primary disk | 100 | GiB |
| Cloud SQL for PostgreSQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Cloud SQL for PostgreSQL (two copies) | Allocated share of provisioned cost | 1 | fraction |
| Cloud SQL for PostgreSQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Cloud SQL for PostgreSQL (two copies) | Planning peak / mean work | 2 | multiplier |
| Cloud SQL for PostgreSQL (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| Cloud SQL for PostgreSQL (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| Cloud SQL for PostgreSQL (two copies) | Planning disk utilization | 0.8 | fraction |
| Cloud SQL for PostgreSQL (two copies) | Maintenance and log disk reserve | 20 | GiB |
| Cloud SQL for PostgreSQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Cloud SQL for PostgreSQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Cloud SQL for PostgreSQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Cloud SQL for PostgreSQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Cloud SQL for PostgreSQL (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* Cloud SQL Enterprise edition (PostgreSQL) 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-42ce840602ccc44a14430c68c1039d2af3889c41` / `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).

##### Aurora PostgreSQL · Database writes

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Database writes. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Aurora PostgreSQL · 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/64576cdb0952b86e443f2df367ff26adcb4ebc2ea8da9fb0c5c2b18ccd258bb5-light.svg)

![Aurora PostgreSQL · 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/fee110c446fa40fed77e23e503ad142eda7e2ccfc2371c530323e57ae51be7c2-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) | Aurora PostgreSQL | Target scenario | Cloud SQL for PostgreSQL | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Cloud SQL for PostgreSQL (one copy) | 118.18 | 118.18 |
| 0 | 0.00 | Cloud SQL for PostgreSQL (two copies) | 236.36 | 236.36 |
| 1 | 0.00 | Cloud SQL for PostgreSQL (one copy) | 118.18 | 118.18 |
| 1 | 0.00 | Cloud SQL for PostgreSQL (two copies) | 236.36 | 236.36 |
| 10 | 0.00 | Cloud SQL for PostgreSQL (one copy) | 118.18 | 118.18 |
| 10 | 0.00 | Cloud SQL for PostgreSQL (two copies) | 236.36 | 236.36 |
| 100 | 0.00 | Cloud SQL for PostgreSQL (one copy) | 118.18 | 118.18 |
| 100 | 0.00 | Cloud SQL for PostgreSQL (two copies) | 236.36 | 236.36 |
| 1,000 | 0.00 | Cloud SQL for PostgreSQL (one copy) | 118.18 | 118.18 |
| 1,000 | 0.00 | Cloud SQL for PostgreSQL (two copies) | 236.36 | 236.36 |
| 10,000 | 0.00 | Cloud SQL for PostgreSQL (one copy) | 118.18 | 118.18 |
| 10,000 | 0.00 | Cloud SQL for PostgreSQL (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 PostgreSQL (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| Cloud SQL for PostgreSQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| Cloud SQL for PostgreSQL (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Origin list price · Database reads | 0 | USD/operations |
| Cloud SQL for PostgreSQL (one copy) | Origin list price · Database writes | 0 | USD/operations |
| Cloud SQL for PostgreSQL (one copy) | Target CPU / source CPU | 1 | multiplier |
| Cloud SQL for PostgreSQL (one copy) | Target RAM / source RAM | 1 | multiplier |
| Cloud SQL for PostgreSQL (one copy) | Target disk / source disk | 1 | multiplier |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · read | 0 | USD/read |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · write | 0 | USD/write |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| Cloud SQL for PostgreSQL (one copy) | Target list price · GiB-month | 0.17 | USD/GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Cloud SQL for PostgreSQL (one copy) | Target list price · network GiB | 0.19 | USD/network GiB |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour |
| Cloud SQL for PostgreSQL (one copy) | Target list price · GiB-hour | 0.007 | USD/GiB-hour |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · input token | 0 | USD/input token |
| Cloud SQL for PostgreSQL (one copy) | Target price guess · output token | 0 | USD/output token |
| Cloud SQL for PostgreSQL (one copy) | Target monthly base charge | 0 | USD/month |
| Cloud SQL for PostgreSQL (one copy) | Target service minimum | 9.365 | USD/month |
| Cloud SQL for PostgreSQL (one copy) | Minimum primary CPU | 2 | vCPU |
| Cloud SQL for PostgreSQL (one copy) | Minimum primary RAM | 8 | GiB |
| Cloud SQL for PostgreSQL (one copy) | Minimum primary disk | 100 | GiB |
| Cloud SQL for PostgreSQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Cloud SQL for PostgreSQL (one copy) | Allocated share of provisioned cost | 1 | fraction |
| Cloud SQL for PostgreSQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Cloud SQL for PostgreSQL (one copy) | Planning peak / mean work | 2 | multiplier |
| Cloud SQL for PostgreSQL (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| Cloud SQL for PostgreSQL (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| Cloud SQL for PostgreSQL (one copy) | Planning disk utilization | 0.8 | fraction |
| Cloud SQL for PostgreSQL (one copy) | Maintenance and log disk reserve | 20 | GiB |
| Cloud SQL for PostgreSQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Cloud SQL for PostgreSQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Cloud SQL for PostgreSQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Cloud SQL for PostgreSQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Cloud SQL for PostgreSQL (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| Cloud SQL for PostgreSQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| Cloud SQL for PostgreSQL (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| Cloud SQL for PostgreSQL (two copies) | Origin list price · Database reads | 0 | USD/operations |
| Cloud SQL for PostgreSQL (two copies) | Origin list price · Database writes | 0 | USD/operations |
| Cloud SQL for PostgreSQL (two copies) | Target CPU / source CPU | 1 | multiplier |
| Cloud SQL for PostgreSQL (two copies) | Target RAM / source RAM | 1 | multiplier |
| Cloud SQL for PostgreSQL (two copies) | Target disk / source disk | 1 | multiplier |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · read | 0 | USD/read |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · write | 0 | USD/write |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| Cloud SQL for PostgreSQL (two copies) | Target list price · GiB-month | 0.17 | USD/GiB-month |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Cloud SQL for PostgreSQL (two copies) | Target list price · network GiB | 0.19 | USD/network GiB |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Cloud SQL for PostgreSQL (two copies) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour |
| Cloud SQL for PostgreSQL (two copies) | Target list price · GiB-hour | 0.007 | USD/GiB-hour |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · input token | 0 | USD/input token |
| Cloud SQL for PostgreSQL (two copies) | Target price guess · output token | 0 | USD/output token |
| Cloud SQL for PostgreSQL (two copies) | Target monthly base charge | 0 | USD/month |
| Cloud SQL for PostgreSQL (two copies) | Target service minimum | 9.365 | USD/month |
| Cloud SQL for PostgreSQL (two copies) | Minimum primary CPU | 2 | vCPU |
| Cloud SQL for PostgreSQL (two copies) | Minimum primary RAM | 8 | GiB |
| Cloud SQL for PostgreSQL (two copies) | Minimum primary disk | 100 | GiB |
| Cloud SQL for PostgreSQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Cloud SQL for PostgreSQL (two copies) | Allocated share of provisioned cost | 1 | fraction |
| Cloud SQL for PostgreSQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Cloud SQL for PostgreSQL (two copies) | Planning peak / mean work | 2 | multiplier |
| Cloud SQL for PostgreSQL (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| Cloud SQL for PostgreSQL (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| Cloud SQL for PostgreSQL (two copies) | Planning disk utilization | 0.8 | fraction |
| Cloud SQL for PostgreSQL (two copies) | Maintenance and log disk reserve | 20 | GiB |
| Cloud SQL for PostgreSQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Cloud SQL for PostgreSQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Cloud SQL for PostgreSQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Cloud SQL for PostgreSQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Cloud SQL for PostgreSQL (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* Cloud SQL Enterprise edition (PostgreSQL) 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-42ce840602ccc44a14430c68c1039d2af3889c41` / `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).

**Aurora PostgreSQL → Cloud SQL for PostgreSQL: 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.145 | USD/vCPU-hours |
| Origin list price · Primary memory | 0 | USD/GiB-hours |
| Origin list price · Primary provisioned storage | 0.1 | 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.

* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.

* Cloud SQL Enterprise edition (PostgreSQL) 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-42ce840602ccc44a14430c68c1039d2af3889c41` / `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).

### AlloyDB for PostgreSQL

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| AWS/Aurora-proprietary SQL: aws\_s3.*, aws\_lambda.invoke, Aurora ML (aws\_sagemaker / aws\_comprehend), aurora\_* / apg\_plan\_mgmt | SQL functions | Out of scope | Full surface | AWS and Aurora extension functions with no counterpart on AlloyDB; a query calling them fails |
| pgwire protocol (application SQL) | Wire protocol | Supported | Common | wire-compatible PostgreSQL; application SQL is unchanged |

#### How it works

Your application's PostgreSQL driver connects directly to AlloyDB for PostgreSQL. These database requests are the **data plane**. The driver and the PostgreSQL wire protocol stay the same, and Tensor9 adds no proxy, translation or latency to your queries.

Management requests, such as snapshots, restores, replicas, failover and configuration changes, are the **control plane**. Tensor9 runs the RDS API in the customer's Cloud Adapter deployment and translates each of these requests to the backend's management API. The sections below list which operations work and which return an error.

![Database requests (SQL over pgwire) connect directly to AlloyDB. The Tensor9 service adapter translates RDS API management calls to AlloyDB admin API.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgcGd3aXJlKSBjb25uZWN0IGRpcmVjdGx5IHRvIEFsbG95REIuIFRoZSBUZW5zb3I5IHNlcnZpY2UgYWRhcHRlciB0cmFuc2xhdGVzIFJEUyBBUEkgbWFuYWdlbWVudCBjYWxscyB0byBBbGxveURCIGFkbWluIEFQSS4iPjxzdHlsZT50ZXh0e2ZvbnQtZmFtaWx5OkludGVyLC1hcHBsZS1zeXN0ZW0sQmxpbmtNYWNTeXN0ZW1Gb250LCdTZWdvZSBVSScsUm9ib3RvLCdIZWx2ZXRpY2EgTmV1ZScsQXJpYWwsc2Fucy1zZXJpZjtmaWxsOiMzMzQxNTV9PC9zdHlsZT4KPGRlZnM+PG1hcmtlciBpZD0iYWhkLWFsbG95ZGIiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjciIG1hcmtlckhlaWdodD0iNyIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6Izk0YTNiOCIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iOCIgeT0iMzQiIHdpZHRoPSI4MjAiIGhlaWdodD0iMjA2IiByeD0iMTYiIHN0cm9rZS13aWR0aD0iMS40IiBzdHJva2UtZGFzaGFycmF5PSI1IDUiIHN0eWxlPSJmaWxsOiNmOGZhZmM7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iMjYiIHk9IjU0IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzk0YTNiODsgZmlsbDojMDQ3ODU3Ij5PTiBHT09HTEUgQ0xPVUQ8L3RleHQ+PHN2ZyB4PSI3OTIiIHk9IjM2IiB3aWR0aD0iMTYiIGhlaWdodD0iMTYiIHZpZXdCb3g9IjAgLTI1IDI1NiAyNTYiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiPjxnPiA8cGF0aCBkPSJNMTcwLjI1MTcsNTYuODE4NiBMMTkyLjUwNDcsMzQuNTY1NiBMMTkzLjk4NzcsMjUuMTk1NiBDMTUzLjQzNjcsLTExLjY3NzQgODguOTc1NywtNy40OTY0IDUyLjQyMDcsMzMuOTE5NiBDNDIuMjY2Nyw0NS40MjI2IDM0LjczMzcsNTkuNzYzNiAzMC43MTY3LDc0LjU3MjYgTDM4LjY4NjcsNzMuNDQ5NiBMODMuMTkxNyw2Ni4xMTA2IEw4Ni42Mjc3LDYyLjU5NjYgQzEwNi40MjQ3LDQwLjg1NDYgMTM5Ljg5NzcsMzcuOTI5NiAxNjIuNzU1Nyw1Ni40Mjg2IEwxNzAuMjUxNyw1Ni44MTg2IFoiIGZpbGw9IiNFQTQzMzUiPiA8L3BhdGg+IDxwYXRoIGQ9Ik0yMjQuMjA0OCw3My45MTgyIEMyMTkuMDg5OCw1NS4wODIyIDIwOC41ODg4LDM4LjE0OTIgMTkzLjk4NzgsMjUuMTk2MiBMMTYyLjc1NTgsNTYuNDI4MiBDMTc1Ljk0MzgsNjcuMjA0MiAxODMuNDU2OCw4My40MzgyIDE4My4xMzQ4LDEwMC40NjUyIEwxODMuMTM0OCwxMDYuMDA5MiBDMTk4LjQ4NTgsMTA2LjAwOTIgMjEwLjkzMTgsMTE4LjQ1NDIgMjEwLjkzMTgsMTMzLjgwNTIgQzIxMC45MzE4LDE0OS4xNTcyIDE5OC40ODU4LDE2MS4yOTAyIDE4My4xMzQ4LDE2MS4yOTAyIEwxMjcuNDYzOCwxNjEuMjkwMiBMMTIxLjk5NzgsMTY3LjIyNDIgTDEyMS45OTc4LDIwMC41NjQyIEwxMjcuNDYzOCwyMDUuNzk1MiBMMTgzLjEzNDgsMjA1Ljc5NTIgQzIyMy4wNjQ4LDIwNi4xMDYyIDI1NS42ODY4LDE3NC4zMDEyIDI1NS45OTc4LDEzNC4zNzEyIEMyNTYuMTg1OCwxMTAuMTY4MiAyNDQuMjUyOCw4Ny40NzgyIDIyNC4yMDQ4LDczLjkxODIiIGZpbGw9IiM0Mjg1RjQiPiA8L3BhdGg+IDxwYXRoIGQ9Ik03MS44NzA0LDIwNS43OTU3IEwxMjcuNDYzNCwyMDUuNzk1NyBMMTI3LjQ2MzQsMTYxLjI4OTcgTDcxLjg3MDQsMTYxLjI4OTcgQzY3LjkwOTQsMTYxLjI4ODcgNjQuMDczNCwxNjAuNDM3NyA2MC40NzE0LDE1OC43OTE3IEw1Mi41ODQ0LDE2MS4yMTE3IEwzMC4xNzU0LDE4My40NjQ3IEwyOC4yMjM0LDE5MS4wMzg3IEM0MC43OTA0LDIwMC41Mjc3IDU2LjEyMzQsMjA1Ljg2MzcgNzEuODcwNCwyMDUuNzk1NyIgZmlsbD0iIzM0QTg1MyI+IDwvcGF0aD4gPHBhdGggZD0iTTcxLjg3MDQsNjEuNDI1NSBDMzEuOTM5NCw2MS42NjM1IC0wLjIzNjYsOTQuMjI3NSAwLjAwMTQsMTM0LjE1NzUgQzAuMTM0NCwxNTYuNDU1NSAxMC41NDg0LDE3Ny40NDU1IDI4LjIyMzQsMTkxLjAzODUgTDYwLjQ3MTQsMTU4Ljc5MTUgQzQ2LjQ4MDQsMTUyLjQ3MDUgNDAuMjYzNCwxMzYuMDA1NSA0Ni41ODQ0LDEyMi4wMTU1IEM1Mi45MDQ0LDEwOC4wMjU1IDY5LjM3MDQsMTAxLjgwODUgODMuMzU5NCwxMDguMTI4NSBDODkuNTI0NCwxMTAuOTEzNSA5NC40NjE0LDExNS44NTE1IDk3LjI0NjQsMTIyLjAxNTUgTDEyOS40OTQ0LDg5Ljc2ODUgQzExNS43NzM0LDcxLjgzMTUgOTQuNDUzNCw2MS4zNDQ1IDcxLjg3MDQsNjEuNDI1NSIgZmlsbD0iI0ZCQkMwNSI+IDwvcGF0aD4gPC9nPjwvc3ZnPgo8cmVjdCB4PSIyNiIgeT0iODgiIHdpZHRoPSIxMjgiIGhlaWdodD0iMTEyIiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjkwIiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTNweCI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIxNDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5Qb3N0Z3JlU1FMIGRyaXZlcjwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjE2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij51bmNoYW5nZWQ8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iODIiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4OyBmaWxsOiMwNDc4NTciPkRBVEFCQVNFIFJFUVVFU1RTIMK3IERJUkVDVCBDT05ORUNUSU9OPC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTA4IiB4Mj0iNjEwIiB5Mj0iMTA4IiBzdHJva2Utd2lkdGg9IjIuMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtYWxsb3lkYikiIHN0eWxlPSJzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSIzODIiIHk9IjEwMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZpbGw6IzA0Nzg1NyI+U1FMIG92ZXIgcGd3aXJlPC90ZXh0Pgo8cmVjdCB4PSI2MTQiIHk9Ijc2IiB3aWR0aD0iMTk2IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+PHN2ZyB4PSI3ODYiIHk9IjU2IiB3aWR0aD0iMjAiIGhlaWdodD0iMjAiIHZpZXdCb3g9IjAgMCA0MzIuMDcxIDQ0NS4zODMiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiPjxnIHN0eWxlPSJmaWxsLXJ1bGU6bm9uemVybztjbGlwLXJ1bGU6bm9uemVybztzdHJva2U6IzAwMDAwMDtzdHJva2UtbWl0ZXJsaW1pdDo0Ij4gPC9nPiA8ZyBzdHlsZT0iZmlsbC1ydWxlOm5vbnplcm87Y2xpcC1ydWxlOm5vbnplcm87ZmlsbDpub25lO3N0cm9rZTojRkZGRkZGO3N0cm9rZS13aWR0aDoxMi40NjUxO3N0cm9rZS1saW5lY2FwOnJvdW5kO3N0cm9rZS1saW5lam9pbjpyb3VuZDtzdHJva2UtbWl0ZXJsaW1pdDo0Ij4gPHBhdGggZD0iTTMyMy4yMDUsMzI0LjIyN2MyLjgzMy0yMy42MDEsMS45ODQtMjcuMDYyLDE5LjU2My0yMy4yMzlsNC40NjMsMC4zOTJjMTMuNTE3LDAuNjE1LDMxLjE5OS0yLjE3NCw0MS41ODctN2MyMi4zNjItMTAuMzc2LDM1LjYyMi0yNy43LDEzLjU3Mi0yMy4xNDhjLTUwLjI5NywxMC4zNzYtNTMuNzU1LTYuNjU1LTUzLjc1NS02LjY1NWM1My4xMTEtNzguODAzLDc1LjMxMy0xNzguODM2LDU2LjE0OS0yMDMuMzIyIEMzNTIuNTE0LTUuNTM0LDI2Mi4wMzYsMjYuMDQ5LDI2MC41MjIsMjYuODY5bC0wLjQ4MiwwLjA4OWMtOS45MzgtMi4wNjItMjEuMDYtMy4yOTQtMzMuNTU0LTMuNDk2Yy0yMi43NjEtMC4zNzQtNDAuMDMyLDUuOTY3LTUzLjEzMywxNS45MDRjMCwwLTE2MS40MDgtNjYuNDk4LTE1My44OTksODMuNjI4YzEuNTk3LDMxLjkzNiw0NS43NzcsMjQxLjY1NSw5OC40NywxNzguMzEgYzE5LjI1OS0yMy4xNjMsMzcuODcxLTQyLjc0OCwzNy44NzEtNDIuNzQ4YzkuMjQyLDYuMTQsMjAuMzA3LDkuMjcyLDMxLjkxMiw4LjE0N2wwLjg5Ny0wLjc2NWMtMC4yODEsMi44NzYtMC4xNTcsNS42ODksMC4zNTksOS4wMTljLTEzLjU3MiwxNS4xNjctOS41ODQsMTcuODMtMzYuNzIzLDIzLjQxNmMtMjcuNDU3LDUuNjU5LTExLjMyNiwxNS43MzQtMC43OTcsMTguMzY3YzEyLjc2OCwzLjE5Myw0Mi4zMDUsNy43MTYsNjIuMjY4LTIwLjIyNCBsLTAuNzk1LDMuMTg4YzUuMzI1LDQuMjYsNC45NjUsMzAuNjE5LDUuNzIsNDkuNDUyYzAuNzU2LDE4LjgzNCwyLjAxNywzNi40MDksNS44NTYsNDYuNzcxYzMuODM5LDEwLjM2LDguMzY5LDM3LjA1LDQ0LjAzNiwyOS40MDZjMjkuODA5LTYuMzg4LDUyLjYtMTUuNTgyLDU0LjY3Ny0xMDEuMTA3IiBzdHlsZT0iZmlsbDojMDAwMDAwO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDozNy4zOTUzO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyIi8+IDxwYXRoIGQ9Ik00MDIuMzk1LDI3MS4yM2MtNTAuMzAyLDEwLjM3Ni01My43Ni02LjY1NS01My43Ni02LjY1NWM1My4xMTEtNzguODA4LDc1LjMxMy0xNzguODQzLDU2LjE1My0yMDMuMzI2Yy01Mi4yNy02Ni43ODUtMTQyLjc1Mi0zNS4yLTE0NC4yNjItMzQuMzhsLTAuNDg2LDAuMDg3Yy05LjkzOC0yLjA2My0yMS4wNi0zLjI5Mi0zMy41Ni0zLjQ5NmMtMjIuNzYxLTAuMzczLTQwLjAyNiw1Ljk2Ny01My4xMjcsMTUuOTAyIGMwLDAtMTYxLjQxMS02Ni40OTUtMTUzLjkwNCw4My42M2MxLjU5NywzMS45MzgsNDUuNzc2LDI0MS42NTcsOTguNDcxLDE3OC4zMTJjMTkuMjYtMjMuMTYzLDM3Ljg2OS00Mi43NDgsMzcuODY5LTQyLjc0OGM5LjI0Myw2LjE0LDIwLjMwOCw5LjI3MiwzMS45MDgsOC4xNDdsMC45MDEtMC43NjVjLTAuMjgsMi44NzYtMC4xNTIsNS42ODksMC4zNjEsOS4wMTljLTEzLjU3NSwxNS4xNjctOS41ODYsMTcuODMtMzYuNzIzLDIzLjQxNiBjLTI3LjQ1OSw1LjY1OS0xMS4zMjgsMTUuNzM0LTAuNzk2LDE4LjM2N2MxMi43NjgsMy4xOTMsNDIuMzA3LDcuNzE2LDYyLjI2Ni0yMC4yMjRsLTAuNzk2LDMuMTg4YzUuMzE5LDQuMjYsOS4wNTQsMjcuNzExLDguNDI4LDQ4Ljk2OWMtMC42MjYsMjEuMjU5LTEuMDQ0LDM1Ljg1NCwzLjE0Nyw0Ny4yNTRjNC4xOTEsMTEuNCw4LjM2OCwzNy4wNSw0NC4wNDIsMjkuNDA2YzI5LjgwOS02LjM4OCw0NS4yNTYtMjIuOTQyLDQ3LjQwNS01MC41NTUgYzEuNTI1LTE5LjYzMSw0Ljk3Ni0xNi43MjksNS4xOTQtMzQuMjhsMi43NjgtOC4zMDljMy4xOTItMjYuNjExLDAuNTA3LTM1LjE5NiwxOC44NzItMzEuMjAzbDQuNDYzLDAuMzkyYzEzLjUxNywwLjYxNSwzMS4yMDgtMi4xNzQsNDEuNTkxLTdjMjIuMzU4LTEwLjM3NiwzNS42MTgtMjcuNywxMy41NzMtMjMuMTQ4eiIgc3R5bGU9ImZpbGw6IzMzNjc5MTtzdHJva2U6bm9uZSIvPiA8cGF0aCBkPSJNMjE1Ljg2NiwyODYuNDg0Yy0xLjM4NSw0OS41MTYsMC4zNDgsOTkuMzc3LDUuMTkzLDExMS40OTVjNC44NDgsMTIuMTE4LDE1LjIyMywzNS42ODgsNTAuOSwyOC4wNDVjMjkuODA2LTYuMzksNDAuNjUxLTE4Ljc1Niw0NS4zNTctNDYuMDUxYzMuNDY2LTIwLjA4MiwxMC4xNDgtNzUuODU0LDExLjAwNS04Ny4yODEiLz4gPHBhdGggZD0iTTE3My4xMDQsMzguMjU2YzAsMC0xNjEuNTIxLTY2LjAxNi0xNTQuMDEyLDg0LjEwOWMxLjU5NywzMS45MzgsNDUuNzc5LDI0MS42NjQsOTguNDczLDE3OC4zMTZjMTkuMjU2LTIzLjE2NiwzNi42NzEtNDEuMzM1LDM2LjY3MS00MS4zMzUiLz4gPHBhdGggZD0iTTI2MC4zNDksMjYuMjA3Yy01LjU5MSwxLjc1Myw4OS44NDgtMzQuODg5LDE0NC4wODcsMzQuNDE3YzE5LjE1OSwyNC40ODQtMy4wNDMsMTI0LjUxOS01Ni4xNTMsMjAzLjMyOSIvPiA8cGF0aCBkPSJNMzQ4LjI4MiwyNjMuOTUzYzAsMCwzLjQ2MSwxNy4wMzYsNTMuNzY0LDYuNjUzYzIyLjA0LTQuNTUyLDguNzc2LDEyLjc3NC0xMy41NzcsMjMuMTU1Yy0xOC4zNDUsOC41MTQtNTkuNDc0LDEwLjY5Ni02MC4xNDYtMS4wNjljLTEuNzI5LTMwLjM1NSwyMS42NDctMjEuMTMzLDE5Ljk2LTI4LjczOWMtMS41MjUtNi44NS0xMS45NzktMTMuNTczLTE4Ljg5NC0zMC4zMzggYy02LjAzNy0xNC42MzMtODIuNzk2LTEyNi44NDksMjEuMjg3LTExMC4xODNjMy44MTMtMC43ODktMjcuMTQ2LTk5LjAwMi0xMjQuNTUzLTEwMC41OTljLTk3LjM4NS0xLjU5Ny05NC4xOSwxMTkuNzYyLTk0LjE5LDExOS43NjIiIHN0eWxlPSJzdHJva2UtbGluZWpvaW46YmV2ZWwiLz4gPHBhdGggZD0iTTE4OC42MDQsMjc0LjMzNGMtMTMuNTc3LDE1LjE2Ni05LjU4NCwxNy44MjktMzYuNzIzLDIzLjQxN2MtMjcuNDU5LDUuNjYtMTEuMzI2LDE1LjczMy0wLjc5NywxOC4zNjVjMTIuNzY4LDMuMTk1LDQyLjMwNyw3LjcxOCw2Mi4yNjYtMjAuMjI5YzYuMDc4LTguNTA5LTAuMDM2LTIyLjA4Ni04LjM4NS0yNS41NDdjLTQuMDM0LTEuNjcxLTkuNDI4LTMuNzY1LTE2LjM2MSwzLjk5NHoiLz4gPHBhdGggZD0iTTE4Ny43MTUsMjc0LjA2OWMtMS4zNjgtOC45MTcsMi45My0xOS41MjgsNy41MzYtMzEuOTQyYzYuOTIyLTE4LjYyNiwyMi44OTMtMzcuMjU1LDEwLjExNy05Ni4zMzljLTkuNTIzLTQ0LjAyOS03My4zOTYtOS4xNjMtNzMuNDM2LTMuMTkzYy0wLjAzOSw1Ljk2OCwyLjg4OSwzMC4yNi0xLjA2Nyw1OC41NDhjLTUuMTYyLDM2LjkxMywyMy40ODgsNjguMTMyLDU2LjQ3OSw2NC45MzgiLz4gPHBhdGggZD0iTTE3Mi41MTcsMTQxLjdjLTAuMjg4LDIuMDM5LDMuNzMzLDcuNDgsOC45NzYsOC4yMDdjNS4yMzQsMC43Myw5LjcxNC0zLjUyMiw5Ljk5OC01LjU1OWMwLjI4NC0yLjAzOS0zLjczMi00LjI4NS04Ljk3Ny01LjAxNWMtNS4yMzctMC43MzEtOS43MTksMC4zMzMtOS45OTYsMi4zNjd6IiBzdHlsZT0iZmlsbDojRkZGRkZGO3N0cm9rZS13aWR0aDo0LjE1NTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNMzMxLjk0MSwxMzcuNTQzYzAuMjg0LDIuMDM5LTMuNzMyLDcuNDgtOC45NzYsOC4yMDdjLTUuMjM4LDAuNzMtOS43MTgtMy41MjItMTAuMDA1LTUuNTU5Yy0wLjI3Ny0yLjAzOSwzLjc0LTQuMjg1LDguOTc5LTUuMDE1YzUuMjM5LTAuNzMsOS43MTgsMC4zMzMsMTAuMDAyLDIuMzY4eiIgc3R5bGU9ImZpbGw6I0ZGRkZGRjtzdHJva2Utd2lkdGg6Mi4wNzc1O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyIi8+IDxwYXRoIGQ9Ik0zNTAuNjc2LDEyMy40MzJjMC44NjMsMTUuOTk0LTMuNDQ1LDI2Ljg4OC0zLjk4OCw0My45MTRjLTAuODA0LDI0Ljc0OCwxMS43OTksNTMuMDc0LTcuMTkxLDgxLjQzNSIvPiA8cGF0aCBkPSJNMCw2MC4yMzIiIHN0eWxlPSJzdHJva2Utd2lkdGg6MyIvPiA8L2c+PC9zdmc+Cjx0ZXh0IHg9IjcxMiIgeT0iMTAzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjEycHgiPkFsbG95REI8L3RleHQ+Cjx0ZXh0IHg9IjcxMiIgeT0iMTIyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+UG9zdGdyZVNRTCBlbmdpbmU8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iMTU4IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzk0YTNiOCI+TUFOQUdFTUVOVCBSRVFVRVNUUyDCtyBWSUEgVEVOU09SOTwvdGV4dD4KPGxpbmUgeDE9IjE1NCIgeTE9IjE5NiIgeDI9IjMwMCIgeTI9IjE5NiIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoZC1hbGxveWRiKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjIyNyIgeT0iMTg4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YiI+UkRTIEFQSTwvdGV4dD4KPHJlY3QgeD0iMzA0IiB5PSIxNjQiIHdpZHRoPSIxODAiIGhlaWdodD0iNjYiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iMzk0IiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSIzOTQiIHk9IjIwOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+c2VydmljZSBhZGFwdGVyPC90ZXh0Pgo8bGluZSB4MT0iNDg0IiB5MT0iMTk2IiB4Mj0iNjEwIiB5Mj0iMTk2IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLWFsbG95ZGIpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHJlY3QgeD0iNjE0IiB5PSIxNjQiIHdpZHRoPSIxOTYiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iNzEyIiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTEuNXB4Ij5BbGxveURCIGFkbWluIEFQSTwvdGV4dD4KPHRleHQgeD0iNzEyIiB5PSIyMTAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj50aGUgYmFja2VuZCdzIG1hbmFnZW1lbnQgQVBJPC90ZXh0Pgo8L3N2Zz4=)

![Database requests (SQL over pgwire) connect directly to AlloyDB. The Tensor9 service adapter translates RDS API management calls to AlloyDB admin API.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgcGd3aXJlKSBjb25uZWN0IGRpcmVjdGx5IHRvIEFsbG95REIuIFRoZSBUZW5zb3I5IHNlcnZpY2UgYWRhcHRlciB0cmFuc2xhdGVzIFJEUyBBUEkgbWFuYWdlbWVudCBjYWxscyB0byBBbGxveURCIGFkbWluIEFQSS4iPjxzdHlsZT50ZXh0e2ZvbnQtZmFtaWx5OkludGVyLC1hcHBsZS1zeXN0ZW0sQmxpbmtNYWNTeXN0ZW1Gb250LCdTZWdvZSBVSScsUm9ib3RvLCdIZWx2ZXRpY2EgTmV1ZScsQXJpYWwsc2Fucy1zZXJpZjtmaWxsOiNjYmQ1ZTF9PC9zdHlsZT4KPGRlZnM+PG1hcmtlciBpZD0iYWhkLWFsbG95ZGIiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjciIG1hcmtlckhlaWdodD0iNyIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6IzY0NzQ4YiIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iOCIgeT0iMzQiIHdpZHRoPSI4MjAiIGhlaWdodD0iMjA2IiByeD0iMTYiIHN0cm9rZS13aWR0aD0iMS40IiBzdHJva2UtZGFzaGFycmF5PSI1IDUiIHN0eWxlPSJmaWxsOiMwZjE3MmE7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iMjYiIHk9IjU0IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzY0NzQ4YjsgZmlsbDojNmVlN2I3Ij5PTiBHT09HTEUgQ0xPVUQ8L3RleHQ+PHN2ZyB4PSI3OTIiIHk9IjM2IiB3aWR0aD0iMTYiIGhlaWdodD0iMTYiIHZpZXdCb3g9IjAgLTI1IDI1NiAyNTYiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiPjxnPiA8cGF0aCBkPSJNMTcwLjI1MTcsNTYuODE4NiBMMTkyLjUwNDcsMzQuNTY1NiBMMTkzLjk4NzcsMjUuMTk1NiBDMTUzLjQzNjcsLTExLjY3NzQgODguOTc1NywtNy40OTY0IDUyLjQyMDcsMzMuOTE5NiBDNDIuMjY2Nyw0NS40MjI2IDM0LjczMzcsNTkuNzYzNiAzMC43MTY3LDc0LjU3MjYgTDM4LjY4NjcsNzMuNDQ5NiBMODMuMTkxNyw2Ni4xMTA2IEw4Ni42Mjc3LDYyLjU5NjYgQzEwNi40MjQ3LDQwLjg1NDYgMTM5Ljg5NzcsMzcuOTI5NiAxNjIuNzU1Nyw1Ni40Mjg2IEwxNzAuMjUxNyw1Ni44MTg2IFoiIGZpbGw9IiNFQTQzMzUiPiA8L3BhdGg+IDxwYXRoIGQ9Ik0yMjQuMjA0OCw3My45MTgyIEMyMTkuMDg5OCw1NS4wODIyIDIwOC41ODg4LDM4LjE0OTIgMTkzLjk4NzgsMjUuMTk2MiBMMTYyLjc1NTgsNTYuNDI4MiBDMTc1Ljk0MzgsNjcuMjA0MiAxODMuNDU2OCw4My40MzgyIDE4My4xMzQ4LDEwMC40NjUyIEwxODMuMTM0OCwxMDYuMDA5MiBDMTk4LjQ4NTgsMTA2LjAwOTIgMjEwLjkzMTgsMTE4LjQ1NDIgMjEwLjkzMTgsMTMzLjgwNTIgQzIxMC45MzE4LDE0OS4xNTcyIDE5OC40ODU4LDE2MS4yOTAyIDE4My4xMzQ4LDE2MS4yOTAyIEwxMjcuNDYzOCwxNjEuMjkwMiBMMTIxLjk5NzgsMTY3LjIyNDIgTDEyMS45OTc4LDIwMC41NjQyIEwxMjcuNDYzOCwyMDUuNzk1MiBMMTgzLjEzNDgsMjA1Ljc5NTIgQzIyMy4wNjQ4LDIwNi4xMDYyIDI1NS42ODY4LDE3NC4zMDEyIDI1NS45OTc4LDEzNC4zNzEyIEMyNTYuMTg1OCwxMTAuMTY4MiAyNDQuMjUyOCw4Ny40NzgyIDIyNC4yMDQ4LDczLjkxODIiIGZpbGw9IiM0Mjg1RjQiPiA8L3BhdGg+IDxwYXRoIGQ9Ik03MS44NzA0LDIwNS43OTU3IEwxMjcuNDYzNCwyMDUuNzk1NyBMMTI3LjQ2MzQsMTYxLjI4OTcgTDcxLjg3MDQsMTYxLjI4OTcgQzY3LjkwOTQsMTYxLjI4ODcgNjQuMDczNCwxNjAuNDM3NyA2MC40NzE0LDE1OC43OTE3IEw1Mi41ODQ0LDE2MS4yMTE3IEwzMC4xNzU0LDE4My40NjQ3IEwyOC4yMjM0LDE5MS4wMzg3IEM0MC43OTA0LDIwMC41Mjc3IDU2LjEyMzQsMjA1Ljg2MzcgNzEuODcwNCwyMDUuNzk1NyIgZmlsbD0iIzM0QTg1MyI+IDwvcGF0aD4gPHBhdGggZD0iTTcxLjg3MDQsNjEuNDI1NSBDMzEuOTM5NCw2MS42NjM1IC0wLjIzNjYsOTQuMjI3NSAwLjAwMTQsMTM0LjE1NzUgQzAuMTM0NCwxNTYuNDU1NSAxMC41NDg0LDE3Ny40NDU1IDI4LjIyMzQsMTkxLjAzODUgTDYwLjQ3MTQsMTU4Ljc5MTUgQzQ2LjQ4MDQsMTUyLjQ3MDUgNDAuMjYzNCwxMzYuMDA1NSA0Ni41ODQ0LDEyMi4wMTU1IEM1Mi45MDQ0LDEwOC4wMjU1IDY5LjM3MDQsMTAxLjgwODUgODMuMzU5NCwxMDguMTI4NSBDODkuNTI0NCwxMTAuOTEzNSA5NC40NjE0LDExNS44NTE1IDk3LjI0NjQsMTIyLjAxNTUgTDEyOS40OTQ0LDg5Ljc2ODUgQzExNS43NzM0LDcxLjgzMTUgOTQuNDUzNCw2MS4zNDQ1IDcxLjg3MDQsNjEuNDI1NSIgZmlsbD0iI0ZCQkMwNSI+IDwvcGF0aD4gPC9nPjwvc3ZnPgo8cmVjdCB4PSIyNiIgeT0iODgiIHdpZHRoPSIxMjgiIGhlaWdodD0iMTEyIiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjkwIiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTNweCI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIxNDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5Qb3N0Z3JlU1FMIGRyaXZlcjwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjE2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij51bmNoYW5nZWQ8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iODIiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiM2ZWU3YjciPkRBVEFCQVNFIFJFUVVFU1RTIMK3IERJUkVDVCBDT05ORUNUSU9OPC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTA4IiB4Mj0iNjEwIiB5Mj0iMTA4IiBzdHJva2Utd2lkdGg9IjIuMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtYWxsb3lkYikiIHN0eWxlPSJzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSIzODIiIHk9IjEwMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZpbGw6IzZlZTdiNyI+U1FMIG92ZXIgcGd3aXJlPC90ZXh0Pgo8cmVjdCB4PSI2MTQiIHk9Ijc2IiB3aWR0aD0iMTk2IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+PHN2ZyB4PSI3ODYiIHk9IjU2IiB3aWR0aD0iMjAiIGhlaWdodD0iMjAiIHZpZXdCb3g9IjAgMCA0MzIuMDcxIDQ0NS4zODMiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiPjxnIHN0eWxlPSJmaWxsLXJ1bGU6bm9uemVybztjbGlwLXJ1bGU6bm9uemVybztzdHJva2U6IzAwMDAwMDtzdHJva2UtbWl0ZXJsaW1pdDo0Ij4gPC9nPiA8ZyBzdHlsZT0iZmlsbC1ydWxlOm5vbnplcm87Y2xpcC1ydWxlOm5vbnplcm87ZmlsbDpub25lO3N0cm9rZTojRkZGRkZGO3N0cm9rZS13aWR0aDoxMi40NjUxO3N0cm9rZS1saW5lY2FwOnJvdW5kO3N0cm9rZS1saW5lam9pbjpyb3VuZDtzdHJva2UtbWl0ZXJsaW1pdDo0Ij4gPHBhdGggZD0iTTMyMy4yMDUsMzI0LjIyN2MyLjgzMy0yMy42MDEsMS45ODQtMjcuMDYyLDE5LjU2My0yMy4yMzlsNC40NjMsMC4zOTJjMTMuNTE3LDAuNjE1LDMxLjE5OS0yLjE3NCw0MS41ODctN2MyMi4zNjItMTAuMzc2LDM1LjYyMi0yNy43LDEzLjU3Mi0yMy4xNDhjLTUwLjI5NywxMC4zNzYtNTMuNzU1LTYuNjU1LTUzLjc1NS02LjY1NWM1My4xMTEtNzguODAzLDc1LjMxMy0xNzguODM2LDU2LjE0OS0yMDMuMzIyIEMzNTIuNTE0LTUuNTM0LDI2Mi4wMzYsMjYuMDQ5LDI2MC41MjIsMjYuODY5bC0wLjQ4MiwwLjA4OWMtOS45MzgtMi4wNjItMjEuMDYtMy4yOTQtMzMuNTU0LTMuNDk2Yy0yMi43NjEtMC4zNzQtNDAuMDMyLDUuOTY3LTUzLjEzMywxNS45MDRjMCwwLTE2MS40MDgtNjYuNDk4LTE1My44OTksODMuNjI4YzEuNTk3LDMxLjkzNiw0NS43NzcsMjQxLjY1NSw5OC40NywxNzguMzEgYzE5LjI1OS0yMy4xNjMsMzcuODcxLTQyLjc0OCwzNy44NzEtNDIuNzQ4YzkuMjQyLDYuMTQsMjAuMzA3LDkuMjcyLDMxLjkxMiw4LjE0N2wwLjg5Ny0wLjc2NWMtMC4yODEsMi44NzYtMC4xNTcsNS42ODksMC4zNTksOS4wMTljLTEzLjU3MiwxNS4xNjctOS41ODQsMTcuODMtMzYuNzIzLDIzLjQxNmMtMjcuNDU3LDUuNjU5LTExLjMyNiwxNS43MzQtMC43OTcsMTguMzY3YzEyLjc2OCwzLjE5Myw0Mi4zMDUsNy43MTYsNjIuMjY4LTIwLjIyNCBsLTAuNzk1LDMuMTg4YzUuMzI1LDQuMjYsNC45NjUsMzAuNjE5LDUuNzIsNDkuNDUyYzAuNzU2LDE4LjgzNCwyLjAxNywzNi40MDksNS44NTYsNDYuNzcxYzMuODM5LDEwLjM2LDguMzY5LDM3LjA1LDQ0LjAzNiwyOS40MDZjMjkuODA5LTYuMzg4LDUyLjYtMTUuNTgyLDU0LjY3Ny0xMDEuMTA3IiBzdHlsZT0iZmlsbDojMDAwMDAwO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDozNy4zOTUzO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyIi8+IDxwYXRoIGQ9Ik00MDIuMzk1LDI3MS4yM2MtNTAuMzAyLDEwLjM3Ni01My43Ni02LjY1NS01My43Ni02LjY1NWM1My4xMTEtNzguODA4LDc1LjMxMy0xNzguODQzLDU2LjE1My0yMDMuMzI2Yy01Mi4yNy02Ni43ODUtMTQyLjc1Mi0zNS4yLTE0NC4yNjItMzQuMzhsLTAuNDg2LDAuMDg3Yy05LjkzOC0yLjA2My0yMS4wNi0zLjI5Mi0zMy41Ni0zLjQ5NmMtMjIuNzYxLTAuMzczLTQwLjAyNiw1Ljk2Ny01My4xMjcsMTUuOTAyIGMwLDAtMTYxLjQxMS02Ni40OTUtMTUzLjkwNCw4My42M2MxLjU5NywzMS45MzgsNDUuNzc2LDI0MS42NTcsOTguNDcxLDE3OC4zMTJjMTkuMjYtMjMuMTYzLDM3Ljg2OS00Mi43NDgsMzcuODY5LTQyLjc0OGM5LjI0Myw2LjE0LDIwLjMwOCw5LjI3MiwzMS45MDgsOC4xNDdsMC45MDEtMC43NjVjLTAuMjgsMi44NzYtMC4xNTIsNS42ODksMC4zNjEsOS4wMTljLTEzLjU3NSwxNS4xNjctOS41ODYsMTcuODMtMzYuNzIzLDIzLjQxNiBjLTI3LjQ1OSw1LjY1OS0xMS4zMjgsMTUuNzM0LTAuNzk2LDE4LjM2N2MxMi43NjgsMy4xOTMsNDIuMzA3LDcuNzE2LDYyLjI2Ni0yMC4yMjRsLTAuNzk2LDMuMTg4YzUuMzE5LDQuMjYsOS4wNTQsMjcuNzExLDguNDI4LDQ4Ljk2OWMtMC42MjYsMjEuMjU5LTEuMDQ0LDM1Ljg1NCwzLjE0Nyw0Ny4yNTRjNC4xOTEsMTEuNCw4LjM2OCwzNy4wNSw0NC4wNDIsMjkuNDA2YzI5LjgwOS02LjM4OCw0NS4yNTYtMjIuOTQyLDQ3LjQwNS01MC41NTUgYzEuNTI1LTE5LjYzMSw0Ljk3Ni0xNi43MjksNS4xOTQtMzQuMjhsMi43NjgtOC4zMDljMy4xOTItMjYuNjExLDAuNTA3LTM1LjE5NiwxOC44NzItMzEuMjAzbDQuNDYzLDAuMzkyYzEzLjUxNywwLjYxNSwzMS4yMDgtMi4xNzQsNDEuNTkxLTdjMjIuMzU4LTEwLjM3NiwzNS42MTgtMjcuNywxMy41NzMtMjMuMTQ4eiIgc3R5bGU9ImZpbGw6IzMzNjc5MTtzdHJva2U6bm9uZSIvPiA8cGF0aCBkPSJNMjE1Ljg2NiwyODYuNDg0Yy0xLjM4NSw0OS41MTYsMC4zNDgsOTkuMzc3LDUuMTkzLDExMS40OTVjNC44NDgsMTIuMTE4LDE1LjIyMywzNS42ODgsNTAuOSwyOC4wNDVjMjkuODA2LTYuMzksNDAuNjUxLTE4Ljc1Niw0NS4zNTctNDYuMDUxYzMuNDY2LTIwLjA4MiwxMC4xNDgtNzUuODU0LDExLjAwNS04Ny4yODEiLz4gPHBhdGggZD0iTTE3My4xMDQsMzguMjU2YzAsMC0xNjEuNTIxLTY2LjAxNi0xNTQuMDEyLDg0LjEwOWMxLjU5NywzMS45MzgsNDUuNzc5LDI0MS42NjQsOTguNDczLDE3OC4zMTZjMTkuMjU2LTIzLjE2NiwzNi42NzEtNDEuMzM1LDM2LjY3MS00MS4zMzUiLz4gPHBhdGggZD0iTTI2MC4zNDksMjYuMjA3Yy01LjU5MSwxLjc1Myw4OS44NDgtMzQuODg5LDE0NC4wODcsMzQuNDE3YzE5LjE1OSwyNC40ODQtMy4wNDMsMTI0LjUxOS01Ni4xNTMsMjAzLjMyOSIvPiA8cGF0aCBkPSJNMzQ4LjI4MiwyNjMuOTUzYzAsMCwzLjQ2MSwxNy4wMzYsNTMuNzY0LDYuNjUzYzIyLjA0LTQuNTUyLDguNzc2LDEyLjc3NC0xMy41NzcsMjMuMTU1Yy0xOC4zNDUsOC41MTQtNTkuNDc0LDEwLjY5Ni02MC4xNDYtMS4wNjljLTEuNzI5LTMwLjM1NSwyMS42NDctMjEuMTMzLDE5Ljk2LTI4LjczOWMtMS41MjUtNi44NS0xMS45NzktMTMuNTczLTE4Ljg5NC0zMC4zMzggYy02LjAzNy0xNC42MzMtODIuNzk2LTEyNi44NDksMjEuMjg3LTExMC4xODNjMy44MTMtMC43ODktMjcuMTQ2LTk5LjAwMi0xMjQuNTUzLTEwMC41OTljLTk3LjM4NS0xLjU5Ny05NC4xOSwxMTkuNzYyLTk0LjE5LDExOS43NjIiIHN0eWxlPSJzdHJva2UtbGluZWpvaW46YmV2ZWwiLz4gPHBhdGggZD0iTTE4OC42MDQsMjc0LjMzNGMtMTMuNTc3LDE1LjE2Ni05LjU4NCwxNy44MjktMzYuNzIzLDIzLjQxN2MtMjcuNDU5LDUuNjYtMTEuMzI2LDE1LjczMy0wLjc5NywxOC4zNjVjMTIuNzY4LDMuMTk1LDQyLjMwNyw3LjcxOCw2Mi4yNjYtMjAuMjI5YzYuMDc4LTguNTA5LTAuMDM2LTIyLjA4Ni04LjM4NS0yNS41NDdjLTQuMDM0LTEuNjcxLTkuNDI4LTMuNzY1LTE2LjM2MSwzLjk5NHoiLz4gPHBhdGggZD0iTTE4Ny43MTUsMjc0LjA2OWMtMS4zNjgtOC45MTcsMi45My0xOS41MjgsNy41MzYtMzEuOTQyYzYuOTIyLTE4LjYyNiwyMi44OTMtMzcuMjU1LDEwLjExNy05Ni4zMzljLTkuNTIzLTQ0LjAyOS03My4zOTYtOS4xNjMtNzMuNDM2LTMuMTkzYy0wLjAzOSw1Ljk2OCwyLjg4OSwzMC4yNi0xLjA2Nyw1OC41NDhjLTUuMTYyLDM2LjkxMywyMy40ODgsNjguMTMyLDU2LjQ3OSw2NC45MzgiLz4gPHBhdGggZD0iTTE3Mi41MTcsMTQxLjdjLTAuMjg4LDIuMDM5LDMuNzMzLDcuNDgsOC45NzYsOC4yMDdjNS4yMzQsMC43Myw5LjcxNC0zLjUyMiw5Ljk5OC01LjU1OWMwLjI4NC0yLjAzOS0zLjczMi00LjI4NS04Ljk3Ny01LjAxNWMtNS4yMzctMC43MzEtOS43MTksMC4zMzMtOS45OTYsMi4zNjd6IiBzdHlsZT0iZmlsbDojRkZGRkZGO3N0cm9rZS13aWR0aDo0LjE1NTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNMzMxLjk0MSwxMzcuNTQzYzAuMjg0LDIuMDM5LTMuNzMyLDcuNDgtOC45NzYsOC4yMDdjLTUuMjM4LDAuNzMtOS43MTgtMy41MjItMTAuMDA1LTUuNTU5Yy0wLjI3Ny0yLjAzOSwzLjc0LTQuMjg1LDguOTc5LTUuMDE1YzUuMjM5LTAuNzMsOS43MTgsMC4zMzMsMTAuMDAyLDIuMzY4eiIgc3R5bGU9ImZpbGw6I0ZGRkZGRjtzdHJva2Utd2lkdGg6Mi4wNzc1O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyIi8+IDxwYXRoIGQ9Ik0zNTAuNjc2LDEyMy40MzJjMC44NjMsMTUuOTk0LTMuNDQ1LDI2Ljg4OC0zLjk4OCw0My45MTRjLTAuODA0LDI0Ljc0OCwxMS43OTksNTMuMDc0LTcuMTkxLDgxLjQzNSIvPiA8cGF0aCBkPSJNMCw2MC4yMzIiIHN0eWxlPSJzdHJva2Utd2lkdGg6MyIvPiA8L2c+PC9zdmc+Cjx0ZXh0IHg9IjcxMiIgeT0iMTAzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjEycHgiPkFsbG95REI8L3RleHQ+Cjx0ZXh0IHg9IjcxMiIgeT0iMTIyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+UG9zdGdyZVNRTCBlbmdpbmU8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iMTU4IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzY0NzQ4YiI+TUFOQUdFTUVOVCBSRVFVRVNUUyDCtyBWSUEgVEVOU09SOTwvdGV4dD4KPGxpbmUgeDE9IjE1NCIgeTE9IjE5NiIgeDI9IjMwMCIgeTI9IjE5NiIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoZC1hbGxveWRiKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjIyNyIgeT0iMTg4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiOCI+UkRTIEFQSTwvdGV4dD4KPHJlY3QgeD0iMzA0IiB5PSIxNjQiIHdpZHRoPSIxODAiIGhlaWdodD0iNjYiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iMzk0IiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSIzOTQiIHk9IjIwOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+c2VydmljZSBhZGFwdGVyPC90ZXh0Pgo8bGluZSB4MT0iNDg0IiB5MT0iMTk2IiB4Mj0iNjEwIiB5Mj0iMTk2IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLWFsbG95ZGIpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHJlY3QgeD0iNjE0IiB5PSIxNjQiIHdpZHRoPSIxOTYiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iNzEyIiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTEuNXB4Ij5BbGxveURCIGFkbWluIEFQSTwvdGV4dD4KPHRleHQgeD0iNzEyIiB5PSIyMTAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij50aGUgYmFja2VuZCdzIG1hbmFnZW1lbnQgQVBJPC90ZXh0Pgo8L3N2Zz4=)

Queries reach the database directly; only the management calls are translated.

#### Database connections

Aurora stores data in an AWS-specific storage layer, but your application reaches it over the standard PostgreSQL wire protocol, which AlloyDB for PostgreSQL also supports. Your SQL, drivers, object-relational mappers (ORMs), prepared statements, data types and transaction behavior stay the same; only the storage underneath changes.

AWS and Aurora add SQL functions for moving data through S3, invoking Lambda and machine learning. These functions do not exist on the backend, so a query that calls them returns an error.

#### Database management

At runtime your application and tools keep making the same RDS calls for the cluster and its members. For each supported operation, the adapter accepts the RDS request, returns the RDS response format, and maps it to AlloyDB. A cluster becomes an AlloyDB cluster, the writer becomes a highly available primary instance, and each reader becomes its own read pool. Parameter groups become database flags, and a reboot becomes an instance restart. Snapshot, restore, point-in-time restore, failover, stop / start and global-cluster requests return an error; the limitations below describe what AlloyDB does on its own instead.

With Max, your tools call `CreateDBCluster` and `CreateDBInstance` through the RDS adapter to create a logical Aurora cluster and its members on AlloyDB. The first member becomes the cluster's primary instance, placed across two zones; later members become read pool instances. Tensor9 keeps a durable record of the logical cluster and its members, with AWS-style identifiers, and reconciles the AlloyDB resources with it: it records each accepted request, then creates or removes the AlloyDB resources in the background. `DescribeDBClusters` and `DescribeDBInstances` report the status and endpoints that AlloyDB shows. `DeleteDBInstance` removes readers before the writer; `DeleteDBCluster` removes the cluster once its members are gone. Your application's SQL connection goes directly to AlloyDB.

![The Tensor9 service adapter handles RDS management requests using AlloyDB admin API and returns RDS responses.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTk2IiB2aWV3Qm94PSIwIDAgODM2IDE5NiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgaGFuZGxlcyBSRFMgbWFuYWdlbWVudCByZXF1ZXN0cyB1c2luZyBBbGxveURCIGFkbWluIEFQSSBhbmQgcmV0dXJucyBSRFMgcmVzcG9uc2VzLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaGMtcmRzLWFsbG95ZGItYWRtaW4tYXBpIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM5NGEzYjgiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjE2IiB5PSIzNCIgd2lkdGg9IjIzNiIgaGVpZ2h0PSIxMjgiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iMTM0IiB5PSI2MCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMi41cHgiPlJEUyBtYW5hZ2VtZW50IGNhbGw8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iODIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5jcmVhdGUgwrcgZGVzY3JpYmUgwrcgZGVsZXRlPC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9Ijk5IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+d3JpdGVyIMK3IHJlYWRlcnM8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iMTE2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+cGFyYW1ldGVycyDCtyByZWJvb3Q8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iMTQyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YiI+c2FtZSByZXF1ZXN0IC8gcmVzcG9uc2Ugc2hhcGVzPC90ZXh0Pgo8bGluZSB4MT0iMjUyIiB5MT0iNzQiIHgyPSIzMTQiIHkyPSI3NCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtYWxsb3lkYi1hZG1pbi1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPGxpbmUgeDE9IjMxOCIgeTE9IjEyOCIgeDI9IjI1NiIgeTI9IjEyOCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtYWxsb3lkYi1hZG1pbi1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHJlY3QgeD0iMzE4IiB5PSI1NCIgd2lkdGg9IjIwNCIgaGVpZ2h0PSI4OCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI0MjAiIHk9Ijk0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC1zaXplOjEycHgiPlRlbnNvcjk8L3RleHQ+CiAgPHRleHQgeD0iNDIwIiB5PSIxMTIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPnNlcnZpY2UgYWRhcHRlcjwvdGV4dD4KPGxpbmUgeDE9IjUyMiIgeTE9Ijc0IiB4Mj0iNTg0IiB5Mj0iNzQiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWFsbG95ZGItYWRtaW4tYXBpKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxsaW5lIHgxPSI1ODgiIHkxPSIxMjgiIHgyPSI1MjYiIHkyPSIxMjgiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWFsbG95ZGItYWRtaW4tYXBpKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxyZWN0IHg9IjU4OCIgeT0iMzQiIHdpZHRoPSIyMzIiIGhlaWdodD0iMTI4IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjcwNCIgeT0iNjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTJweCI+QWxsb3lEQiBhZG1pbiBBUEk8L3RleHQ+Cjx0ZXh0IHg9IjcwNCIgeT0iOTQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5jbHVzdGVycyDCtyBpbnN0YW5jZXMgwrcgcmVhZCBwb29sczwvdGV4dD4KPHRleHQgeD0iNzA0IiB5PSIxMTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5kYXRhYmFzZSBmbGFncyDCtyByZXN0YXJ0PC90ZXh0Pgo8L3N2Zz4=)

![The Tensor9 service adapter handles RDS management requests using AlloyDB admin API and returns RDS responses.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTk2IiB2aWV3Qm94PSIwIDAgODM2IDE5NiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgaGFuZGxlcyBSRFMgbWFuYWdlbWVudCByZXF1ZXN0cyB1c2luZyBBbGxveURCIGFkbWluIEFQSSBhbmQgcmV0dXJucyBSRFMgcmVzcG9uc2VzLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaGMtcmRzLWFsbG95ZGItYWRtaW4tYXBpIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM2NDc0OGIiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjE2IiB5PSIzNCIgd2lkdGg9IjIzNiIgaGVpZ2h0PSIxMjgiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iMTM0IiB5PSI2MCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMi41cHgiPlJEUyBtYW5hZ2VtZW50IGNhbGw8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iODIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5jcmVhdGUgwrcgZGVzY3JpYmUgwrcgZGVsZXRlPC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9Ijk5IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+d3JpdGVyIMK3IHJlYWRlcnM8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iMTE2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+cGFyYW1ldGVycyDCtyByZWJvb3Q8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iMTQyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiOCI+c2FtZSByZXF1ZXN0IC8gcmVzcG9uc2Ugc2hhcGVzPC90ZXh0Pgo8bGluZSB4MT0iMjUyIiB5MT0iNzQiIHgyPSIzMTQiIHkyPSI3NCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtYWxsb3lkYi1hZG1pbi1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPGxpbmUgeDE9IjMxOCIgeTE9IjEyOCIgeDI9IjI1NiIgeTI9IjEyOCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtYWxsb3lkYi1hZG1pbi1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHJlY3QgeD0iMzE4IiB5PSI1NCIgd2lkdGg9IjIwNCIgaGVpZ2h0PSI4OCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSI0MjAiIHk9Ijk0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC1zaXplOjEycHgiPlRlbnNvcjk8L3RleHQ+CiAgPHRleHQgeD0iNDIwIiB5PSIxMTIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPnNlcnZpY2UgYWRhcHRlcjwvdGV4dD4KPGxpbmUgeDE9IjUyMiIgeTE9Ijc0IiB4Mj0iNTg0IiB5Mj0iNzQiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWFsbG95ZGItYWRtaW4tYXBpKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxsaW5lIHgxPSI1ODgiIHkxPSIxMjgiIHgyPSI1MjYiIHkyPSIxMjgiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWFsbG95ZGItYWRtaW4tYXBpKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxyZWN0IHg9IjU4OCIgeT0iMzQiIHdpZHRoPSIyMzIiIGhlaWdodD0iMTI4IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjcwNCIgeT0iNjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTJweCI+QWxsb3lEQiBhZG1pbiBBUEk8L3RleHQ+Cjx0ZXh0IHg9IjcwNCIgeT0iOTQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5jbHVzdGVycyDCtyBpbnN0YW5jZXMgwrcgcmVhZCBwb29sczwvdGV4dD4KPHRleHQgeD0iNzA0IiB5PSIxMTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5kYXRhYmFzZSBmbGFncyDCtyByZXN0YXJ0PC90ZXh0Pgo8L3N2Zz4=)

Tensor9 translates RDS management requests to the backend API and returns RDS responses.

#### Limitations

Where Aurora and AlloyDB differ

* **RDS snapshots and restores are not supported.** AlloyDB runs automated and continuous backups, kept for the cluster's backup retention period, and Google supports point-in-time recovery from them. The adapter does not translate RDS snapshot, restore-from-snapshot or point-in-time restore requests, and deleting a cluster requires skipping the final snapshot.
* **RDS-driven failover is not supported.** AlloyDB fails the primary over to its standby in another zone on its own. The adapter does not translate `FailoverDBCluster`, readers are not promotion candidates, and promotion tiers must stay at the default.
* **Readers behave differently: each one is an AlloyDB read pool.** Each reader becomes its own read pool instance, with at most 20 read nodes per cluster. With more than one reader there is no shared cluster reader endpoint.
* **Instance classes behave differently: they map to fixed AlloyDB shapes.** Members use AlloyDB's N2 shapes from 2 to 96 vCPU with 8 GiB of memory per vCPU. Burstable classes have no equivalent, and a member's class cannot change after creation.
* **Parameter groups behave differently: Tensor9 keeps the group and applies its settings as flags.** Tensor9 keeps named parameter groups and their overrides. Supported explicit PostgreSQL parameters become AlloyDB database flags; the group object itself stays with Tensor9. RDS-specific parameters and settings outside AlloyDB's flag list are rejected.
* **Several Aurora features are not supported.** The Data API, global databases, stop / start, event subscriptions, RDS Proxy APIs, Serverless v2, I/O-Optimized storage, global write forwarding and customer-managed encryption keys are not available on this backend.

#### Other considerations

**Migration.** Moving the data is a one-time step, covered by this page's migration note: a logical dump and restore, or logical replication for a short cutover. This page describes how things work after cutover.

**Operations.** The customer owns the AlloyDB cluster in their Google Cloud project. Maintenance windows, quotas and pricing are Google's.

**Features and capacity.** The comparison table on this page lists feature and high-availability differences. Check the backend's pricing and capacity limits when you size the deployment.

#### 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.

##### Aurora PostgreSQL · Primary allocated compute

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Primary allocated compute. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Aurora PostgreSQL · 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/5093a6215cc60e989e6aaa44d2d789e1576fbbcbfd9bf9c2e491288484b0923d-light.svg)

![Aurora PostgreSQL · 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/88061eab0f48ac8953e71a3660ba8dfaf1ea7b2e3ddc204f658caa06b69e40d6-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) | Aurora PostgreSQL | Target scenario | AlloyDB for PostgreSQL | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | AlloyDB for PostgreSQL (one copy) | 191.88 | 191.88 |
| 0 | 0.00 | AlloyDB for PostgreSQL (two copies) | 353.77 | 353.77 |
| 1,460 | 211.70 | AlloyDB for PostgreSQL (one copy) | 191.88 | -19.82 |
| 1,460 | 211.70 | AlloyDB for PostgreSQL (two copies) | 353.77 | 142.07 |
| 2,920 | 423.40 | AlloyDB for PostgreSQL (one copy) | 353.77 | -69.63 |
| 2,920 | 423.40 | AlloyDB for PostgreSQL (two copies) | 677.53 | 254.13 |
| 5,840 | 846.80 | AlloyDB for PostgreSQL (one copy) | 677.53 | -169.27 |
| 5,840 | 846.80 | AlloyDB for PostgreSQL (two copies) | 1,325.07 | 478.27 |
| 11,680 | 1,693.60 | AlloyDB for PostgreSQL (one copy) | 1,325.07 | -368.53 |
| 11,680 | 1,693.60 | AlloyDB for PostgreSQL (two copies) | 2,620.15 | 926.55 |
| 23,360 | 3,387.20 | AlloyDB for PostgreSQL (one copy) | 2,620.15 | -767.05 |
| 23,360 | 3,387.20 | AlloyDB for PostgreSQL (two copies) | 5,210.31 | 1,823.11 |
| 46,720 | 6,774.40 | AlloyDB for PostgreSQL (one copy) | 5,210.31 | -1,564.09 |
| 46,720 | 6,774.40 | AlloyDB for PostgreSQL (two copies) | 10,390.62 | 3,616.22 |

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 |
| - | - | -: | - |
| AlloyDB for PostgreSQL (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| AlloyDB for PostgreSQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| AlloyDB for PostgreSQL (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| AlloyDB for PostgreSQL (one copy) | Origin list price · Database reads | 0 | USD/operations |
| AlloyDB for PostgreSQL (one copy) | Origin list price · Database writes | 0 | USD/operations |
| AlloyDB for PostgreSQL (one copy) | Target CPU / source CPU | 1 | multiplier |
| AlloyDB for PostgreSQL (one copy) | Target RAM / source RAM | 1 | multiplier |
| AlloyDB for PostgreSQL (one copy) | Target disk / source disk | 1 | multiplier |
| AlloyDB for PostgreSQL (one copy) | Target price guess · read | 0 | USD/read |
| AlloyDB for PostgreSQL (one copy) | Target price guess · write | 0 | USD/write |
| AlloyDB for PostgreSQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| AlloyDB for PostgreSQL (one copy) | Target list price · GiB-month | 0.299957 | USD/GiB-month |
| AlloyDB for PostgreSQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| AlloyDB for PostgreSQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| AlloyDB for PostgreSQL (one copy) | Target list price · network GiB | 0.12 | USD/network GiB |
| AlloyDB for PostgreSQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| AlloyDB for PostgreSQL (one copy) | Target list price · vCPU-hour | 0.06608 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (one copy) | Target list price · GiB-hour | 0.0112 | USD/GiB-hour |
| AlloyDB for PostgreSQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| AlloyDB for PostgreSQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| AlloyDB for PostgreSQL (one copy) | Target price guess · input token | 0 | USD/input token |
| AlloyDB for PostgreSQL (one copy) | Target price guess · output token | 0 | USD/output token |
| AlloyDB for PostgreSQL (one copy) | Target monthly base charge | 0 | USD/month |
| AlloyDB for PostgreSQL (one copy) | Target service minimum | 113.646 | USD/month |
| AlloyDB for PostgreSQL (one copy) | Minimum primary CPU | 2 | vCPU |
| AlloyDB for PostgreSQL (one copy) | Minimum primary RAM | 8 | GiB |
| AlloyDB for PostgreSQL (one copy) | Minimum primary disk | 100 | GiB |
| AlloyDB for PostgreSQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| AlloyDB for PostgreSQL (one copy) | Allocated share of provisioned cost | 1 | fraction |
| AlloyDB for PostgreSQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| AlloyDB for PostgreSQL (one copy) | Planning peak / mean work | 2 | multiplier |
| AlloyDB for PostgreSQL (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| AlloyDB for PostgreSQL (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| AlloyDB for PostgreSQL (one copy) | Planning disk utilization | 0.8 | fraction |
| AlloyDB for PostgreSQL (one copy) | Maintenance and log disk reserve | 20 | GiB |
| AlloyDB for PostgreSQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| AlloyDB for PostgreSQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| AlloyDB for PostgreSQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| AlloyDB for PostgreSQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| AlloyDB for PostgreSQL (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| AlloyDB for PostgreSQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| AlloyDB for PostgreSQL (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| AlloyDB for PostgreSQL (two copies) | Origin list price · Database reads | 0 | USD/operations |
| AlloyDB for PostgreSQL (two copies) | Origin list price · Database writes | 0 | USD/operations |
| AlloyDB for PostgreSQL (two copies) | Target CPU / source CPU | 1 | multiplier |
| AlloyDB for PostgreSQL (two copies) | Target RAM / source RAM | 1 | multiplier |
| AlloyDB for PostgreSQL (two copies) | Target disk / source disk | 1 | multiplier |
| AlloyDB for PostgreSQL (two copies) | Target price guess · read | 0 | USD/read |
| AlloyDB for PostgreSQL (two copies) | Target price guess · write | 0 | USD/write |
| AlloyDB for PostgreSQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| AlloyDB for PostgreSQL (two copies) | Target list price · GiB-month | 0.299957 | USD/GiB-month |
| AlloyDB for PostgreSQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| AlloyDB for PostgreSQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| AlloyDB for PostgreSQL (two copies) | Target list price · network GiB | 0.12 | USD/network GiB |
| AlloyDB for PostgreSQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| AlloyDB for PostgreSQL (two copies) | Target list price · vCPU-hour | 0.06608 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (two copies) | Target list price · GiB-hour | 0.0112 | USD/GiB-hour |
| AlloyDB for PostgreSQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| AlloyDB for PostgreSQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| AlloyDB for PostgreSQL (two copies) | Target price guess · input token | 0 | USD/input token |
| AlloyDB for PostgreSQL (two copies) | Target price guess · output token | 0 | USD/output token |
| AlloyDB for PostgreSQL (two copies) | Target monthly base charge | 0 | USD/month |
| AlloyDB for PostgreSQL (two copies) | Target service minimum | 113.646 | USD/month |
| AlloyDB for PostgreSQL (two copies) | Minimum primary CPU | 2 | vCPU |
| AlloyDB for PostgreSQL (two copies) | Minimum primary RAM | 8 | GiB |
| AlloyDB for PostgreSQL (two copies) | Minimum primary disk | 100 | GiB |
| AlloyDB for PostgreSQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| AlloyDB for PostgreSQL (two copies) | Allocated share of provisioned cost | 1 | fraction |
| AlloyDB for PostgreSQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| AlloyDB for PostgreSQL (two copies) | Planning peak / mean work | 2 | multiplier |
| AlloyDB for PostgreSQL (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| AlloyDB for PostgreSQL (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| AlloyDB for PostgreSQL (two copies) | Planning disk utilization | 0.8 | fraction |
| AlloyDB for PostgreSQL (two copies) | Maintenance and log disk reserve | 20 | GiB |
| AlloyDB for PostgreSQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| AlloyDB for PostgreSQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| AlloyDB for PostgreSQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| AlloyDB for PostgreSQL (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* AlloyDB bills each node's vCPU and memory (a high-availability primary is two nodes) and one regional storage pool by used GiB that every instance in the cluster shares, so storage is billed once however many copies run. The smallest machine is c4a-highmem-1 (1 vCPU, 8 GB; [https://docs.cloud.google.com/alloydb/docs/choose-machine-type](https://docs.cloud.google.com/alloydb/docs/choose-machine-type)). C4 and Z3 machine series, backups and committed-use discounts 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: AlloyDB n2-highmem-128 has 128 vCPUs and 864 GB ([https://docs.cloud.google.com/alloydb/docs/choose-machine-type](https://docs.cloud.google.com/alloydb/docs/choose-machine-type)); a cluster stores up to 128 TiB ([https://docs.cloud.google.com/alloydb/quotas](https://docs.cloud.google.com/alloydb/quotas)).
* 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)
* AlloyDB for PostgreSQL pricing: [https://cloud.google.com/alloydb/pricing](https://cloud.google.com/alloydb/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-b2d817a7f080d81019ebee2767d317c382dabcef` / `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), [AlloyDB for PostgreSQL pricing](https://cloud.google.com/alloydb/pricing).

##### Aurora PostgreSQL · Stored data

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Aurora PostgreSQL · 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/62014f2b35512254c28232c7e3d0ba63b3881f39ca4c9bb23460eb688b942d7b-light.svg)

![Aurora PostgreSQL · 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/014c2c8b15656380298fec14061dbd29ff185941f79b1ed0b0e33e1b579f7113-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) | Aurora PostgreSQL | Target scenario | AlloyDB for PostgreSQL | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | AlloyDB for PostgreSQL (one copy) | 191.88 | 191.88 |
| 0 | 0.00 | AlloyDB for PostgreSQL (two copies) | 353.77 | 353.77 |
| 10 | 1.00 | AlloyDB for PostgreSQL (one copy) | 191.88 | 190.88 |
| 10 | 1.00 | AlloyDB for PostgreSQL (two copies) | 353.77 | 352.77 |
| 100 | 10.00 | AlloyDB for PostgreSQL (one copy) | 206.88 | 196.88 |
| 100 | 10.00 | AlloyDB for PostgreSQL (two copies) | 368.76 | 358.76 |
| 1,000 | 100.00 | AlloyDB for PostgreSQL (one copy) | 544.33 | 444.33 |
| 1,000 | 100.00 | AlloyDB for PostgreSQL (two copies) | 706.21 | 606.21 |
| 10,000 | 1,000.00 | AlloyDB for PostgreSQL (one copy) | 3,918.85 | 2,918.85 |
| 10,000 | 1,000.00 | AlloyDB for PostgreSQL (two copies) | 4,080.73 | 3,080.73 |
| 100,000 | 10,000.00 | AlloyDB for PostgreSQL (one copy) | 37,664.01 | 27,664.01 |
| 100,000 | 10,000.00 | AlloyDB for PostgreSQL (two copies) | 37,825.89 | 27,825.89 |

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 125,025 GiB SSD at 100,000 GiB-month.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| AlloyDB for PostgreSQL (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| AlloyDB for PostgreSQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| AlloyDB for PostgreSQL (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| AlloyDB for PostgreSQL (one copy) | Origin list price · Database reads | 0 | USD/operations |
| AlloyDB for PostgreSQL (one copy) | Origin list price · Database writes | 0 | USD/operations |
| AlloyDB for PostgreSQL (one copy) | Target CPU / source CPU | 1 | multiplier |
| AlloyDB for PostgreSQL (one copy) | Target RAM / source RAM | 1 | multiplier |
| AlloyDB for PostgreSQL (one copy) | Target disk / source disk | 1 | multiplier |
| AlloyDB for PostgreSQL (one copy) | Target price guess · read | 0 | USD/read |
| AlloyDB for PostgreSQL (one copy) | Target price guess · write | 0 | USD/write |
| AlloyDB for PostgreSQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| AlloyDB for PostgreSQL (one copy) | Target list price · GiB-month | 0.299957 | USD/GiB-month |
| AlloyDB for PostgreSQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| AlloyDB for PostgreSQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| AlloyDB for PostgreSQL (one copy) | Target list price · network GiB | 0.12 | USD/network GiB |
| AlloyDB for PostgreSQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| AlloyDB for PostgreSQL (one copy) | Target list price · vCPU-hour | 0.06608 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (one copy) | Target list price · GiB-hour | 0.0112 | USD/GiB-hour |
| AlloyDB for PostgreSQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| AlloyDB for PostgreSQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| AlloyDB for PostgreSQL (one copy) | Target price guess · input token | 0 | USD/input token |
| AlloyDB for PostgreSQL (one copy) | Target price guess · output token | 0 | USD/output token |
| AlloyDB for PostgreSQL (one copy) | Target monthly base charge | 0 | USD/month |
| AlloyDB for PostgreSQL (one copy) | Target service minimum | 113.646 | USD/month |
| AlloyDB for PostgreSQL (one copy) | Minimum primary CPU | 2 | vCPU |
| AlloyDB for PostgreSQL (one copy) | Minimum primary RAM | 8 | GiB |
| AlloyDB for PostgreSQL (one copy) | Minimum primary disk | 100 | GiB |
| AlloyDB for PostgreSQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| AlloyDB for PostgreSQL (one copy) | Allocated share of provisioned cost | 1 | fraction |
| AlloyDB for PostgreSQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| AlloyDB for PostgreSQL (one copy) | Planning peak / mean work | 2 | multiplier |
| AlloyDB for PostgreSQL (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| AlloyDB for PostgreSQL (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| AlloyDB for PostgreSQL (one copy) | Planning disk utilization | 0.8 | fraction |
| AlloyDB for PostgreSQL (one copy) | Maintenance and log disk reserve | 20 | GiB |
| AlloyDB for PostgreSQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| AlloyDB for PostgreSQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| AlloyDB for PostgreSQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| AlloyDB for PostgreSQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| AlloyDB for PostgreSQL (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| AlloyDB for PostgreSQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| AlloyDB for PostgreSQL (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| AlloyDB for PostgreSQL (two copies) | Origin list price · Database reads | 0 | USD/operations |
| AlloyDB for PostgreSQL (two copies) | Origin list price · Database writes | 0 | USD/operations |
| AlloyDB for PostgreSQL (two copies) | Target CPU / source CPU | 1 | multiplier |
| AlloyDB for PostgreSQL (two copies) | Target RAM / source RAM | 1 | multiplier |
| AlloyDB for PostgreSQL (two copies) | Target disk / source disk | 1 | multiplier |
| AlloyDB for PostgreSQL (two copies) | Target price guess · read | 0 | USD/read |
| AlloyDB for PostgreSQL (two copies) | Target price guess · write | 0 | USD/write |
| AlloyDB for PostgreSQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| AlloyDB for PostgreSQL (two copies) | Target list price · GiB-month | 0.299957 | USD/GiB-month |
| AlloyDB for PostgreSQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| AlloyDB for PostgreSQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| AlloyDB for PostgreSQL (two copies) | Target list price · network GiB | 0.12 | USD/network GiB |
| AlloyDB for PostgreSQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| AlloyDB for PostgreSQL (two copies) | Target list price · vCPU-hour | 0.06608 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (two copies) | Target list price · GiB-hour | 0.0112 | USD/GiB-hour |
| AlloyDB for PostgreSQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| AlloyDB for PostgreSQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| AlloyDB for PostgreSQL (two copies) | Target price guess · input token | 0 | USD/input token |
| AlloyDB for PostgreSQL (two copies) | Target price guess · output token | 0 | USD/output token |
| AlloyDB for PostgreSQL (two copies) | Target monthly base charge | 0 | USD/month |
| AlloyDB for PostgreSQL (two copies) | Target service minimum | 113.646 | USD/month |
| AlloyDB for PostgreSQL (two copies) | Minimum primary CPU | 2 | vCPU |
| AlloyDB for PostgreSQL (two copies) | Minimum primary RAM | 8 | GiB |
| AlloyDB for PostgreSQL (two copies) | Minimum primary disk | 100 | GiB |
| AlloyDB for PostgreSQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| AlloyDB for PostgreSQL (two copies) | Allocated share of provisioned cost | 1 | fraction |
| AlloyDB for PostgreSQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| AlloyDB for PostgreSQL (two copies) | Planning peak / mean work | 2 | multiplier |
| AlloyDB for PostgreSQL (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| AlloyDB for PostgreSQL (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| AlloyDB for PostgreSQL (two copies) | Planning disk utilization | 0.8 | fraction |
| AlloyDB for PostgreSQL (two copies) | Maintenance and log disk reserve | 20 | GiB |
| AlloyDB for PostgreSQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| AlloyDB for PostgreSQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| AlloyDB for PostgreSQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| AlloyDB for PostgreSQL (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* AlloyDB bills each node's vCPU and memory (a high-availability primary is two nodes) and one regional storage pool by used GiB that every instance in the cluster shares, so storage is billed once however many copies run. The smallest machine is c4a-highmem-1 (1 vCPU, 8 GB; [https://docs.cloud.google.com/alloydb/docs/choose-machine-type](https://docs.cloud.google.com/alloydb/docs/choose-machine-type)). C4 and Z3 machine series, backups and committed-use discounts 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: AlloyDB n2-highmem-128 has 128 vCPUs and 864 GB ([https://docs.cloud.google.com/alloydb/docs/choose-machine-type](https://docs.cloud.google.com/alloydb/docs/choose-machine-type)); a cluster stores up to 128 TiB ([https://docs.cloud.google.com/alloydb/quotas](https://docs.cloud.google.com/alloydb/quotas)).
* 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)
* AlloyDB for PostgreSQL pricing: [https://cloud.google.com/alloydb/pricing](https://cloud.google.com/alloydb/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-b2d817a7f080d81019ebee2767d317c382dabcef` / `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), [AlloyDB for PostgreSQL pricing](https://cloud.google.com/alloydb/pricing).

##### Aurora PostgreSQL · Database writes

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Database writes. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Aurora PostgreSQL · 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/27a44168c81ab4e058b09ad14d8ece7dc2da033437ee73925d5b2ddcb9ecd884-light.svg)

![Aurora PostgreSQL · 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/2b019f878b599cd6d7f040042000a8d51cc9f0381615bea577fd99459aa45e02-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) | Aurora PostgreSQL | Target scenario | AlloyDB for PostgreSQL | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | AlloyDB for PostgreSQL (one copy) | 191.88 | 191.88 |
| 0 | 0.00 | AlloyDB for PostgreSQL (two copies) | 353.77 | 353.77 |
| 1 | 0.00 | AlloyDB for PostgreSQL (one copy) | 191.88 | 191.88 |
| 1 | 0.00 | AlloyDB for PostgreSQL (two copies) | 353.77 | 353.77 |
| 10 | 0.00 | AlloyDB for PostgreSQL (one copy) | 191.88 | 191.88 |
| 10 | 0.00 | AlloyDB for PostgreSQL (two copies) | 353.77 | 353.77 |
| 100 | 0.00 | AlloyDB for PostgreSQL (one copy) | 191.88 | 191.88 |
| 100 | 0.00 | AlloyDB for PostgreSQL (two copies) | 353.77 | 353.77 |
| 1,000 | 0.00 | AlloyDB for PostgreSQL (one copy) | 191.88 | 191.88 |
| 1,000 | 0.00 | AlloyDB for PostgreSQL (two copies) | 353.77 | 353.77 |
| 10,000 | 0.00 | AlloyDB for PostgreSQL (one copy) | 191.88 | 191.88 |
| 10,000 | 0.00 | AlloyDB for PostgreSQL (two copies) | 353.77 | 353.77 |

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 |
| - | - | -: | - |
| AlloyDB for PostgreSQL (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| AlloyDB for PostgreSQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| AlloyDB for PostgreSQL (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| AlloyDB for PostgreSQL (one copy) | Origin list price · Database reads | 0 | USD/operations |
| AlloyDB for PostgreSQL (one copy) | Origin list price · Database writes | 0 | USD/operations |
| AlloyDB for PostgreSQL (one copy) | Target CPU / source CPU | 1 | multiplier |
| AlloyDB for PostgreSQL (one copy) | Target RAM / source RAM | 1 | multiplier |
| AlloyDB for PostgreSQL (one copy) | Target disk / source disk | 1 | multiplier |
| AlloyDB for PostgreSQL (one copy) | Target price guess · read | 0 | USD/read |
| AlloyDB for PostgreSQL (one copy) | Target price guess · write | 0 | USD/write |
| AlloyDB for PostgreSQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| AlloyDB for PostgreSQL (one copy) | Target list price · GiB-month | 0.299957 | USD/GiB-month |
| AlloyDB for PostgreSQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| AlloyDB for PostgreSQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| AlloyDB for PostgreSQL (one copy) | Target list price · network GiB | 0.12 | USD/network GiB |
| AlloyDB for PostgreSQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| AlloyDB for PostgreSQL (one copy) | Target list price · vCPU-hour | 0.06608 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (one copy) | Target list price · GiB-hour | 0.0112 | USD/GiB-hour |
| AlloyDB for PostgreSQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| AlloyDB for PostgreSQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| AlloyDB for PostgreSQL (one copy) | Target price guess · input token | 0 | USD/input token |
| AlloyDB for PostgreSQL (one copy) | Target price guess · output token | 0 | USD/output token |
| AlloyDB for PostgreSQL (one copy) | Target monthly base charge | 0 | USD/month |
| AlloyDB for PostgreSQL (one copy) | Target service minimum | 113.646 | USD/month |
| AlloyDB for PostgreSQL (one copy) | Minimum primary CPU | 2 | vCPU |
| AlloyDB for PostgreSQL (one copy) | Minimum primary RAM | 8 | GiB |
| AlloyDB for PostgreSQL (one copy) | Minimum primary disk | 100 | GiB |
| AlloyDB for PostgreSQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| AlloyDB for PostgreSQL (one copy) | Allocated share of provisioned cost | 1 | fraction |
| AlloyDB for PostgreSQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| AlloyDB for PostgreSQL (one copy) | Planning peak / mean work | 2 | multiplier |
| AlloyDB for PostgreSQL (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| AlloyDB for PostgreSQL (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| AlloyDB for PostgreSQL (one copy) | Planning disk utilization | 0.8 | fraction |
| AlloyDB for PostgreSQL (one copy) | Maintenance and log disk reserve | 20 | GiB |
| AlloyDB for PostgreSQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| AlloyDB for PostgreSQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| AlloyDB for PostgreSQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| AlloyDB for PostgreSQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| AlloyDB for PostgreSQL (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| AlloyDB for PostgreSQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| AlloyDB for PostgreSQL (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| AlloyDB for PostgreSQL (two copies) | Origin list price · Database reads | 0 | USD/operations |
| AlloyDB for PostgreSQL (two copies) | Origin list price · Database writes | 0 | USD/operations |
| AlloyDB for PostgreSQL (two copies) | Target CPU / source CPU | 1 | multiplier |
| AlloyDB for PostgreSQL (two copies) | Target RAM / source RAM | 1 | multiplier |
| AlloyDB for PostgreSQL (two copies) | Target disk / source disk | 1 | multiplier |
| AlloyDB for PostgreSQL (two copies) | Target price guess · read | 0 | USD/read |
| AlloyDB for PostgreSQL (two copies) | Target price guess · write | 0 | USD/write |
| AlloyDB for PostgreSQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| AlloyDB for PostgreSQL (two copies) | Target list price · GiB-month | 0.299957 | USD/GiB-month |
| AlloyDB for PostgreSQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| AlloyDB for PostgreSQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| AlloyDB for PostgreSQL (two copies) | Target list price · network GiB | 0.12 | USD/network GiB |
| AlloyDB for PostgreSQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| AlloyDB for PostgreSQL (two copies) | Target list price · vCPU-hour | 0.06608 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (two copies) | Target list price · GiB-hour | 0.0112 | USD/GiB-hour |
| AlloyDB for PostgreSQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| AlloyDB for PostgreSQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| AlloyDB for PostgreSQL (two copies) | Target price guess · input token | 0 | USD/input token |
| AlloyDB for PostgreSQL (two copies) | Target price guess · output token | 0 | USD/output token |
| AlloyDB for PostgreSQL (two copies) | Target monthly base charge | 0 | USD/month |
| AlloyDB for PostgreSQL (two copies) | Target service minimum | 113.646 | USD/month |
| AlloyDB for PostgreSQL (two copies) | Minimum primary CPU | 2 | vCPU |
| AlloyDB for PostgreSQL (two copies) | Minimum primary RAM | 8 | GiB |
| AlloyDB for PostgreSQL (two copies) | Minimum primary disk | 100 | GiB |
| AlloyDB for PostgreSQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| AlloyDB for PostgreSQL (two copies) | Allocated share of provisioned cost | 1 | fraction |
| AlloyDB for PostgreSQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| AlloyDB for PostgreSQL (two copies) | Planning peak / mean work | 2 | multiplier |
| AlloyDB for PostgreSQL (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| AlloyDB for PostgreSQL (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| AlloyDB for PostgreSQL (two copies) | Planning disk utilization | 0.8 | fraction |
| AlloyDB for PostgreSQL (two copies) | Maintenance and log disk reserve | 20 | GiB |
| AlloyDB for PostgreSQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| AlloyDB for PostgreSQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| AlloyDB for PostgreSQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| AlloyDB for PostgreSQL (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* AlloyDB bills each node's vCPU and memory (a high-availability primary is two nodes) and one regional storage pool by used GiB that every instance in the cluster shares, so storage is billed once however many copies run. The smallest machine is c4a-highmem-1 (1 vCPU, 8 GB; [https://docs.cloud.google.com/alloydb/docs/choose-machine-type](https://docs.cloud.google.com/alloydb/docs/choose-machine-type)). C4 and Z3 machine series, backups and committed-use discounts 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: AlloyDB n2-highmem-128 has 128 vCPUs and 864 GB ([https://docs.cloud.google.com/alloydb/docs/choose-machine-type](https://docs.cloud.google.com/alloydb/docs/choose-machine-type)); a cluster stores up to 128 TiB ([https://docs.cloud.google.com/alloydb/quotas](https://docs.cloud.google.com/alloydb/quotas)).
* 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)
* AlloyDB for PostgreSQL pricing: [https://cloud.google.com/alloydb/pricing](https://cloud.google.com/alloydb/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-b2d817a7f080d81019ebee2767d317c382dabcef` / `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), [AlloyDB for PostgreSQL pricing](https://cloud.google.com/alloydb/pricing).

**Aurora PostgreSQL → AlloyDB for PostgreSQL: 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 | 96.48 |
| Target: Provisioned primary RAM | 65.41 |
| Target: Provisioned primary disk | 30.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** | **191.88** |

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.145 | USD/vCPU-hours |
| Origin list price · Primary memory | 0 | USD/GiB-hours |
| Origin list price · Primary provisioned storage | 0.1 | 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.299957 | 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.06608 | USD/vCPU-hour |
| Target list price · GiB-hour | 0.0112 | 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 | 113.646 | 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.

* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.

* AlloyDB bills each node's vCPU and memory (a high-availability primary is two nodes) and one regional storage pool by used GiB that every instance in the cluster shares, so storage is billed once however many copies run. The smallest machine is c4a-highmem-1 (1 vCPU, 8 GB; [https://docs.cloud.google.com/alloydb/docs/choose-machine-type](https://docs.cloud.google.com/alloydb/docs/choose-machine-type)). C4 and Z3 machine series, backups and committed-use discounts 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: AlloyDB n2-highmem-128 has 128 vCPUs and 864 GB ([https://docs.cloud.google.com/alloydb/docs/choose-machine-type](https://docs.cloud.google.com/alloydb/docs/choose-machine-type)); a cluster stores up to 128 TiB ([https://docs.cloud.google.com/alloydb/quotas](https://docs.cloud.google.com/alloydb/quotas)).

* 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-b2d817a7f080d81019ebee2767d317c382dabcef` / `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), [AlloyDB for PostgreSQL pricing](https://cloud.google.com/alloydb/pricing).

### AlloyDB for PostgreSQL (RDS proxy)

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| IAM database authentication (rds-db:connect tokens) | Access | Supported | Most usage | RDS authentication tokens for users granted rds\_iam; the proxy verifies the signature and authorizes rds-db:connect on the cluster resource ID and user, then logs in as that role |
| AWS/Aurora-proprietary SQL: aws\_s3.*, aws\_lambda.invoke, Aurora ML, apg\_plan\_mgmt and other aurora\_* functions | SQL functions | Out of scope | Full surface | AWS and Aurora extension functions with no counterpart on AlloyDB; a query calling them fails |
| Aurora discovery functions: aurora\_db\_instance\_identifier(), aurora\_list\_builtins(), aurora\_replica\_status() | SQL functions | Partial | Most usage | served for drivers that discover Aurora topology; aurora\_replica\_status() leaves replica lag empty |
| pgwire protocol through the Tensor9 PostgreSQL proxy (application SQL) | Wire protocol | Supported | Common | wire-compatible PostgreSQL; the proxy relays each session unchanged over its own AlloyDB connection as the same SQL user, without pooling or rewriting SQL |

#### How it works

Your application's PostgreSQL driver connects to Tensor9's PostgreSQL proxy at the endpoint RDS reports. The proxy checks the login, picks the backend the endpoint names, and opens its own connection to AlloyDB for PostgreSQL as the same SQL user. It passes the session through unchanged: it does not pool connections, rewrite SQL or cache results. These database requests are the **data plane**, and on this backend they pass through Tensor9.

Management requests, such as creating and describing databases, parameter changes and reboots, are the **control plane**. Tensor9 runs the RDS API in the customer's Cloud Adapter deployment and translates these requests to AlloyDB for PostgreSQL's management API, exactly as for the backend without the proxy.

Creating the cluster on this backend, rather than on plain AlloyDB, gives you what the proxy adds: IAM database authentication with RDS tokens; a reader endpoint that spreads connections across every read pool and falls back to the writer when no reader is available, as Aurora's does; a certificate authority that `verify-full` clients can pin; and, on Kubernetes installations, the cluster's security groups checked against each client's own address.

![Database requests (SQL over pgwire) go through the Tensor9 PostgreSQL proxy to AlloyDB. The Tensor9 service adapter translates RDS API management calls to AlloyDB admin API.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgcGd3aXJlKSBnbyB0aHJvdWdoIHRoZSBUZW5zb3I5IFBvc3RncmVTUUwgcHJveHkgdG8gQWxsb3lEQi4gVGhlIFRlbnNvcjkgc2VydmljZSBhZGFwdGVyIHRyYW5zbGF0ZXMgUkRTIEFQSSBtYW5hZ2VtZW50IGNhbGxzIHRvIEFsbG95REIgYWRtaW4gQVBJLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaHAtYWxsb3lkYiIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNyIgbWFya2VySGVpZ2h0PSI3IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+PHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBzdHlsZT0iZmlsbDojOTRhM2I4Ii8+PC9tYXJrZXI+PC9kZWZzPgo8cmVjdCB4PSI4IiB5PSIzNCIgd2lkdGg9IjgyMCIgaGVpZ2h0PSIyMDYiIHJ4PSIxNiIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0cm9rZS1kYXNoYXJyYXk9IjUgNSIgc3R5bGU9ImZpbGw6I2Y4ZmFmYztzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSIyNiIgeT0iNTQiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4OyBmaWxsOiMwNDc4NTciPk9OIEdPT0dMRSBDTE9VRDwvdGV4dD4KPHN2ZyB4PSI3OTIiIHk9IjM2IiB3aWR0aD0iMTYiIGhlaWdodD0iMTYiIHZpZXdCb3g9IjAgLTI1IDI1NiAyNTYiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiPjxnPiA8cGF0aCBkPSJNMTcwLjI1MTcsNTYuODE4NiBMMTkyLjUwNDcsMzQuNTY1NiBMMTkzLjk4NzcsMjUuMTk1NiBDMTUzLjQzNjcsLTExLjY3NzQgODguOTc1NywtNy40OTY0IDUyLjQyMDcsMzMuOTE5NiBDNDIuMjY2Nyw0NS40MjI2IDM0LjczMzcsNTkuNzYzNiAzMC43MTY3LDc0LjU3MjYgTDM4LjY4NjcsNzMuNDQ5NiBMODMuMTkxNyw2Ni4xMTA2IEw4Ni42Mjc3LDYyLjU5NjYgQzEwNi40MjQ3LDQwLjg1NDYgMTM5Ljg5NzcsMzcuOTI5NiAxNjIuNzU1Nyw1Ni40Mjg2IEwxNzAuMjUxNyw1Ni44MTg2IFoiIGZpbGw9IiNFQTQzMzUiPiA8L3BhdGg+IDxwYXRoIGQ9Ik0yMjQuMjA0OCw3My45MTgyIEMyMTkuMDg5OCw1NS4wODIyIDIwOC41ODg4LDM4LjE0OTIgMTkzLjk4NzgsMjUuMTk2MiBMMTYyLjc1NTgsNTYuNDI4MiBDMTc1Ljk0MzgsNjcuMjA0MiAxODMuNDU2OCw4My40MzgyIDE4My4xMzQ4LDEwMC40NjUyIEwxODMuMTM0OCwxMDYuMDA5MiBDMTk4LjQ4NTgsMTA2LjAwOTIgMjEwLjkzMTgsMTE4LjQ1NDIgMjEwLjkzMTgsMTMzLjgwNTIgQzIxMC45MzE4LDE0OS4xNTcyIDE5OC40ODU4LDE2MS4yOTAyIDE4My4xMzQ4LDE2MS4yOTAyIEwxMjcuNDYzOCwxNjEuMjkwMiBMMTIxLjk5NzgsMTY3LjIyNDIgTDEyMS45OTc4LDIwMC41NjQyIEwxMjcuNDYzOCwyMDUuNzk1MiBMMTgzLjEzNDgsMjA1Ljc5NTIgQzIyMy4wNjQ4LDIwNi4xMDYyIDI1NS42ODY4LDE3NC4zMDEyIDI1NS45OTc4LDEzNC4zNzEyIEMyNTYuMTg1OCwxMTAuMTY4MiAyNDQuMjUyOCw4Ny40NzgyIDIyNC4yMDQ4LDczLjkxODIiIGZpbGw9IiM0Mjg1RjQiPiA8L3BhdGg+IDxwYXRoIGQ9Ik03MS44NzA0LDIwNS43OTU3IEwxMjcuNDYzNCwyMDUuNzk1NyBMMTI3LjQ2MzQsMTYxLjI4OTcgTDcxLjg3MDQsMTYxLjI4OTcgQzY3LjkwOTQsMTYxLjI4ODcgNjQuMDczNCwxNjAuNDM3NyA2MC40NzE0LDE1OC43OTE3IEw1Mi41ODQ0LDE2MS4yMTE3IEwzMC4xNzU0LDE4My40NjQ3IEwyOC4yMjM0LDE5MS4wMzg3IEM0MC43OTA0LDIwMC41Mjc3IDU2LjEyMzQsMjA1Ljg2MzcgNzEuODcwNCwyMDUuNzk1NyIgZmlsbD0iIzM0QTg1MyI+IDwvcGF0aD4gPHBhdGggZD0iTTcxLjg3MDQsNjEuNDI1NSBDMzEuOTM5NCw2MS42NjM1IC0wLjIzNjYsOTQuMjI3NSAwLjAwMTQsMTM0LjE1NzUgQzAuMTM0NCwxNTYuNDU1NSAxMC41NDg0LDE3Ny40NDU1IDI4LjIyMzQsMTkxLjAzODUgTDYwLjQ3MTQsMTU4Ljc5MTUgQzQ2LjQ4MDQsMTUyLjQ3MDUgNDAuMjYzNCwxMzYuMDA1NSA0Ni41ODQ0LDEyMi4wMTU1IEM1Mi45MDQ0LDEwOC4wMjU1IDY5LjM3MDQsMTAxLjgwODUgODMuMzU5NCwxMDguMTI4NSBDODkuNTI0NCwxMTAuOTEzNSA5NC40NjE0LDExNS44NTE1IDk3LjI0NjQsMTIyLjAxNTUgTDEyOS40OTQ0LDg5Ljc2ODUgQzExNS43NzM0LDcxLjgzMTUgOTQuNDUzNCw2MS4zNDQ1IDcxLjg3MDQsNjEuNDI1NSIgZmlsbD0iI0ZCQkMwNSI+IDwvcGF0aD4gPC9nPjwvc3ZnPgo8cmVjdCB4PSIyNiIgeT0iODgiIHdpZHRoPSIxMjgiIGhlaWdodD0iMTEyIiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjkwIiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTNweCI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIxNDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5Qb3N0Z3JlU1FMIGRyaXZlcjwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjE2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij51bmNoYW5nZWQ8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iNjYiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4OyBmaWxsOiMwNDc4NTciPkRBVEFCQVNFIFJFUVVFU1RTIMK3IFZJQSBURU5TT1I5IFBST1hZPC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTA4IiB4Mj0iMzAwIiB5Mj0iMTA4IiBzdHJva2Utd2lkdGg9IjIuMiIgbWFya2VyLWVuZD0idXJsKCNhaHAtYWxsb3lkYikiIHN0eWxlPSJzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSIyMjciIHk9IjEwMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZpbGw6IzA0Nzg1NyI+U1FMIG92ZXIgcGd3aXJlPC90ZXh0Pgo8cmVjdCB4PSIzMDQiIHk9Ijc2IiB3aWR0aD0iMTgwIiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjM5NCIgeT0iOTgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXNpemU6MTJweCI+VGVuc29yOSBTUUwgcHJveHk8L3RleHQ+Cjx0ZXh0IHg9IjM5NCIgeT0iMTE1IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij5JQU0gbG9naW4gwrcgZW5kcG9pbnQgcm91dGluZzwvdGV4dD4KPHRleHQgeD0iMzk0IiB5PSIxMzAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPm9uZSBiYWNrZW5kIHNlc3Npb24gZWFjaDwvdGV4dD4KPGxpbmUgeDE9IjQ4NCIgeTE9IjEwOCIgeDI9IjYxMCIgeTI9IjEwOCIgc3Ryb2tlLXdpZHRoPSIyLjIiIG1hcmtlci1lbmQ9InVybCgjYWhwLWFsbG95ZGIpIiBzdHlsZT0ic3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iNTQ3IiB5PSIxMDAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiMwNDc4NTciPm93biBzZXNzaW9uPC90ZXh0Pgo8dGV4dCB4PSIzOTQiIHk9IjE1NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPm9uZSBwcm94eSBkZXBsb3ltZW50IHBlciBjbHVzdGVyPC90ZXh0Pgo8cmVjdCB4PSI2MTQiIHk9Ijc2IiB3aWR0aD0iMTk2IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+CjxzdmcgeD0iNzg2IiB5PSI1NiIgd2lkdGg9IjIwIiBoZWlnaHQ9IjIwIiB2aWV3Qm94PSIwIDAgNDMyLjA3MSA0NDUuMzgzIiBwcmVzZXJ2ZUFzcGVjdFJhdGlvPSJ4TWlkWU1pZCBtZWV0Ij48ZyBzdHlsZT0iZmlsbC1ydWxlOm5vbnplcm87Y2xpcC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLW1pdGVybGltaXQ6NCI+IDwvZz4gPGcgc3R5bGU9ImZpbGwtcnVsZTpub256ZXJvO2NsaXAtcnVsZTpub256ZXJvO2ZpbGw6bm9uZTtzdHJva2U6I0ZGRkZGRjtzdHJva2Utd2lkdGg6MTIuNDY1MTtzdHJva2UtbGluZWNhcDpyb3VuZDtzdHJva2UtbGluZWpvaW46cm91bmQ7c3Ryb2tlLW1pdGVybGltaXQ6NCI+IDxwYXRoIGQ9Ik0zMjMuMjA1LDMyNC4yMjdjMi44MzMtMjMuNjAxLDEuOTg0LTI3LjA2MiwxOS41NjMtMjMuMjM5bDQuNDYzLDAuMzkyYzEzLjUxNywwLjYxNSwzMS4xOTktMi4xNzQsNDEuNTg3LTdjMjIuMzYyLTEwLjM3NiwzNS42MjItMjcuNywxMy41NzItMjMuMTQ4Yy01MC4yOTcsMTAuMzc2LTUzLjc1NS02LjY1NS01My43NTUtNi42NTVjNTMuMTExLTc4LjgwMyw3NS4zMTMtMTc4LjgzNiw1Ni4xNDktMjAzLjMyMiBDMzUyLjUxNC01LjUzNCwyNjIuMDM2LDI2LjA0OSwyNjAuNTIyLDI2Ljg2OWwtMC40ODIsMC4wODljLTkuOTM4LTIuMDYyLTIxLjA2LTMuMjk0LTMzLjU1NC0zLjQ5NmMtMjIuNzYxLTAuMzc0LTQwLjAzMiw1Ljk2Ny01My4xMzMsMTUuOTA0YzAsMC0xNjEuNDA4LTY2LjQ5OC0xNTMuODk5LDgzLjYyOGMxLjU5NywzMS45MzYsNDUuNzc3LDI0MS42NTUsOTguNDcsMTc4LjMxIGMxOS4yNTktMjMuMTYzLDM3Ljg3MS00Mi43NDgsMzcuODcxLTQyLjc0OGM5LjI0Miw2LjE0LDIwLjMwNyw5LjI3MiwzMS45MTIsOC4xNDdsMC44OTctMC43NjVjLTAuMjgxLDIuODc2LTAuMTU3LDUuNjg5LDAuMzU5LDkuMDE5Yy0xMy41NzIsMTUuMTY3LTkuNTg0LDE3LjgzLTM2LjcyMywyMy40MTZjLTI3LjQ1Nyw1LjY1OS0xMS4zMjYsMTUuNzM0LTAuNzk3LDE4LjM2N2MxMi43NjgsMy4xOTMsNDIuMzA1LDcuNzE2LDYyLjI2OC0yMC4yMjQgbC0wLjc5NSwzLjE4OGM1LjMyNSw0LjI2LDQuOTY1LDMwLjYxOSw1LjcyLDQ5LjQ1MmMwLjc1NiwxOC44MzQsMi4wMTcsMzYuNDA5LDUuODU2LDQ2Ljc3MWMzLjgzOSwxMC4zNiw4LjM2OSwzNy4wNSw0NC4wMzYsMjkuNDA2YzI5LjgwOS02LjM4OCw1Mi42LTE1LjU4Miw1NC42NzctMTAxLjEwNyIgc3R5bGU9ImZpbGw6IzAwMDAwMDtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MzcuMzk1MztzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNNDAyLjM5NSwyNzEuMjNjLTUwLjMwMiwxMC4zNzYtNTMuNzYtNi42NTUtNTMuNzYtNi42NTVjNTMuMTExLTc4LjgwOCw3NS4zMTMtMTc4Ljg0Myw1Ni4xNTMtMjAzLjMyNmMtNTIuMjctNjYuNzg1LTE0Mi43NTItMzUuMi0xNDQuMjYyLTM0LjM4bC0wLjQ4NiwwLjA4N2MtOS45MzgtMi4wNjMtMjEuMDYtMy4yOTItMzMuNTYtMy40OTZjLTIyLjc2MS0wLjM3My00MC4wMjYsNS45NjctNTMuMTI3LDE1LjkwMiBjMCwwLTE2MS40MTEtNjYuNDk1LTE1My45MDQsODMuNjNjMS41OTcsMzEuOTM4LDQ1Ljc3NiwyNDEuNjU3LDk4LjQ3MSwxNzguMzEyYzE5LjI2LTIzLjE2MywzNy44NjktNDIuNzQ4LDM3Ljg2OS00Mi43NDhjOS4yNDMsNi4xNCwyMC4zMDgsOS4yNzIsMzEuOTA4LDguMTQ3bDAuOTAxLTAuNzY1Yy0wLjI4LDIuODc2LTAuMTUyLDUuNjg5LDAuMzYxLDkuMDE5Yy0xMy41NzUsMTUuMTY3LTkuNTg2LDE3LjgzLTM2LjcyMywyMy40MTYgYy0yNy40NTksNS42NTktMTEuMzI4LDE1LjczNC0wLjc5NiwxOC4zNjdjMTIuNzY4LDMuMTkzLDQyLjMwNyw3LjcxNiw2Mi4yNjYtMjAuMjI0bC0wLjc5NiwzLjE4OGM1LjMxOSw0LjI2LDkuMDU0LDI3LjcxMSw4LjQyOCw0OC45NjljLTAuNjI2LDIxLjI1OS0xLjA0NCwzNS44NTQsMy4xNDcsNDcuMjU0YzQuMTkxLDExLjQsOC4zNjgsMzcuMDUsNDQuMDQyLDI5LjQwNmMyOS44MDktNi4zODgsNDUuMjU2LTIyLjk0Miw0Ny40MDUtNTAuNTU1IGMxLjUyNS0xOS42MzEsNC45NzYtMTYuNzI5LDUuMTk0LTM0LjI4bDIuNzY4LTguMzA5YzMuMTkyLTI2LjYxMSwwLjUwNy0zNS4xOTYsMTguODcyLTMxLjIwM2w0LjQ2MywwLjM5MmMxMy41MTcsMC42MTUsMzEuMjA4LTIuMTc0LDQxLjU5MS03YzIyLjM1OC0xMC4zNzYsMzUuNjE4LTI3LjcsMTMuNTczLTIzLjE0OHoiIHN0eWxlPSJmaWxsOiMzMzY3OTE7c3Ryb2tlOm5vbmUiLz4gPHBhdGggZD0iTTIxNS44NjYsMjg2LjQ4NGMtMS4zODUsNDkuNTE2LDAuMzQ4LDk5LjM3Nyw1LjE5MywxMTEuNDk1YzQuODQ4LDEyLjExOCwxNS4yMjMsMzUuNjg4LDUwLjksMjguMDQ1YzI5LjgwNi02LjM5LDQwLjY1MS0xOC43NTYsNDUuMzU3LTQ2LjA1MWMzLjQ2Ni0yMC4wODIsMTAuMTQ4LTc1Ljg1NCwxMS4wMDUtODcuMjgxIi8+IDxwYXRoIGQ9Ik0xNzMuMTA0LDM4LjI1NmMwLDAtMTYxLjUyMS02Ni4wMTYtMTU0LjAxMiw4NC4xMDljMS41OTcsMzEuOTM4LDQ1Ljc3OSwyNDEuNjY0LDk4LjQ3MywxNzguMzE2YzE5LjI1Ni0yMy4xNjYsMzYuNjcxLTQxLjMzNSwzNi42NzEtNDEuMzM1Ii8+IDxwYXRoIGQ9Ik0yNjAuMzQ5LDI2LjIwN2MtNS41OTEsMS43NTMsODkuODQ4LTM0Ljg4OSwxNDQuMDg3LDM0LjQxN2MxOS4xNTksMjQuNDg0LTMuMDQzLDEyNC41MTktNTYuMTUzLDIwMy4zMjkiLz4gPHBhdGggZD0iTTM0OC4yODIsMjYzLjk1M2MwLDAsMy40NjEsMTcuMDM2LDUzLjc2NCw2LjY1M2MyMi4wNC00LjU1Miw4Ljc3NiwxMi43NzQtMTMuNTc3LDIzLjE1NWMtMTguMzQ1LDguNTE0LTU5LjQ3NCwxMC42OTYtNjAuMTQ2LTEuMDY5Yy0xLjcyOS0zMC4zNTUsMjEuNjQ3LTIxLjEzMywxOS45Ni0yOC43MzljLTEuNTI1LTYuODUtMTEuOTc5LTEzLjU3My0xOC44OTQtMzAuMzM4IGMtNi4wMzctMTQuNjMzLTgyLjc5Ni0xMjYuODQ5LDIxLjI4Ny0xMTAuMTgzYzMuODEzLTAuNzg5LTI3LjE0Ni05OS4wMDItMTI0LjU1My0xMDAuNTk5Yy05Ny4zODUtMS41OTctOTQuMTksMTE5Ljc2Mi05NC4xOSwxMTkuNzYyIiBzdHlsZT0ic3Ryb2tlLWxpbmVqb2luOmJldmVsIi8+IDxwYXRoIGQ9Ik0xODguNjA0LDI3NC4zMzRjLTEzLjU3NywxNS4xNjYtOS41ODQsMTcuODI5LTM2LjcyMywyMy40MTdjLTI3LjQ1OSw1LjY2LTExLjMyNiwxNS43MzMtMC43OTcsMTguMzY1YzEyLjc2OCwzLjE5NSw0Mi4zMDcsNy43MTgsNjIuMjY2LTIwLjIyOWM2LjA3OC04LjUwOS0wLjAzNi0yMi4wODYtOC4zODUtMjUuNTQ3Yy00LjAzNC0xLjY3MS05LjQyOC0zLjc2NS0xNi4zNjEsMy45OTR6Ii8+IDxwYXRoIGQ9Ik0xODcuNzE1LDI3NC4wNjljLTEuMzY4LTguOTE3LDIuOTMtMTkuNTI4LDcuNTM2LTMxLjk0MmM2LjkyMi0xOC42MjYsMjIuODkzLTM3LjI1NSwxMC4xMTctOTYuMzM5Yy05LjUyMy00NC4wMjktNzMuMzk2LTkuMTYzLTczLjQzNi0zLjE5M2MtMC4wMzksNS45NjgsMi44ODksMzAuMjYtMS4wNjcsNTguNTQ4Yy01LjE2MiwzNi45MTMsMjMuNDg4LDY4LjEzMiw1Ni40NzksNjQuOTM4Ii8+IDxwYXRoIGQ9Ik0xNzIuNTE3LDE0MS43Yy0wLjI4OCwyLjAzOSwzLjczMyw3LjQ4LDguOTc2LDguMjA3YzUuMjM0LDAuNzMsOS43MTQtMy41MjIsOS45OTgtNS41NTljMC4yODQtMi4wMzktMy43MzItNC4yODUtOC45NzctNS4wMTVjLTUuMjM3LTAuNzMxLTkuNzE5LDAuMzMzLTkuOTk2LDIuMzY3eiIgc3R5bGU9ImZpbGw6I0ZGRkZGRjtzdHJva2Utd2lkdGg6NC4xNTU7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTMzMS45NDEsMTM3LjU0M2MwLjI4NCwyLjAzOS0zLjczMiw3LjQ4LTguOTc2LDguMjA3Yy01LjIzOCwwLjczLTkuNzE4LTMuNTIyLTEwLjAwNS01LjU1OWMtMC4yNzctMi4wMzksMy43NC00LjI4NSw4Ljk3OS01LjAxNWM1LjIzOS0wLjczLDkuNzE4LDAuMzMzLDEwLjAwMiwyLjM2OHoiIHN0eWxlPSJmaWxsOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjIuMDc3NTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNMzUwLjY3NiwxMjMuNDMyYzAuODYzLDE1Ljk5NC0zLjQ0NSwyNi44ODgtMy45ODgsNDMuOTE0Yy0wLjgwNCwyNC43NDgsMTEuNzk5LDUzLjA3NC03LjE5MSw4MS40MzUiLz4gPHBhdGggZD0iTTAsNjAuMjMyIiBzdHlsZT0ic3Ryb2tlLXdpZHRoOjMiLz4gPC9nPjwvc3ZnPgo8dGV4dCB4PSI3MTIiIHk9IjEwMyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMnB4Ij5BbGxveURCPC90ZXh0Pgo8dGV4dCB4PSI3MTIiIHk9IjEyMiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPlBvc3RncmVTUUwgZW5naW5lPC90ZXh0Pgo8dGV4dCB4PSIyMDAiIHk9IjE3NiIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjgiPk1BTkFHRU1FTlQgUkVRVUVTVFMgwrcgVklBIFRFTlNPUjk8L3RleHQ+CjxsaW5lIHgxPSIxNTQiIHkxPSIyMDYiIHgyPSIzMDAiIHkyPSIyMDYiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaHAtYWxsb3lkYikiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8dGV4dCB4PSIyMjciIHk9IjE5OCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGIiPlJEUyBBUEk8L3RleHQ+CjxyZWN0IHg9IjMwNCIgeT0iMTgyIiB3aWR0aD0iMTgwIiBoZWlnaHQ9IjUwIiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjM5NCIgeT0iMjAzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC1zaXplOjEycHgiPlRlbnNvcjk8L3RleHQ+Cjx0ZXh0IHg9IjM5NCIgeT0iMjIwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij5zZXJ2aWNlIGFkYXB0ZXI8L3RleHQ+CjxsaW5lIHgxPSI0ODQiIHkxPSIyMDYiIHgyPSI2MTAiIHkyPSIyMDYiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaHAtYWxsb3lkYikiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8cmVjdCB4PSI2MTQiIHk9IjE4MiIgd2lkdGg9IjE5NiIgaGVpZ2h0PSI1MCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSI3MTIiIHk9IjIwMyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMS41cHgiPkFsbG95REIgYWRtaW4gQVBJPC90ZXh0Pgo8dGV4dCB4PSI3MTIiIHk9IjIyMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPnRoZSBiYWNrZW5kJ3MgbWFuYWdlbWVudCBBUEk8L3RleHQ+Cjwvc3ZnPg==)

![Database requests (SQL over pgwire) go through the Tensor9 PostgreSQL proxy to AlloyDB. The Tensor9 service adapter translates RDS API management calls to AlloyDB admin API.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgcGd3aXJlKSBnbyB0aHJvdWdoIHRoZSBUZW5zb3I5IFBvc3RncmVTUUwgcHJveHkgdG8gQWxsb3lEQi4gVGhlIFRlbnNvcjkgc2VydmljZSBhZGFwdGVyIHRyYW5zbGF0ZXMgUkRTIEFQSSBtYW5hZ2VtZW50IGNhbGxzIHRvIEFsbG95REIgYWRtaW4gQVBJLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaHAtYWxsb3lkYiIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNyIgbWFya2VySGVpZ2h0PSI3IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+PHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBzdHlsZT0iZmlsbDojNjQ3NDhiIi8+PC9tYXJrZXI+PC9kZWZzPgo8cmVjdCB4PSI4IiB5PSIzNCIgd2lkdGg9IjgyMCIgaGVpZ2h0PSIyMDYiIHJ4PSIxNiIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0cm9rZS1kYXNoYXJyYXk9IjUgNSIgc3R5bGU9ImZpbGw6IzBmMTcyYTtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSIyNiIgeT0iNTQiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiM2ZWU3YjciPk9OIEdPT0dMRSBDTE9VRDwvdGV4dD4KPHN2ZyB4PSI3OTIiIHk9IjM2IiB3aWR0aD0iMTYiIGhlaWdodD0iMTYiIHZpZXdCb3g9IjAgLTI1IDI1NiAyNTYiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiPjxnPiA8cGF0aCBkPSJNMTcwLjI1MTcsNTYuODE4NiBMMTkyLjUwNDcsMzQuNTY1NiBMMTkzLjk4NzcsMjUuMTk1NiBDMTUzLjQzNjcsLTExLjY3NzQgODguOTc1NywtNy40OTY0IDUyLjQyMDcsMzMuOTE5NiBDNDIuMjY2Nyw0NS40MjI2IDM0LjczMzcsNTkuNzYzNiAzMC43MTY3LDc0LjU3MjYgTDM4LjY4NjcsNzMuNDQ5NiBMODMuMTkxNyw2Ni4xMTA2IEw4Ni42Mjc3LDYyLjU5NjYgQzEwNi40MjQ3LDQwLjg1NDYgMTM5Ljg5NzcsMzcuOTI5NiAxNjIuNzU1Nyw1Ni40Mjg2IEwxNzAuMjUxNyw1Ni44MTg2IFoiIGZpbGw9IiNFQTQzMzUiPiA8L3BhdGg+IDxwYXRoIGQ9Ik0yMjQuMjA0OCw3My45MTgyIEMyMTkuMDg5OCw1NS4wODIyIDIwOC41ODg4LDM4LjE0OTIgMTkzLjk4NzgsMjUuMTk2MiBMMTYyLjc1NTgsNTYuNDI4MiBDMTc1Ljk0MzgsNjcuMjA0MiAxODMuNDU2OCw4My40MzgyIDE4My4xMzQ4LDEwMC40NjUyIEwxODMuMTM0OCwxMDYuMDA5MiBDMTk4LjQ4NTgsMTA2LjAwOTIgMjEwLjkzMTgsMTE4LjQ1NDIgMjEwLjkzMTgsMTMzLjgwNTIgQzIxMC45MzE4LDE0OS4xNTcyIDE5OC40ODU4LDE2MS4yOTAyIDE4My4xMzQ4LDE2MS4yOTAyIEwxMjcuNDYzOCwxNjEuMjkwMiBMMTIxLjk5NzgsMTY3LjIyNDIgTDEyMS45OTc4LDIwMC41NjQyIEwxMjcuNDYzOCwyMDUuNzk1MiBMMTgzLjEzNDgsMjA1Ljc5NTIgQzIyMy4wNjQ4LDIwNi4xMDYyIDI1NS42ODY4LDE3NC4zMDEyIDI1NS45OTc4LDEzNC4zNzEyIEMyNTYuMTg1OCwxMTAuMTY4MiAyNDQuMjUyOCw4Ny40NzgyIDIyNC4yMDQ4LDczLjkxODIiIGZpbGw9IiM0Mjg1RjQiPiA8L3BhdGg+IDxwYXRoIGQ9Ik03MS44NzA0LDIwNS43OTU3IEwxMjcuNDYzNCwyMDUuNzk1NyBMMTI3LjQ2MzQsMTYxLjI4OTcgTDcxLjg3MDQsMTYxLjI4OTcgQzY3LjkwOTQsMTYxLjI4ODcgNjQuMDczNCwxNjAuNDM3NyA2MC40NzE0LDE1OC43OTE3IEw1Mi41ODQ0LDE2MS4yMTE3IEwzMC4xNzU0LDE4My40NjQ3IEwyOC4yMjM0LDE5MS4wMzg3IEM0MC43OTA0LDIwMC41Mjc3IDU2LjEyMzQsMjA1Ljg2MzcgNzEuODcwNCwyMDUuNzk1NyIgZmlsbD0iIzM0QTg1MyI+IDwvcGF0aD4gPHBhdGggZD0iTTcxLjg3MDQsNjEuNDI1NSBDMzEuOTM5NCw2MS42NjM1IC0wLjIzNjYsOTQuMjI3NSAwLjAwMTQsMTM0LjE1NzUgQzAuMTM0NCwxNTYuNDU1NSAxMC41NDg0LDE3Ny40NDU1IDI4LjIyMzQsMTkxLjAzODUgTDYwLjQ3MTQsMTU4Ljc5MTUgQzQ2LjQ4MDQsMTUyLjQ3MDUgNDAuMjYzNCwxMzYuMDA1NSA0Ni41ODQ0LDEyMi4wMTU1IEM1Mi45MDQ0LDEwOC4wMjU1IDY5LjM3MDQsMTAxLjgwODUgODMuMzU5NCwxMDguMTI4NSBDODkuNTI0NCwxMTAuOTEzNSA5NC40NjE0LDExNS44NTE1IDk3LjI0NjQsMTIyLjAxNTUgTDEyOS40OTQ0LDg5Ljc2ODUgQzExNS43NzM0LDcxLjgzMTUgOTQuNDUzNCw2MS4zNDQ1IDcxLjg3MDQsNjEuNDI1NSIgZmlsbD0iI0ZCQkMwNSI+IDwvcGF0aD4gPC9nPjwvc3ZnPgo8cmVjdCB4PSIyNiIgeT0iODgiIHdpZHRoPSIxMjgiIGhlaWdodD0iMTEyIiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjkwIiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTNweCI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIxNDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5Qb3N0Z3JlU1FMIGRyaXZlcjwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjE2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij51bmNoYW5nZWQ8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iNjYiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiM2ZWU3YjciPkRBVEFCQVNFIFJFUVVFU1RTIMK3IFZJQSBURU5TT1I5IFBST1hZPC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTA4IiB4Mj0iMzAwIiB5Mj0iMTA4IiBzdHJva2Utd2lkdGg9IjIuMiIgbWFya2VyLWVuZD0idXJsKCNhaHAtYWxsb3lkYikiIHN0eWxlPSJzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSIyMjciIHk9IjEwMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZpbGw6IzZlZTdiNyI+U1FMIG92ZXIgcGd3aXJlPC90ZXh0Pgo8cmVjdCB4PSIzMDQiIHk9Ijc2IiB3aWR0aD0iMTgwIiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjM5NCIgeT0iOTgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXNpemU6MTJweCI+VGVuc29yOSBTUUwgcHJveHk8L3RleHQ+Cjx0ZXh0IHg9IjM5NCIgeT0iMTE1IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij5JQU0gbG9naW4gwrcgZW5kcG9pbnQgcm91dGluZzwvdGV4dD4KPHRleHQgeD0iMzk0IiB5PSIxMzAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPm9uZSBiYWNrZW5kIHNlc3Npb24gZWFjaDwvdGV4dD4KPGxpbmUgeDE9IjQ4NCIgeTE9IjEwOCIgeDI9IjYxMCIgeTI9IjEwOCIgc3Ryb2tlLXdpZHRoPSIyLjIiIG1hcmtlci1lbmQ9InVybCgjYWhwLWFsbG95ZGIpIiBzdHlsZT0ic3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iNTQ3IiB5PSIxMDAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiM2ZWU3YjciPm93biBzZXNzaW9uPC90ZXh0Pgo8dGV4dCB4PSIzOTQiIHk9IjE1NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPm9uZSBwcm94eSBkZXBsb3ltZW50IHBlciBjbHVzdGVyPC90ZXh0Pgo8cmVjdCB4PSI2MTQiIHk9Ijc2IiB3aWR0aD0iMTk2IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+CjxzdmcgeD0iNzg2IiB5PSI1NiIgd2lkdGg9IjIwIiBoZWlnaHQ9IjIwIiB2aWV3Qm94PSIwIDAgNDMyLjA3MSA0NDUuMzgzIiBwcmVzZXJ2ZUFzcGVjdFJhdGlvPSJ4TWlkWU1pZCBtZWV0Ij48ZyBzdHlsZT0iZmlsbC1ydWxlOm5vbnplcm87Y2xpcC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLW1pdGVybGltaXQ6NCI+IDwvZz4gPGcgc3R5bGU9ImZpbGwtcnVsZTpub256ZXJvO2NsaXAtcnVsZTpub256ZXJvO2ZpbGw6bm9uZTtzdHJva2U6I0ZGRkZGRjtzdHJva2Utd2lkdGg6MTIuNDY1MTtzdHJva2UtbGluZWNhcDpyb3VuZDtzdHJva2UtbGluZWpvaW46cm91bmQ7c3Ryb2tlLW1pdGVybGltaXQ6NCI+IDxwYXRoIGQ9Ik0zMjMuMjA1LDMyNC4yMjdjMi44MzMtMjMuNjAxLDEuOTg0LTI3LjA2MiwxOS41NjMtMjMuMjM5bDQuNDYzLDAuMzkyYzEzLjUxNywwLjYxNSwzMS4xOTktMi4xNzQsNDEuNTg3LTdjMjIuMzYyLTEwLjM3NiwzNS42MjItMjcuNywxMy41NzItMjMuMTQ4Yy01MC4yOTcsMTAuMzc2LTUzLjc1NS02LjY1NS01My43NTUtNi42NTVjNTMuMTExLTc4LjgwMyw3NS4zMTMtMTc4LjgzNiw1Ni4xNDktMjAzLjMyMiBDMzUyLjUxNC01LjUzNCwyNjIuMDM2LDI2LjA0OSwyNjAuNTIyLDI2Ljg2OWwtMC40ODIsMC4wODljLTkuOTM4LTIuMDYyLTIxLjA2LTMuMjk0LTMzLjU1NC0zLjQ5NmMtMjIuNzYxLTAuMzc0LTQwLjAzMiw1Ljk2Ny01My4xMzMsMTUuOTA0YzAsMC0xNjEuNDA4LTY2LjQ5OC0xNTMuODk5LDgzLjYyOGMxLjU5NywzMS45MzYsNDUuNzc3LDI0MS42NTUsOTguNDcsMTc4LjMxIGMxOS4yNTktMjMuMTYzLDM3Ljg3MS00Mi43NDgsMzcuODcxLTQyLjc0OGM5LjI0Miw2LjE0LDIwLjMwNyw5LjI3MiwzMS45MTIsOC4xNDdsMC44OTctMC43NjVjLTAuMjgxLDIuODc2LTAuMTU3LDUuNjg5LDAuMzU5LDkuMDE5Yy0xMy41NzIsMTUuMTY3LTkuNTg0LDE3LjgzLTM2LjcyMywyMy40MTZjLTI3LjQ1Nyw1LjY1OS0xMS4zMjYsMTUuNzM0LTAuNzk3LDE4LjM2N2MxMi43NjgsMy4xOTMsNDIuMzA1LDcuNzE2LDYyLjI2OC0yMC4yMjQgbC0wLjc5NSwzLjE4OGM1LjMyNSw0LjI2LDQuOTY1LDMwLjYxOSw1LjcyLDQ5LjQ1MmMwLjc1NiwxOC44MzQsMi4wMTcsMzYuNDA5LDUuODU2LDQ2Ljc3MWMzLjgzOSwxMC4zNiw4LjM2OSwzNy4wNSw0NC4wMzYsMjkuNDA2YzI5LjgwOS02LjM4OCw1Mi42LTE1LjU4Miw1NC42NzctMTAxLjEwNyIgc3R5bGU9ImZpbGw6IzAwMDAwMDtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MzcuMzk1MztzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNNDAyLjM5NSwyNzEuMjNjLTUwLjMwMiwxMC4zNzYtNTMuNzYtNi42NTUtNTMuNzYtNi42NTVjNTMuMTExLTc4LjgwOCw3NS4zMTMtMTc4Ljg0Myw1Ni4xNTMtMjAzLjMyNmMtNTIuMjctNjYuNzg1LTE0Mi43NTItMzUuMi0xNDQuMjYyLTM0LjM4bC0wLjQ4NiwwLjA4N2MtOS45MzgtMi4wNjMtMjEuMDYtMy4yOTItMzMuNTYtMy40OTZjLTIyLjc2MS0wLjM3My00MC4wMjYsNS45NjctNTMuMTI3LDE1LjkwMiBjMCwwLTE2MS40MTEtNjYuNDk1LTE1My45MDQsODMuNjNjMS41OTcsMzEuOTM4LDQ1Ljc3NiwyNDEuNjU3LDk4LjQ3MSwxNzguMzEyYzE5LjI2LTIzLjE2MywzNy44NjktNDIuNzQ4LDM3Ljg2OS00Mi43NDhjOS4yNDMsNi4xNCwyMC4zMDgsOS4yNzIsMzEuOTA4LDguMTQ3bDAuOTAxLTAuNzY1Yy0wLjI4LDIuODc2LTAuMTUyLDUuNjg5LDAuMzYxLDkuMDE5Yy0xMy41NzUsMTUuMTY3LTkuNTg2LDE3LjgzLTM2LjcyMywyMy40MTYgYy0yNy40NTksNS42NTktMTEuMzI4LDE1LjczNC0wLjc5NiwxOC4zNjdjMTIuNzY4LDMuMTkzLDQyLjMwNyw3LjcxNiw2Mi4yNjYtMjAuMjI0bC0wLjc5NiwzLjE4OGM1LjMxOSw0LjI2LDkuMDU0LDI3LjcxMSw4LjQyOCw0OC45NjljLTAuNjI2LDIxLjI1OS0xLjA0NCwzNS44NTQsMy4xNDcsNDcuMjU0YzQuMTkxLDExLjQsOC4zNjgsMzcuMDUsNDQuMDQyLDI5LjQwNmMyOS44MDktNi4zODgsNDUuMjU2LTIyLjk0Miw0Ny40MDUtNTAuNTU1IGMxLjUyNS0xOS42MzEsNC45NzYtMTYuNzI5LDUuMTk0LTM0LjI4bDIuNzY4LTguMzA5YzMuMTkyLTI2LjYxMSwwLjUwNy0zNS4xOTYsMTguODcyLTMxLjIwM2w0LjQ2MywwLjM5MmMxMy41MTcsMC42MTUsMzEuMjA4LTIuMTc0LDQxLjU5MS03YzIyLjM1OC0xMC4zNzYsMzUuNjE4LTI3LjcsMTMuNTczLTIzLjE0OHoiIHN0eWxlPSJmaWxsOiMzMzY3OTE7c3Ryb2tlOm5vbmUiLz4gPHBhdGggZD0iTTIxNS44NjYsMjg2LjQ4NGMtMS4zODUsNDkuNTE2LDAuMzQ4LDk5LjM3Nyw1LjE5MywxMTEuNDk1YzQuODQ4LDEyLjExOCwxNS4yMjMsMzUuNjg4LDUwLjksMjguMDQ1YzI5LjgwNi02LjM5LDQwLjY1MS0xOC43NTYsNDUuMzU3LTQ2LjA1MWMzLjQ2Ni0yMC4wODIsMTAuMTQ4LTc1Ljg1NCwxMS4wMDUtODcuMjgxIi8+IDxwYXRoIGQ9Ik0xNzMuMTA0LDM4LjI1NmMwLDAtMTYxLjUyMS02Ni4wMTYtMTU0LjAxMiw4NC4xMDljMS41OTcsMzEuOTM4LDQ1Ljc3OSwyNDEuNjY0LDk4LjQ3MywxNzguMzE2YzE5LjI1Ni0yMy4xNjYsMzYuNjcxLTQxLjMzNSwzNi42NzEtNDEuMzM1Ii8+IDxwYXRoIGQ9Ik0yNjAuMzQ5LDI2LjIwN2MtNS41OTEsMS43NTMsODkuODQ4LTM0Ljg4OSwxNDQuMDg3LDM0LjQxN2MxOS4xNTksMjQuNDg0LTMuMDQzLDEyNC41MTktNTYuMTUzLDIwMy4zMjkiLz4gPHBhdGggZD0iTTM0OC4yODIsMjYzLjk1M2MwLDAsMy40NjEsMTcuMDM2LDUzLjc2NCw2LjY1M2MyMi4wNC00LjU1Miw4Ljc3NiwxMi43NzQtMTMuNTc3LDIzLjE1NWMtMTguMzQ1LDguNTE0LTU5LjQ3NCwxMC42OTYtNjAuMTQ2LTEuMDY5Yy0xLjcyOS0zMC4zNTUsMjEuNjQ3LTIxLjEzMywxOS45Ni0yOC43MzljLTEuNTI1LTYuODUtMTEuOTc5LTEzLjU3My0xOC44OTQtMzAuMzM4IGMtNi4wMzctMTQuNjMzLTgyLjc5Ni0xMjYuODQ5LDIxLjI4Ny0xMTAuMTgzYzMuODEzLTAuNzg5LTI3LjE0Ni05OS4wMDItMTI0LjU1My0xMDAuNTk5Yy05Ny4zODUtMS41OTctOTQuMTksMTE5Ljc2Mi05NC4xOSwxMTkuNzYyIiBzdHlsZT0ic3Ryb2tlLWxpbmVqb2luOmJldmVsIi8+IDxwYXRoIGQ9Ik0xODguNjA0LDI3NC4zMzRjLTEzLjU3NywxNS4xNjYtOS41ODQsMTcuODI5LTM2LjcyMywyMy40MTdjLTI3LjQ1OSw1LjY2LTExLjMyNiwxNS43MzMtMC43OTcsMTguMzY1YzEyLjc2OCwzLjE5NSw0Mi4zMDcsNy43MTgsNjIuMjY2LTIwLjIyOWM2LjA3OC04LjUwOS0wLjAzNi0yMi4wODYtOC4zODUtMjUuNTQ3Yy00LjAzNC0xLjY3MS05LjQyOC0zLjc2NS0xNi4zNjEsMy45OTR6Ii8+IDxwYXRoIGQ9Ik0xODcuNzE1LDI3NC4wNjljLTEuMzY4LTguOTE3LDIuOTMtMTkuNTI4LDcuNTM2LTMxLjk0MmM2LjkyMi0xOC42MjYsMjIuODkzLTM3LjI1NSwxMC4xMTctOTYuMzM5Yy05LjUyMy00NC4wMjktNzMuMzk2LTkuMTYzLTczLjQzNi0zLjE5M2MtMC4wMzksNS45NjgsMi44ODksMzAuMjYtMS4wNjcsNTguNTQ4Yy01LjE2MiwzNi45MTMsMjMuNDg4LDY4LjEzMiw1Ni40NzksNjQuOTM4Ii8+IDxwYXRoIGQ9Ik0xNzIuNTE3LDE0MS43Yy0wLjI4OCwyLjAzOSwzLjczMyw3LjQ4LDguOTc2LDguMjA3YzUuMjM0LDAuNzMsOS43MTQtMy41MjIsOS45OTgtNS41NTljMC4yODQtMi4wMzktMy43MzItNC4yODUtOC45NzctNS4wMTVjLTUuMjM3LTAuNzMxLTkuNzE5LDAuMzMzLTkuOTk2LDIuMzY3eiIgc3R5bGU9ImZpbGw6I0ZGRkZGRjtzdHJva2Utd2lkdGg6NC4xNTU7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTMzMS45NDEsMTM3LjU0M2MwLjI4NCwyLjAzOS0zLjczMiw3LjQ4LTguOTc2LDguMjA3Yy01LjIzOCwwLjczLTkuNzE4LTMuNTIyLTEwLjAwNS01LjU1OWMtMC4yNzctMi4wMzksMy43NC00LjI4NSw4Ljk3OS01LjAxNWM1LjIzOS0wLjczLDkuNzE4LDAuMzMzLDEwLjAwMiwyLjM2OHoiIHN0eWxlPSJmaWxsOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjIuMDc3NTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNMzUwLjY3NiwxMjMuNDMyYzAuODYzLDE1Ljk5NC0zLjQ0NSwyNi44ODgtMy45ODgsNDMuOTE0Yy0wLjgwNCwyNC43NDgsMTEuNzk5LDUzLjA3NC03LjE5MSw4MS40MzUiLz4gPHBhdGggZD0iTTAsNjAuMjMyIiBzdHlsZT0ic3Ryb2tlLXdpZHRoOjMiLz4gPC9nPjwvc3ZnPgo8dGV4dCB4PSI3MTIiIHk9IjEwMyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMnB4Ij5BbGxveURCPC90ZXh0Pgo8dGV4dCB4PSI3MTIiIHk9IjEyMiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPlBvc3RncmVTUUwgZW5naW5lPC90ZXh0Pgo8dGV4dCB4PSIyMDAiIHk9IjE3NiIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGIiPk1BTkFHRU1FTlQgUkVRVUVTVFMgwrcgVklBIFRFTlNPUjk8L3RleHQ+CjxsaW5lIHgxPSIxNTQiIHkxPSIyMDYiIHgyPSIzMDAiIHkyPSIyMDYiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaHAtYWxsb3lkYikiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8dGV4dCB4PSIyMjciIHk9IjE5OCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjgiPlJEUyBBUEk8L3RleHQ+CjxyZWN0IHg9IjMwNCIgeT0iMTgyIiB3aWR0aD0iMTgwIiBoZWlnaHQ9IjUwIiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjM5NCIgeT0iMjAzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC1zaXplOjEycHgiPlRlbnNvcjk8L3RleHQ+Cjx0ZXh0IHg9IjM5NCIgeT0iMjIwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij5zZXJ2aWNlIGFkYXB0ZXI8L3RleHQ+CjxsaW5lIHgxPSI0ODQiIHkxPSIyMDYiIHgyPSI2MTAiIHkyPSIyMDYiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaHAtYWxsb3lkYikiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8cmVjdCB4PSI2MTQiIHk9IjE4MiIgd2lkdGg9IjE5NiIgaGVpZ2h0PSI1MCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSI3MTIiIHk9IjIwMyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMS41cHgiPkFsbG95REIgYWRtaW4gQVBJPC90ZXh0Pgo8dGV4dCB4PSI3MTIiIHk9IjIyMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPnRoZSBiYWNrZW5kJ3MgbWFuYWdlbWVudCBBUEk8L3RleHQ+Cjwvc3ZnPg==)

Queries pass through the Tensor9 proxy, which authenticates and routes them; management calls are translated.

#### Database connections

Each cluster gets a writer endpoint and a reader endpoint, named the way Aurora names them. The writer endpoint always reaches the primary instance. The reader endpoint sends each new session to an available read pool, or to the writer while no read pool is available. On a Kubernetes installation these two are the cluster's endpoints. They are published through Private Service Connect and named in a private DNS zone attached to the cluster's VPC, so they resolve only inside that VPC. A member's own instance name resolves too, but it routes by role, so a reader member's name reaches any reader. A Docker composition also publishes instance and custom endpoints. When membership changes, existing sessions keep their backend and new sessions use the new membership.

IAM database authentication works the way it does on Aurora. Grant `rds_iam` to a SQL user, then connect with an RDS authentication token signed for the exact endpoint, port, region and user name. The proxy checks the signature and the `rds-db:connect` permission on `dbuser:<cluster resource ID>/<user>`, then logs in to AlloyDB as that same role, so SQL grants and row-level security are unchanged. Password logins for other users pass through; a user granted `rds_iam` cannot log in with a password.

Applications trust the proxy's certificate, not AlloyDB's. Members of a proxied cluster report the proxy's certificate authority as their CA certificate, and the endpoint offers the matching trust bundle at the path where AWS publishes its RDS bundles. The proxy encrypts its own connection to AlloyDB. Three Aurora discovery functions work for drivers that use them: `aurora_db_instance_identifier()`, `aurora_list_builtins()` and `aurora_replica_status()`, the last with replica lag left empty. Other `aurora_*` functions and AWS's S3, Lambda and machine-learning SQL functions return an error.

Aurora PostgreSQL's SQL, drivers, object-relational mappers (ORMs), prepared statements, COPY and cancellation work unchanged through the proxy, because AlloyDB for PostgreSQL runs PostgreSQL.

#### Database management

At runtime your tools make the same RDS calls for the cluster and its members. For each supported operation, the adapter accepts the RDS request, returns the RDS response format, and maps it to AlloyDB. A cluster becomes an AlloyDB cluster, the writer a highly available primary instance, and each reader its own read pool. Parameter groups become database flags, and a reboot becomes an instance restart. On this backend the adapter also keeps the proxy up to date: every member, endpoint and IAM change reaches the proxy before Describe reports the endpoint. Snapshot, restore, point-in-time restore, failover, stop / start, global-cluster and RDS Proxy requests return an error.

`CreateDBCluster` with the backend tag `t9:backend=google::1.0.0::alloydb::proxied` places a cluster here; members and custom endpoints follow their cluster. The first member becomes the primary instance and later members become read pools. Tensor9 records each request, creates the AlloyDB resources and the proxy in the background, and reports `creating` until both are ready. Describe returns only proxy addresses, never AlloyDB's own, and only once the running proxy has confirmed the exact configuration.

![The Tensor9 service adapter handles RDS management requests using AlloyDB admin API and returns RDS responses.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTk2IiB2aWV3Qm94PSIwIDAgODM2IDE5NiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgaGFuZGxlcyBSRFMgbWFuYWdlbWVudCByZXF1ZXN0cyB1c2luZyBBbGxveURCIGFkbWluIEFQSSBhbmQgcmV0dXJucyBSRFMgcmVzcG9uc2VzLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaGMtcmRzLWFsbG95ZGItYWRtaW4tYXBpIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM5NGEzYjgiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjE2IiB5PSIzNCIgd2lkdGg9IjIzNiIgaGVpZ2h0PSIxMjgiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iMTM0IiB5PSI2MCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMi41cHgiPlJEUyBtYW5hZ2VtZW50IGNhbGw8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iODIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5jcmVhdGUgwrcgZGVzY3JpYmUgwrcgZGVsZXRlPC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9Ijk5IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+d3JpdGVyIMK3IHJlYWRlcnM8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iMTE2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+cGFyYW1ldGVycyDCtyByZWJvb3Q8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iMTQyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YiI+c2FtZSByZXF1ZXN0IC8gcmVzcG9uc2Ugc2hhcGVzPC90ZXh0Pgo8bGluZSB4MT0iMjUyIiB5MT0iNzQiIHgyPSIzMTQiIHkyPSI3NCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtYWxsb3lkYi1hZG1pbi1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPGxpbmUgeDE9IjMxOCIgeTE9IjEyOCIgeDI9IjI1NiIgeTI9IjEyOCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtYWxsb3lkYi1hZG1pbi1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHJlY3QgeD0iMzE4IiB5PSI1NCIgd2lkdGg9IjIwNCIgaGVpZ2h0PSI4OCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI0MjAiIHk9Ijk0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC1zaXplOjEycHgiPlRlbnNvcjk8L3RleHQ+CiAgPHRleHQgeD0iNDIwIiB5PSIxMTIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPnNlcnZpY2UgYWRhcHRlcjwvdGV4dD4KPGxpbmUgeDE9IjUyMiIgeTE9Ijc0IiB4Mj0iNTg0IiB5Mj0iNzQiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWFsbG95ZGItYWRtaW4tYXBpKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxsaW5lIHgxPSI1ODgiIHkxPSIxMjgiIHgyPSI1MjYiIHkyPSIxMjgiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWFsbG95ZGItYWRtaW4tYXBpKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxyZWN0IHg9IjU4OCIgeT0iMzQiIHdpZHRoPSIyMzIiIGhlaWdodD0iMTI4IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjcwNCIgeT0iNjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTJweCI+QWxsb3lEQiBhZG1pbiBBUEk8L3RleHQ+Cjx0ZXh0IHg9IjcwNCIgeT0iOTQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5jbHVzdGVycyDCtyBpbnN0YW5jZXMgwrcgcmVhZCBwb29sczwvdGV4dD4KPHRleHQgeD0iNzA0IiB5PSIxMTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5kYXRhYmFzZSBmbGFncyDCtyByZXN0YXJ0PC90ZXh0Pgo8L3N2Zz4=)

![The Tensor9 service adapter handles RDS management requests using AlloyDB admin API and returns RDS responses.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTk2IiB2aWV3Qm94PSIwIDAgODM2IDE5NiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgaGFuZGxlcyBSRFMgbWFuYWdlbWVudCByZXF1ZXN0cyB1c2luZyBBbGxveURCIGFkbWluIEFQSSBhbmQgcmV0dXJucyBSRFMgcmVzcG9uc2VzLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaGMtcmRzLWFsbG95ZGItYWRtaW4tYXBpIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM2NDc0OGIiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjE2IiB5PSIzNCIgd2lkdGg9IjIzNiIgaGVpZ2h0PSIxMjgiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iMTM0IiB5PSI2MCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMi41cHgiPlJEUyBtYW5hZ2VtZW50IGNhbGw8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iODIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5jcmVhdGUgwrcgZGVzY3JpYmUgwrcgZGVsZXRlPC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9Ijk5IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+d3JpdGVyIMK3IHJlYWRlcnM8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iMTE2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+cGFyYW1ldGVycyDCtyByZWJvb3Q8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iMTQyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiOCI+c2FtZSByZXF1ZXN0IC8gcmVzcG9uc2Ugc2hhcGVzPC90ZXh0Pgo8bGluZSB4MT0iMjUyIiB5MT0iNzQiIHgyPSIzMTQiIHkyPSI3NCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtYWxsb3lkYi1hZG1pbi1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPGxpbmUgeDE9IjMxOCIgeTE9IjEyOCIgeDI9IjI1NiIgeTI9IjEyOCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtYWxsb3lkYi1hZG1pbi1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHJlY3QgeD0iMzE4IiB5PSI1NCIgd2lkdGg9IjIwNCIgaGVpZ2h0PSI4OCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSI0MjAiIHk9Ijk0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC1zaXplOjEycHgiPlRlbnNvcjk8L3RleHQ+CiAgPHRleHQgeD0iNDIwIiB5PSIxMTIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPnNlcnZpY2UgYWRhcHRlcjwvdGV4dD4KPGxpbmUgeDE9IjUyMiIgeTE9Ijc0IiB4Mj0iNTg0IiB5Mj0iNzQiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWFsbG95ZGItYWRtaW4tYXBpKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxsaW5lIHgxPSI1ODgiIHkxPSIxMjgiIHgyPSI1MjYiIHkyPSIxMjgiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWFsbG95ZGItYWRtaW4tYXBpKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxyZWN0IHg9IjU4OCIgeT0iMzQiIHdpZHRoPSIyMzIiIGhlaWdodD0iMTI4IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjcwNCIgeT0iNjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTJweCI+QWxsb3lEQiBhZG1pbiBBUEk8L3RleHQ+Cjx0ZXh0IHg9IjcwNCIgeT0iOTQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5jbHVzdGVycyDCtyBpbnN0YW5jZXMgwrcgcmVhZCBwb29sczwvdGV4dD4KPHRleHQgeD0iNzA0IiB5PSIxMTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5kYXRhYmFzZSBmbGFncyDCtyByZXN0YXJ0PC90ZXh0Pgo8L3N2Zz4=)

Tensor9 translates RDS management requests to the backend API and returns RDS responses.

#### Limitations

Where Aurora PostgreSQL and AlloyDB behind the proxy differ

* **Connection pooling is not supported.** Each client session keeps its own AlloyDB connection as the same SQL user, and the RDS Proxy APIs are not supported. Use AlloyDB's managed connection pooling, or a pooler in the application, if you need multiplexing.
* **Interrupted sessions are not replayed.** When a backend is lost its sessions disconnect; clients reconnect to the same endpoint and reach a surviving backend. Open transactions are not recovered.
* **RDS-driven failover is not supported.** AlloyDB fails the primary over to its standby by itself. `FailoverDBCluster` is rejected, readers are not promotion candidates, and promotion tiers must stay at the default.
* **RDS snapshots and restores are not supported.** AlloyDB's automated and continuous backups follow the cluster's backup retention; RDS snapshot, restore and point-in-time restore requests return an error.
* **Public endpoints are not supported.** Proxied endpoints resolve only inside the cluster's VPC. Public members, and clusters without a DB subnet group, are rejected.
* **You must rotate the proxy's root certificate yourself.** Rotating the proxy's root certificate authority is not automated. Clusters report a warning two years before it expires.
* **Several Aurora features are not supported.** The Data API, global databases, stop / start, event subscriptions, Serverless v2, I/O-Optimized storage and customer-managed encryption keys are not available on this backend.

#### Other considerations

**Hosting the proxy.** On a Kubernetes installation each proxied cluster gets its own proxy deployment. It scales automatically, loses at most one pod at a time to evictions, and spreads across nodes, and across zones on a regional cluster. Each pod accepts connections using its own copy of the cluster's settings, so a brief outage of Tensor9's control services does not stop new logins. Only the first IAM login of a newly granted user needs those services, and that login is rejected while they are unavailable. A Docker composition runs one fixed proxy container per cluster on the host that runs Tensor9, published on that host's loopback addresses.

**Migration.** Moving the data is a one-time step: a logical dump and restore, or logical replication for a short cutover. Grant `rds_iam` to the users that log in with IAM tokens before you switch clients over.

**Operations.** The customer owns the AlloyDB cluster in their Google Cloud project. Maintenance windows, quotas and pricing are Google's. Tensor9 runs the proxy alongside its other services.

**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.

##### Aurora PostgreSQL · Primary allocated compute

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Primary allocated compute. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Aurora PostgreSQL · 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/e37f567f1894e1b7024e453570b2ad2beafcd8fac93c867c1601698dcf7db4ec-light.svg)

![Aurora PostgreSQL · 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/e932d207e1068f71f52eea0716f51fa0876a801be7dda42cb6ef57d3534b57be-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) | Aurora PostgreSQL | Target scenario | AlloyDB for PostgreSQL (RDS proxy) | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 191.88 | 191.88 |
| 0 | 0.00 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 353.77 | 353.77 |
| 1,460 | 211.70 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 191.88 | -19.82 |
| 1,460 | 211.70 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 353.77 | 142.07 |
| 2,920 | 423.40 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 353.77 | -69.63 |
| 2,920 | 423.40 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 677.53 | 254.13 |
| 5,840 | 846.80 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 677.53 | -169.27 |
| 5,840 | 846.80 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 1,325.07 | 478.27 |
| 11,680 | 1,693.60 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 1,325.07 | -368.53 |
| 11,680 | 1,693.60 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 2,620.15 | 926.55 |
| 23,360 | 3,387.20 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 2,620.15 | -767.05 |
| 23,360 | 3,387.20 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 5,210.31 | 1,823.11 |
| 46,720 | 6,774.40 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 5,210.31 | -1,564.09 |
| 46,720 | 6,774.40 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 10,390.62 | 3,616.22 |

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 |
| - | - | -: | - |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Origin list price · Database reads | 0 | USD/operations |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Origin list price · Database writes | 0 | USD/operations |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target CPU / source CPU | 1 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target RAM / source RAM | 1 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target disk / source disk | 1 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · read | 0 | USD/read |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · write | 0 | USD/write |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target list price · GiB-month | 0.299957 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target list price · network GiB | 0.12 | USD/network GiB |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target list price · vCPU-hour | 0.06608 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target list price · GiB-hour | 0.0112 | USD/GiB-hour |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · input token | 0 | USD/input token |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · output token | 0 | USD/output token |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target monthly base charge | 0 | USD/month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target service minimum | 113.646 | USD/month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Minimum primary CPU | 2 | vCPU |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Minimum primary RAM | 8 | GiB |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Minimum primary disk | 100 | GiB |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Allocated share of provisioned cost | 1 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Planning peak / mean work | 2 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Planning disk utilization | 0.8 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Maintenance and log disk reserve | 20 | GiB |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Origin list price · Database reads | 0 | USD/operations |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Origin list price · Database writes | 0 | USD/operations |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target CPU / source CPU | 1 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target RAM / source RAM | 1 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target disk / source disk | 1 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · read | 0 | USD/read |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · write | 0 | USD/write |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target list price · GiB-month | 0.299957 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target list price · network GiB | 0.12 | USD/network GiB |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target list price · vCPU-hour | 0.06608 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target list price · GiB-hour | 0.0112 | USD/GiB-hour |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · input token | 0 | USD/input token |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · output token | 0 | USD/output token |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target monthly base charge | 0 | USD/month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target service minimum | 113.646 | USD/month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Minimum primary CPU | 2 | vCPU |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Minimum primary RAM | 8 | GiB |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Minimum primary disk | 100 | GiB |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Allocated share of provisioned cost | 1 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Planning peak / mean work | 2 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Planning disk utilization | 0.8 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Maintenance and log disk reserve | 20 | GiB |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* AlloyDB bills each node's vCPU and memory (a high-availability primary is two nodes) and one regional storage pool by used GiB that every instance in the cluster shares, so storage is billed once however many copies run. The smallest machine is c4a-highmem-1 (1 vCPU, 8 GB; [https://docs.cloud.google.com/alloydb/docs/choose-machine-type](https://docs.cloud.google.com/alloydb/docs/choose-machine-type)). C4 and Z3 machine series, backups and committed-use discounts 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: AlloyDB n2-highmem-128 has 128 vCPUs and 864 GB ([https://docs.cloud.google.com/alloydb/docs/choose-machine-type](https://docs.cloud.google.com/alloydb/docs/choose-machine-type)); a cluster stores up to 128 TiB ([https://docs.cloud.google.com/alloydb/quotas](https://docs.cloud.google.com/alloydb/quotas)).
* 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)
* AlloyDB for PostgreSQL pricing: [https://cloud.google.com/alloydb/pricing](https://cloud.google.com/alloydb/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-839cb7ac853b15c56ae293dab2a4c10446879765` / `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), [AlloyDB for PostgreSQL pricing](https://cloud.google.com/alloydb/pricing).

##### Aurora PostgreSQL · Stored data

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Aurora PostgreSQL · 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/666d479fe0b82a3f696c7f2c27116f72c6ccbe68d73aa7578d81abab3af985b0-light.svg)

![Aurora PostgreSQL · 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/2bb917df1f6b81f3917696c5fe1943255822a8dfc464dad2493a40362ae05a95-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) | Aurora PostgreSQL | Target scenario | AlloyDB for PostgreSQL (RDS proxy) | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 191.88 | 191.88 |
| 0 | 0.00 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 353.77 | 353.77 |
| 10 | 1.00 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 191.88 | 190.88 |
| 10 | 1.00 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 353.77 | 352.77 |
| 100 | 10.00 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 206.88 | 196.88 |
| 100 | 10.00 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 368.76 | 358.76 |
| 1,000 | 100.00 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 544.33 | 444.33 |
| 1,000 | 100.00 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 706.21 | 606.21 |
| 10,000 | 1,000.00 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 3,918.85 | 2,918.85 |
| 10,000 | 1,000.00 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 4,080.73 | 3,080.73 |
| 100,000 | 10,000.00 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 37,664.01 | 27,664.01 |
| 100,000 | 10,000.00 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 37,825.89 | 27,825.89 |

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 125,025 GiB SSD at 100,000 GiB-month.

**Curve assumptions**

| Target scenario | Assumption | Value | Unit |
| - | - | -: | - |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Origin list price · Database reads | 0 | USD/operations |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Origin list price · Database writes | 0 | USD/operations |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target CPU / source CPU | 1 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target RAM / source RAM | 1 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target disk / source disk | 1 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · read | 0 | USD/read |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · write | 0 | USD/write |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target list price · GiB-month | 0.299957 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target list price · network GiB | 0.12 | USD/network GiB |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target list price · vCPU-hour | 0.06608 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target list price · GiB-hour | 0.0112 | USD/GiB-hour |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · input token | 0 | USD/input token |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · output token | 0 | USD/output token |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target monthly base charge | 0 | USD/month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target service minimum | 113.646 | USD/month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Minimum primary CPU | 2 | vCPU |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Minimum primary RAM | 8 | GiB |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Minimum primary disk | 100 | GiB |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Allocated share of provisioned cost | 1 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Planning peak / mean work | 2 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Planning disk utilization | 0.8 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Maintenance and log disk reserve | 20 | GiB |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Origin list price · Database reads | 0 | USD/operations |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Origin list price · Database writes | 0 | USD/operations |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target CPU / source CPU | 1 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target RAM / source RAM | 1 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target disk / source disk | 1 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · read | 0 | USD/read |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · write | 0 | USD/write |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target list price · GiB-month | 0.299957 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target list price · network GiB | 0.12 | USD/network GiB |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target list price · vCPU-hour | 0.06608 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target list price · GiB-hour | 0.0112 | USD/GiB-hour |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · input token | 0 | USD/input token |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · output token | 0 | USD/output token |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target monthly base charge | 0 | USD/month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target service minimum | 113.646 | USD/month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Minimum primary CPU | 2 | vCPU |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Minimum primary RAM | 8 | GiB |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Minimum primary disk | 100 | GiB |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Allocated share of provisioned cost | 1 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Planning peak / mean work | 2 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Planning disk utilization | 0.8 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Maintenance and log disk reserve | 20 | GiB |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* AlloyDB bills each node's vCPU and memory (a high-availability primary is two nodes) and one regional storage pool by used GiB that every instance in the cluster shares, so storage is billed once however many copies run. The smallest machine is c4a-highmem-1 (1 vCPU, 8 GB; [https://docs.cloud.google.com/alloydb/docs/choose-machine-type](https://docs.cloud.google.com/alloydb/docs/choose-machine-type)). C4 and Z3 machine series, backups and committed-use discounts 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: AlloyDB n2-highmem-128 has 128 vCPUs and 864 GB ([https://docs.cloud.google.com/alloydb/docs/choose-machine-type](https://docs.cloud.google.com/alloydb/docs/choose-machine-type)); a cluster stores up to 128 TiB ([https://docs.cloud.google.com/alloydb/quotas](https://docs.cloud.google.com/alloydb/quotas)).
* 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)
* AlloyDB for PostgreSQL pricing: [https://cloud.google.com/alloydb/pricing](https://cloud.google.com/alloydb/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-839cb7ac853b15c56ae293dab2a4c10446879765` / `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), [AlloyDB for PostgreSQL pricing](https://cloud.google.com/alloydb/pricing).

##### Aurora PostgreSQL · Database writes

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Database writes. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Aurora PostgreSQL · 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/21bf6f8fd7a12d57d7c9008b00e045a1f804b52b2fe3226076024fd5853b88b7-light.svg)

![Aurora PostgreSQL · 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/9b0fc1800a8b2d3ba3febf4d7f64abf8e37068d4b9edf545b33216b118dd5a22-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) | Aurora PostgreSQL | Target scenario | AlloyDB for PostgreSQL (RDS proxy) | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 191.88 | 191.88 |
| 0 | 0.00 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 353.77 | 353.77 |
| 1 | 0.00 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 191.88 | 191.88 |
| 1 | 0.00 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 353.77 | 353.77 |
| 10 | 0.00 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 191.88 | 191.88 |
| 10 | 0.00 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 353.77 | 353.77 |
| 100 | 0.00 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 191.88 | 191.88 |
| 100 | 0.00 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 353.77 | 353.77 |
| 1,000 | 0.00 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 191.88 | 191.88 |
| 1,000 | 0.00 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 353.77 | 353.77 |
| 10,000 | 0.00 | AlloyDB for PostgreSQL (RDS proxy) (one copy) | 191.88 | 191.88 |
| 10,000 | 0.00 | AlloyDB for PostgreSQL (RDS proxy) (two copies) | 353.77 | 353.77 |

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 |
| - | - | -: | - |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Origin list price · Database reads | 0 | USD/operations |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Origin list price · Database writes | 0 | USD/operations |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target CPU / source CPU | 1 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target RAM / source RAM | 1 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target disk / source disk | 1 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · read | 0 | USD/read |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · write | 0 | USD/write |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target list price · GiB-month | 0.299957 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target list price · network GiB | 0.12 | USD/network GiB |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target list price · vCPU-hour | 0.06608 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target list price · GiB-hour | 0.0112 | USD/GiB-hour |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · input token | 0 | USD/input token |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target price guess · output token | 0 | USD/output token |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target monthly base charge | 0 | USD/month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Target service minimum | 113.646 | USD/month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Minimum primary CPU | 2 | vCPU |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Minimum primary RAM | 8 | GiB |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Minimum primary disk | 100 | GiB |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Allocated share of provisioned cost | 1 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Planning peak / mean work | 2 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Planning disk utilization | 0.8 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Maintenance and log disk reserve | 20 | GiB |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Origin list price · Database reads | 0 | USD/operations |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Origin list price · Database writes | 0 | USD/operations |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target CPU / source CPU | 1 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target RAM / source RAM | 1 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target disk / source disk | 1 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · read | 0 | USD/read |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · write | 0 | USD/write |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target list price · GiB-month | 0.299957 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target list price · network GiB | 0.12 | USD/network GiB |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target list price · vCPU-hour | 0.06608 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target list price · GiB-hour | 0.0112 | USD/GiB-hour |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · input token | 0 | USD/input token |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target price guess · output token | 0 | USD/output token |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target monthly base charge | 0 | USD/month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Target service minimum | 113.646 | USD/month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Minimum primary CPU | 2 | vCPU |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Minimum primary RAM | 8 | GiB |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Minimum primary disk | 100 | GiB |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Allocated share of provisioned cost | 1 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Planning peak / mean work | 2 | multiplier |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Planning disk utilization | 0.8 | fraction |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Maintenance and log disk reserve | 20 | GiB |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| AlloyDB for PostgreSQL (RDS proxy) (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* AlloyDB bills each node's vCPU and memory (a high-availability primary is two nodes) and one regional storage pool by used GiB that every instance in the cluster shares, so storage is billed once however many copies run. The smallest machine is c4a-highmem-1 (1 vCPU, 8 GB; [https://docs.cloud.google.com/alloydb/docs/choose-machine-type](https://docs.cloud.google.com/alloydb/docs/choose-machine-type)). C4 and Z3 machine series, backups and committed-use discounts 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: AlloyDB n2-highmem-128 has 128 vCPUs and 864 GB ([https://docs.cloud.google.com/alloydb/docs/choose-machine-type](https://docs.cloud.google.com/alloydb/docs/choose-machine-type)); a cluster stores up to 128 TiB ([https://docs.cloud.google.com/alloydb/quotas](https://docs.cloud.google.com/alloydb/quotas)).
* 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)
* AlloyDB for PostgreSQL pricing: [https://cloud.google.com/alloydb/pricing](https://cloud.google.com/alloydb/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-839cb7ac853b15c56ae293dab2a4c10446879765` / `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), [AlloyDB for PostgreSQL pricing](https://cloud.google.com/alloydb/pricing).

**Aurora PostgreSQL → AlloyDB for PostgreSQL (RDS proxy): 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 | 96.48 |
| Target: Provisioned primary RAM | 65.41 |
| Target: Provisioned primary disk | 30.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** | **191.88** |

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.145 | USD/vCPU-hours |
| Origin list price · Primary memory | 0 | USD/GiB-hours |
| Origin list price · Primary provisioned storage | 0.1 | 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.299957 | 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.06608 | USD/vCPU-hour |
| Target list price · GiB-hour | 0.0112 | 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 | 113.646 | 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.

* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.

* AlloyDB bills each node's vCPU and memory (a high-availability primary is two nodes) and one regional storage pool by used GiB that every instance in the cluster shares, so storage is billed once however many copies run. The smallest machine is c4a-highmem-1 (1 vCPU, 8 GB; [https://docs.cloud.google.com/alloydb/docs/choose-machine-type](https://docs.cloud.google.com/alloydb/docs/choose-machine-type)). C4 and Z3 machine series, backups and committed-use discounts 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: AlloyDB n2-highmem-128 has 128 vCPUs and 864 GB ([https://docs.cloud.google.com/alloydb/docs/choose-machine-type](https://docs.cloud.google.com/alloydb/docs/choose-machine-type)); a cluster stores up to 128 TiB ([https://docs.cloud.google.com/alloydb/quotas](https://docs.cloud.google.com/alloydb/quotas)).

* 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-839cb7ac853b15c56ae293dab2a4c10446879765` / `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), [AlloyDB for PostgreSQL pricing](https://cloud.google.com/alloydb/pricing).

## On OCI

### OCI Database with PostgreSQL

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| AWS/Aurora-proprietary SQL: aws\_s3.*, aws\_lambda.invoke, Aurora ML (aws\_sagemaker / aws\_comprehend), aurora\_* / apg\_plan\_mgmt | SQL functions | Out of scope | Full surface | AWS and Aurora extension functions with no counterpart on vanilla PostgreSQL; a query calling them fails |
| pgwire protocol (application SQL) | Wire protocol | Supported | Common | wire-compatible PostgreSQL; application SQL is unchanged |

#### How it works

Your application's PostgreSQL driver connects directly to OCI Database with PostgreSQL. These database requests are the **data plane**. The driver and the PostgreSQL wire protocol stay the same, and Tensor9 adds no proxy, translation or latency to your queries.

Management requests, such as snapshots, restores, replicas, failover and configuration changes, are the **control plane**. Tensor9 runs the RDS API in the customer's Cloud Adapter deployment and translates each of these requests to the backend's management API. The sections below list which operations work and which return an error.

![Database requests (SQL over pgwire) connect directly to OCI PostgreSQL. The Tensor9 service adapter translates RDS API management calls to OCI management API.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgcGd3aXJlKSBjb25uZWN0IGRpcmVjdGx5IHRvIE9DSSBQb3N0Z3JlU1FMLiBUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgdHJhbnNsYXRlcyBSRFMgQVBJIG1hbmFnZW1lbnQgY2FsbHMgdG8gT0NJIG1hbmFnZW1lbnQgQVBJLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaGQtb2NpLXBvc3RncmVzcWwiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjciIG1hcmtlckhlaWdodD0iNyIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6Izk0YTNiOCIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iOCIgeT0iMzQiIHdpZHRoPSI4MjAiIGhlaWdodD0iMjA2IiByeD0iMTYiIHN0cm9rZS13aWR0aD0iMS40IiBzdHJva2UtZGFzaGFycmF5PSI1IDUiIHN0eWxlPSJmaWxsOiNmOGZhZmM7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iMjYiIHk9IjU0IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzk0YTNiODsgZmlsbDojMDQ3ODU3Ij5PTiBPQ0k8L3RleHQ+PHN2ZyB4PSI3OTIiIHk9IjM2IiB3aWR0aD0iMTYiIGhlaWdodD0iMTYiIHZpZXdCb3g9IjAgMCAyNCAyNCIgcHJlc2VydmVBc3BlY3RSYXRpbz0ieE1pZFlNaWQgbWVldCI+PHBhdGggZmlsbD0iI0M3NDYzNCIgZD0iTTE2LjQxMiA0LjQxMmgtOC44MmE3LjU4OCA3LjU4OCAwIDAgMC0uMDA4IDE1LjE3Nmg4LjgyOGE3LjU4OCA3LjU4OCAwIDAgMCAwLTE1LjE3Nm0tLjE5MyAxMi41MDJINy43ODZhNC45MTUgNC45MTUgMCAwIDEgMC05LjgyOGg4LjQzM2E0LjkxNCA0LjkxNCAwIDEgMSAwIDkuODI4Ii8+PC9zdmc+CjxyZWN0IHg9IjI2IiB5PSI4OCIgd2lkdGg9IjEyOCIgaGVpZ2h0PSIxMTIiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iOTAiIHk9IjEyNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxM3B4Ij5Zb3VyIGFwcDwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjE0NSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPlBvc3RncmVTUUwgZHJpdmVyPC90ZXh0Pgo8dGV4dCB4PSI5MCIgeT0iMTYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPnVuY2hhbmdlZDwvdGV4dD4KPHRleHQgeD0iMjAwIiB5PSI4MiIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjg7IGZpbGw6IzA0Nzg1NyI+REFUQUJBU0UgUkVRVUVTVFMgwrcgRElSRUNUIENPTk5FQ1RJT048L3RleHQ+CjxsaW5lIHgxPSIxNTQiIHkxPSIxMDgiIHgyPSI2MTAiIHkyPSIxMDgiIHN0cm9rZS13aWR0aD0iMi4yIiBtYXJrZXItZW5kPSJ1cmwoI2FoZC1vY2ktcG9zdGdyZXNxbCkiIHN0eWxlPSJzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSIzODIiIHk9IjEwMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZpbGw6IzA0Nzg1NyI+U1FMIG92ZXIgcGd3aXJlPC90ZXh0Pgo8cmVjdCB4PSI2MTQiIHk9Ijc2IiB3aWR0aD0iMTk2IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+PHN2ZyB4PSI3ODYiIHk9IjU2IiB3aWR0aD0iMjAiIGhlaWdodD0iMjAiIHZpZXdCb3g9IjAgMCA0MzIuMDcxIDQ0NS4zODMiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiPjxnIHN0eWxlPSJmaWxsLXJ1bGU6bm9uemVybztjbGlwLXJ1bGU6bm9uemVybztzdHJva2U6IzAwMDAwMDtzdHJva2UtbWl0ZXJsaW1pdDo0Ij4gPC9nPiA8ZyBzdHlsZT0iZmlsbC1ydWxlOm5vbnplcm87Y2xpcC1ydWxlOm5vbnplcm87ZmlsbDpub25lO3N0cm9rZTojRkZGRkZGO3N0cm9rZS13aWR0aDoxMi40NjUxO3N0cm9rZS1saW5lY2FwOnJvdW5kO3N0cm9rZS1saW5lam9pbjpyb3VuZDtzdHJva2UtbWl0ZXJsaW1pdDo0Ij4gPHBhdGggZD0iTTMyMy4yMDUsMzI0LjIyN2MyLjgzMy0yMy42MDEsMS45ODQtMjcuMDYyLDE5LjU2My0yMy4yMzlsNC40NjMsMC4zOTJjMTMuNTE3LDAuNjE1LDMxLjE5OS0yLjE3NCw0MS41ODctN2MyMi4zNjItMTAuMzc2LDM1LjYyMi0yNy43LDEzLjU3Mi0yMy4xNDhjLTUwLjI5NywxMC4zNzYtNTMuNzU1LTYuNjU1LTUzLjc1NS02LjY1NWM1My4xMTEtNzguODAzLDc1LjMxMy0xNzguODM2LDU2LjE0OS0yMDMuMzIyIEMzNTIuNTE0LTUuNTM0LDI2Mi4wMzYsMjYuMDQ5LDI2MC41MjIsMjYuODY5bC0wLjQ4MiwwLjA4OWMtOS45MzgtMi4wNjItMjEuMDYtMy4yOTQtMzMuNTU0LTMuNDk2Yy0yMi43NjEtMC4zNzQtNDAuMDMyLDUuOTY3LTUzLjEzMywxNS45MDRjMCwwLTE2MS40MDgtNjYuNDk4LTE1My44OTksODMuNjI4YzEuNTk3LDMxLjkzNiw0NS43NzcsMjQxLjY1NSw5OC40NywxNzguMzEgYzE5LjI1OS0yMy4xNjMsMzcuODcxLTQyLjc0OCwzNy44NzEtNDIuNzQ4YzkuMjQyLDYuMTQsMjAuMzA3LDkuMjcyLDMxLjkxMiw4LjE0N2wwLjg5Ny0wLjc2NWMtMC4yODEsMi44NzYtMC4xNTcsNS42ODksMC4zNTksOS4wMTljLTEzLjU3MiwxNS4xNjctOS41ODQsMTcuODMtMzYuNzIzLDIzLjQxNmMtMjcuNDU3LDUuNjU5LTExLjMyNiwxNS43MzQtMC43OTcsMTguMzY3YzEyLjc2OCwzLjE5Myw0Mi4zMDUsNy43MTYsNjIuMjY4LTIwLjIyNCBsLTAuNzk1LDMuMTg4YzUuMzI1LDQuMjYsNC45NjUsMzAuNjE5LDUuNzIsNDkuNDUyYzAuNzU2LDE4LjgzNCwyLjAxNywzNi40MDksNS44NTYsNDYuNzcxYzMuODM5LDEwLjM2LDguMzY5LDM3LjA1LDQ0LjAzNiwyOS40MDZjMjkuODA5LTYuMzg4LDUyLjYtMTUuNTgyLDU0LjY3Ny0xMDEuMTA3IiBzdHlsZT0iZmlsbDojMDAwMDAwO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDozNy4zOTUzO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyIi8+IDxwYXRoIGQ9Ik00MDIuMzk1LDI3MS4yM2MtNTAuMzAyLDEwLjM3Ni01My43Ni02LjY1NS01My43Ni02LjY1NWM1My4xMTEtNzguODA4LDc1LjMxMy0xNzguODQzLDU2LjE1My0yMDMuMzI2Yy01Mi4yNy02Ni43ODUtMTQyLjc1Mi0zNS4yLTE0NC4yNjItMzQuMzhsLTAuNDg2LDAuMDg3Yy05LjkzOC0yLjA2My0yMS4wNi0zLjI5Mi0zMy41Ni0zLjQ5NmMtMjIuNzYxLTAuMzczLTQwLjAyNiw1Ljk2Ny01My4xMjcsMTUuOTAyIGMwLDAtMTYxLjQxMS02Ni40OTUtMTUzLjkwNCw4My42M2MxLjU5NywzMS45MzgsNDUuNzc2LDI0MS42NTcsOTguNDcxLDE3OC4zMTJjMTkuMjYtMjMuMTYzLDM3Ljg2OS00Mi43NDgsMzcuODY5LTQyLjc0OGM5LjI0Myw2LjE0LDIwLjMwOCw5LjI3MiwzMS45MDgsOC4xNDdsMC45MDEtMC43NjVjLTAuMjgsMi44NzYtMC4xNTIsNS42ODksMC4zNjEsOS4wMTljLTEzLjU3NSwxNS4xNjctOS41ODYsMTcuODMtMzYuNzIzLDIzLjQxNiBjLTI3LjQ1OSw1LjY1OS0xMS4zMjgsMTUuNzM0LTAuNzk2LDE4LjM2N2MxMi43NjgsMy4xOTMsNDIuMzA3LDcuNzE2LDYyLjI2Ni0yMC4yMjRsLTAuNzk2LDMuMTg4YzUuMzE5LDQuMjYsOS4wNTQsMjcuNzExLDguNDI4LDQ4Ljk2OWMtMC42MjYsMjEuMjU5LTEuMDQ0LDM1Ljg1NCwzLjE0Nyw0Ny4yNTRjNC4xOTEsMTEuNCw4LjM2OCwzNy4wNSw0NC4wNDIsMjkuNDA2YzI5LjgwOS02LjM4OCw0NS4yNTYtMjIuOTQyLDQ3LjQwNS01MC41NTUgYzEuNTI1LTE5LjYzMSw0Ljk3Ni0xNi43MjksNS4xOTQtMzQuMjhsMi43NjgtOC4zMDljMy4xOTItMjYuNjExLDAuNTA3LTM1LjE5NiwxOC44NzItMzEuMjAzbDQuNDYzLDAuMzkyYzEzLjUxNywwLjYxNSwzMS4yMDgtMi4xNzQsNDEuNTkxLTdjMjIuMzU4LTEwLjM3NiwzNS42MTgtMjcuNywxMy41NzMtMjMuMTQ4eiIgc3R5bGU9ImZpbGw6IzMzNjc5MTtzdHJva2U6bm9uZSIvPiA8cGF0aCBkPSJNMjE1Ljg2NiwyODYuNDg0Yy0xLjM4NSw0OS41MTYsMC4zNDgsOTkuMzc3LDUuMTkzLDExMS40OTVjNC44NDgsMTIuMTE4LDE1LjIyMywzNS42ODgsNTAuOSwyOC4wNDVjMjkuODA2LTYuMzksNDAuNjUxLTE4Ljc1Niw0NS4zNTctNDYuMDUxYzMuNDY2LTIwLjA4MiwxMC4xNDgtNzUuODU0LDExLjAwNS04Ny4yODEiLz4gPHBhdGggZD0iTTE3My4xMDQsMzguMjU2YzAsMC0xNjEuNTIxLTY2LjAxNi0xNTQuMDEyLDg0LjEwOWMxLjU5NywzMS45MzgsNDUuNzc5LDI0MS42NjQsOTguNDczLDE3OC4zMTZjMTkuMjU2LTIzLjE2NiwzNi42NzEtNDEuMzM1LDM2LjY3MS00MS4zMzUiLz4gPHBhdGggZD0iTTI2MC4zNDksMjYuMjA3Yy01LjU5MSwxLjc1Myw4OS44NDgtMzQuODg5LDE0NC4wODcsMzQuNDE3YzE5LjE1OSwyNC40ODQtMy4wNDMsMTI0LjUxOS01Ni4xNTMsMjAzLjMyOSIvPiA8cGF0aCBkPSJNMzQ4LjI4MiwyNjMuOTUzYzAsMCwzLjQ2MSwxNy4wMzYsNTMuNzY0LDYuNjUzYzIyLjA0LTQuNTUyLDguNzc2LDEyLjc3NC0xMy41NzcsMjMuMTU1Yy0xOC4zNDUsOC41MTQtNTkuNDc0LDEwLjY5Ni02MC4xNDYtMS4wNjljLTEuNzI5LTMwLjM1NSwyMS42NDctMjEuMTMzLDE5Ljk2LTI4LjczOWMtMS41MjUtNi44NS0xMS45NzktMTMuNTczLTE4Ljg5NC0zMC4zMzggYy02LjAzNy0xNC42MzMtODIuNzk2LTEyNi44NDksMjEuMjg3LTExMC4xODNjMy44MTMtMC43ODktMjcuMTQ2LTk5LjAwMi0xMjQuNTUzLTEwMC41OTljLTk3LjM4NS0xLjU5Ny05NC4xOSwxMTkuNzYyLTk0LjE5LDExOS43NjIiIHN0eWxlPSJzdHJva2UtbGluZWpvaW46YmV2ZWwiLz4gPHBhdGggZD0iTTE4OC42MDQsMjc0LjMzNGMtMTMuNTc3LDE1LjE2Ni05LjU4NCwxNy44MjktMzYuNzIzLDIzLjQxN2MtMjcuNDU5LDUuNjYtMTEuMzI2LDE1LjczMy0wLjc5NywxOC4zNjVjMTIuNzY4LDMuMTk1LDQyLjMwNyw3LjcxOCw2Mi4yNjYtMjAuMjI5YzYuMDc4LTguNTA5LTAuMDM2LTIyLjA4Ni04LjM4NS0yNS41NDdjLTQuMDM0LTEuNjcxLTkuNDI4LTMuNzY1LTE2LjM2MSwzLjk5NHoiLz4gPHBhdGggZD0iTTE4Ny43MTUsMjc0LjA2OWMtMS4zNjgtOC45MTcsMi45My0xOS41MjgsNy41MzYtMzEuOTQyYzYuOTIyLTE4LjYyNiwyMi44OTMtMzcuMjU1LDEwLjExNy05Ni4zMzljLTkuNTIzLTQ0LjAyOS03My4zOTYtOS4xNjMtNzMuNDM2LTMuMTkzYy0wLjAzOSw1Ljk2OCwyLjg4OSwzMC4yNi0xLjA2Nyw1OC41NDhjLTUuMTYyLDM2LjkxMywyMy40ODgsNjguMTMyLDU2LjQ3OSw2NC45MzgiLz4gPHBhdGggZD0iTTE3Mi41MTcsMTQxLjdjLTAuMjg4LDIuMDM5LDMuNzMzLDcuNDgsOC45NzYsOC4yMDdjNS4yMzQsMC43Myw5LjcxNC0zLjUyMiw5Ljk5OC01LjU1OWMwLjI4NC0yLjAzOS0zLjczMi00LjI4NS04Ljk3Ny01LjAxNWMtNS4yMzctMC43MzEtOS43MTksMC4zMzMtOS45OTYsMi4zNjd6IiBzdHlsZT0iZmlsbDojRkZGRkZGO3N0cm9rZS13aWR0aDo0LjE1NTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNMzMxLjk0MSwxMzcuNTQzYzAuMjg0LDIuMDM5LTMuNzMyLDcuNDgtOC45NzYsOC4yMDdjLTUuMjM4LDAuNzMtOS43MTgtMy41MjItMTAuMDA1LTUuNTU5Yy0wLjI3Ny0yLjAzOSwzLjc0LTQuMjg1LDguOTc5LTUuMDE1YzUuMjM5LTAuNzMsOS43MTgsMC4zMzMsMTAuMDAyLDIuMzY4eiIgc3R5bGU9ImZpbGw6I0ZGRkZGRjtzdHJva2Utd2lkdGg6Mi4wNzc1O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyIi8+IDxwYXRoIGQ9Ik0zNTAuNjc2LDEyMy40MzJjMC44NjMsMTUuOTk0LTMuNDQ1LDI2Ljg4OC0zLjk4OCw0My45MTRjLTAuODA0LDI0Ljc0OCwxMS43OTksNTMuMDc0LTcuMTkxLDgxLjQzNSIvPiA8cGF0aCBkPSJNMCw2MC4yMzIiIHN0eWxlPSJzdHJva2Utd2lkdGg6MyIvPiA8L2c+PC9zdmc+Cjx0ZXh0IHg9IjcxMiIgeT0iMTAzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjEycHgiPk9DSSBQb3N0Z3JlU1FMPC90ZXh0Pgo8dGV4dCB4PSI3MTIiIHk9IjEyMiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPlBvc3RncmVTUUwgZW5naW5lPC90ZXh0Pgo8dGV4dCB4PSIyMDAiIHk9IjE1OCIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjgiPk1BTkFHRU1FTlQgUkVRVUVTVFMgwrcgVklBIFRFTlNPUjk8L3RleHQ+CjxsaW5lIHgxPSIxNTQiIHkxPSIxOTYiIHgyPSIzMDAiIHkyPSIxOTYiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtb2NpLXBvc3RncmVzcWwpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iMjI3IiB5PSIxODgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiIj5SRFMgQVBJPC90ZXh0Pgo8cmVjdCB4PSIzMDQiIHk9IjE2NCIgd2lkdGg9IjE4MCIgaGVpZ2h0PSI2NiIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSIzOTQiIHk9IjE5MSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTc7IGZvbnQtc2l6ZToxMnB4Ij5UZW5zb3I5PC90ZXh0PgogIDx0ZXh0IHg9IjM5NCIgeT0iMjA4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij5zZXJ2aWNlIGFkYXB0ZXI8L3RleHQ+CjxsaW5lIHgxPSI0ODQiIHkxPSIxOTYiIHgyPSI2MTAiIHkyPSIxOTYiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtb2NpLXBvc3RncmVzcWwpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHJlY3QgeD0iNjE0IiB5PSIxNjQiIHdpZHRoPSIxOTYiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iNzEyIiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTEuNXB4Ij5PQ0kgbWFuYWdlbWVudCBBUEk8L3RleHQ+Cjx0ZXh0IHg9IjcxMiIgeT0iMjEwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+dGhlIGJhY2tlbmQncyBtYW5hZ2VtZW50IEFQSTwvdGV4dD4KPC9zdmc+)

![Database requests (SQL over pgwire) connect directly to OCI PostgreSQL. The Tensor9 service adapter translates RDS API management calls to OCI management API.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgcGd3aXJlKSBjb25uZWN0IGRpcmVjdGx5IHRvIE9DSSBQb3N0Z3JlU1FMLiBUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgdHJhbnNsYXRlcyBSRFMgQVBJIG1hbmFnZW1lbnQgY2FsbHMgdG8gT0NJIG1hbmFnZW1lbnQgQVBJLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaGQtb2NpLXBvc3RncmVzcWwiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjciIG1hcmtlckhlaWdodD0iNyIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6IzY0NzQ4YiIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iOCIgeT0iMzQiIHdpZHRoPSI4MjAiIGhlaWdodD0iMjA2IiByeD0iMTYiIHN0cm9rZS13aWR0aD0iMS40IiBzdHJva2UtZGFzaGFycmF5PSI1IDUiIHN0eWxlPSJmaWxsOiMwZjE3MmE7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iMjYiIHk9IjU0IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzY0NzQ4YjsgZmlsbDojNmVlN2I3Ij5PTiBPQ0k8L3RleHQ+PHN2ZyB4PSI3OTIiIHk9IjM2IiB3aWR0aD0iMTYiIGhlaWdodD0iMTYiIHZpZXdCb3g9IjAgMCAyNCAyNCIgcHJlc2VydmVBc3BlY3RSYXRpbz0ieE1pZFlNaWQgbWVldCI+PHBhdGggZmlsbD0iI0M3NDYzNCIgZD0iTTE2LjQxMiA0LjQxMmgtOC44MmE3LjU4OCA3LjU4OCAwIDAgMC0uMDA4IDE1LjE3Nmg4LjgyOGE3LjU4OCA3LjU4OCAwIDAgMCAwLTE1LjE3Nm0tLjE5MyAxMi41MDJINy43ODZhNC45MTUgNC45MTUgMCAwIDEgMC05LjgyOGg4LjQzM2E0LjkxNCA0LjkxNCAwIDEgMSAwIDkuODI4Ii8+PC9zdmc+CjxyZWN0IHg9IjI2IiB5PSI4OCIgd2lkdGg9IjEyOCIgaGVpZ2h0PSIxMTIiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iOTAiIHk9IjEyNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxM3B4Ij5Zb3VyIGFwcDwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjE0NSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPlBvc3RncmVTUUwgZHJpdmVyPC90ZXh0Pgo8dGV4dCB4PSI5MCIgeT0iMTYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPnVuY2hhbmdlZDwvdGV4dD4KPHRleHQgeD0iMjAwIiB5PSI4MiIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGI7IGZpbGw6IzZlZTdiNyI+REFUQUJBU0UgUkVRVUVTVFMgwrcgRElSRUNUIENPTk5FQ1RJT048L3RleHQ+CjxsaW5lIHgxPSIxNTQiIHkxPSIxMDgiIHgyPSI2MTAiIHkyPSIxMDgiIHN0cm9rZS13aWR0aD0iMi4yIiBtYXJrZXItZW5kPSJ1cmwoI2FoZC1vY2ktcG9zdGdyZXNxbCkiIHN0eWxlPSJzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSIzODIiIHk9IjEwMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZpbGw6IzZlZTdiNyI+U1FMIG92ZXIgcGd3aXJlPC90ZXh0Pgo8cmVjdCB4PSI2MTQiIHk9Ijc2IiB3aWR0aD0iMTk2IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+PHN2ZyB4PSI3ODYiIHk9IjU2IiB3aWR0aD0iMjAiIGhlaWdodD0iMjAiIHZpZXdCb3g9IjAgMCA0MzIuMDcxIDQ0NS4zODMiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiPjxnIHN0eWxlPSJmaWxsLXJ1bGU6bm9uemVybztjbGlwLXJ1bGU6bm9uemVybztzdHJva2U6IzAwMDAwMDtzdHJva2UtbWl0ZXJsaW1pdDo0Ij4gPC9nPiA8ZyBzdHlsZT0iZmlsbC1ydWxlOm5vbnplcm87Y2xpcC1ydWxlOm5vbnplcm87ZmlsbDpub25lO3N0cm9rZTojRkZGRkZGO3N0cm9rZS13aWR0aDoxMi40NjUxO3N0cm9rZS1saW5lY2FwOnJvdW5kO3N0cm9rZS1saW5lam9pbjpyb3VuZDtzdHJva2UtbWl0ZXJsaW1pdDo0Ij4gPHBhdGggZD0iTTMyMy4yMDUsMzI0LjIyN2MyLjgzMy0yMy42MDEsMS45ODQtMjcuMDYyLDE5LjU2My0yMy4yMzlsNC40NjMsMC4zOTJjMTMuNTE3LDAuNjE1LDMxLjE5OS0yLjE3NCw0MS41ODctN2MyMi4zNjItMTAuMzc2LDM1LjYyMi0yNy43LDEzLjU3Mi0yMy4xNDhjLTUwLjI5NywxMC4zNzYtNTMuNzU1LTYuNjU1LTUzLjc1NS02LjY1NWM1My4xMTEtNzguODAzLDc1LjMxMy0xNzguODM2LDU2LjE0OS0yMDMuMzIyIEMzNTIuNTE0LTUuNTM0LDI2Mi4wMzYsMjYuMDQ5LDI2MC41MjIsMjYuODY5bC0wLjQ4MiwwLjA4OWMtOS45MzgtMi4wNjItMjEuMDYtMy4yOTQtMzMuNTU0LTMuNDk2Yy0yMi43NjEtMC4zNzQtNDAuMDMyLDUuOTY3LTUzLjEzMywxNS45MDRjMCwwLTE2MS40MDgtNjYuNDk4LTE1My44OTksODMuNjI4YzEuNTk3LDMxLjkzNiw0NS43NzcsMjQxLjY1NSw5OC40NywxNzguMzEgYzE5LjI1OS0yMy4xNjMsMzcuODcxLTQyLjc0OCwzNy44NzEtNDIuNzQ4YzkuMjQyLDYuMTQsMjAuMzA3LDkuMjcyLDMxLjkxMiw4LjE0N2wwLjg5Ny0wLjc2NWMtMC4yODEsMi44NzYtMC4xNTcsNS42ODksMC4zNTksOS4wMTljLTEzLjU3MiwxNS4xNjctOS41ODQsMTcuODMtMzYuNzIzLDIzLjQxNmMtMjcuNDU3LDUuNjU5LTExLjMyNiwxNS43MzQtMC43OTcsMTguMzY3YzEyLjc2OCwzLjE5Myw0Mi4zMDUsNy43MTYsNjIuMjY4LTIwLjIyNCBsLTAuNzk1LDMuMTg4YzUuMzI1LDQuMjYsNC45NjUsMzAuNjE5LDUuNzIsNDkuNDUyYzAuNzU2LDE4LjgzNCwyLjAxNywzNi40MDksNS44NTYsNDYuNzcxYzMuODM5LDEwLjM2LDguMzY5LDM3LjA1LDQ0LjAzNiwyOS40MDZjMjkuODA5LTYuMzg4LDUyLjYtMTUuNTgyLDU0LjY3Ny0xMDEuMTA3IiBzdHlsZT0iZmlsbDojMDAwMDAwO3N0cm9rZTojMDAwMDAwO3N0cm9rZS13aWR0aDozNy4zOTUzO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyIi8+IDxwYXRoIGQ9Ik00MDIuMzk1LDI3MS4yM2MtNTAuMzAyLDEwLjM3Ni01My43Ni02LjY1NS01My43Ni02LjY1NWM1My4xMTEtNzguODA4LDc1LjMxMy0xNzguODQzLDU2LjE1My0yMDMuMzI2Yy01Mi4yNy02Ni43ODUtMTQyLjc1Mi0zNS4yLTE0NC4yNjItMzQuMzhsLTAuNDg2LDAuMDg3Yy05LjkzOC0yLjA2My0yMS4wNi0zLjI5Mi0zMy41Ni0zLjQ5NmMtMjIuNzYxLTAuMzczLTQwLjAyNiw1Ljk2Ny01My4xMjcsMTUuOTAyIGMwLDAtMTYxLjQxMS02Ni40OTUtMTUzLjkwNCw4My42M2MxLjU5NywzMS45MzgsNDUuNzc2LDI0MS42NTcsOTguNDcxLDE3OC4zMTJjMTkuMjYtMjMuMTYzLDM3Ljg2OS00Mi43NDgsMzcuODY5LTQyLjc0OGM5LjI0Myw2LjE0LDIwLjMwOCw5LjI3MiwzMS45MDgsOC4xNDdsMC45MDEtMC43NjVjLTAuMjgsMi44NzYtMC4xNTIsNS42ODksMC4zNjEsOS4wMTljLTEzLjU3NSwxNS4xNjctOS41ODYsMTcuODMtMzYuNzIzLDIzLjQxNiBjLTI3LjQ1OSw1LjY1OS0xMS4zMjgsMTUuNzM0LTAuNzk2LDE4LjM2N2MxMi43NjgsMy4xOTMsNDIuMzA3LDcuNzE2LDYyLjI2Ni0yMC4yMjRsLTAuNzk2LDMuMTg4YzUuMzE5LDQuMjYsOS4wNTQsMjcuNzExLDguNDI4LDQ4Ljk2OWMtMC42MjYsMjEuMjU5LTEuMDQ0LDM1Ljg1NCwzLjE0Nyw0Ny4yNTRjNC4xOTEsMTEuNCw4LjM2OCwzNy4wNSw0NC4wNDIsMjkuNDA2YzI5LjgwOS02LjM4OCw0NS4yNTYtMjIuOTQyLDQ3LjQwNS01MC41NTUgYzEuNTI1LTE5LjYzMSw0Ljk3Ni0xNi43MjksNS4xOTQtMzQuMjhsMi43NjgtOC4zMDljMy4xOTItMjYuNjExLDAuNTA3LTM1LjE5NiwxOC44NzItMzEuMjAzbDQuNDYzLDAuMzkyYzEzLjUxNywwLjYxNSwzMS4yMDgtMi4xNzQsNDEuNTkxLTdjMjIuMzU4LTEwLjM3NiwzNS42MTgtMjcuNywxMy41NzMtMjMuMTQ4eiIgc3R5bGU9ImZpbGw6IzMzNjc5MTtzdHJva2U6bm9uZSIvPiA8cGF0aCBkPSJNMjE1Ljg2NiwyODYuNDg0Yy0xLjM4NSw0OS41MTYsMC4zNDgsOTkuMzc3LDUuMTkzLDExMS40OTVjNC44NDgsMTIuMTE4LDE1LjIyMywzNS42ODgsNTAuOSwyOC4wNDVjMjkuODA2LTYuMzksNDAuNjUxLTE4Ljc1Niw0NS4zNTctNDYuMDUxYzMuNDY2LTIwLjA4MiwxMC4xNDgtNzUuODU0LDExLjAwNS04Ny4yODEiLz4gPHBhdGggZD0iTTE3My4xMDQsMzguMjU2YzAsMC0xNjEuNTIxLTY2LjAxNi0xNTQuMDEyLDg0LjEwOWMxLjU5NywzMS45MzgsNDUuNzc5LDI0MS42NjQsOTguNDczLDE3OC4zMTZjMTkuMjU2LTIzLjE2NiwzNi42NzEtNDEuMzM1LDM2LjY3MS00MS4zMzUiLz4gPHBhdGggZD0iTTI2MC4zNDksMjYuMjA3Yy01LjU5MSwxLjc1Myw4OS44NDgtMzQuODg5LDE0NC4wODcsMzQuNDE3YzE5LjE1OSwyNC40ODQtMy4wNDMsMTI0LjUxOS01Ni4xNTMsMjAzLjMyOSIvPiA8cGF0aCBkPSJNMzQ4LjI4MiwyNjMuOTUzYzAsMCwzLjQ2MSwxNy4wMzYsNTMuNzY0LDYuNjUzYzIyLjA0LTQuNTUyLDguNzc2LDEyLjc3NC0xMy41NzcsMjMuMTU1Yy0xOC4zNDUsOC41MTQtNTkuNDc0LDEwLjY5Ni02MC4xNDYtMS4wNjljLTEuNzI5LTMwLjM1NSwyMS42NDctMjEuMTMzLDE5Ljk2LTI4LjczOWMtMS41MjUtNi44NS0xMS45NzktMTMuNTczLTE4Ljg5NC0zMC4zMzggYy02LjAzNy0xNC42MzMtODIuNzk2LTEyNi44NDksMjEuMjg3LTExMC4xODNjMy44MTMtMC43ODktMjcuMTQ2LTk5LjAwMi0xMjQuNTUzLTEwMC41OTljLTk3LjM4NS0xLjU5Ny05NC4xOSwxMTkuNzYyLTk0LjE5LDExOS43NjIiIHN0eWxlPSJzdHJva2UtbGluZWpvaW46YmV2ZWwiLz4gPHBhdGggZD0iTTE4OC42MDQsMjc0LjMzNGMtMTMuNTc3LDE1LjE2Ni05LjU4NCwxNy44MjktMzYuNzIzLDIzLjQxN2MtMjcuNDU5LDUuNjYtMTEuMzI2LDE1LjczMy0wLjc5NywxOC4zNjVjMTIuNzY4LDMuMTk1LDQyLjMwNyw3LjcxOCw2Mi4yNjYtMjAuMjI5YzYuMDc4LTguNTA5LTAuMDM2LTIyLjA4Ni04LjM4NS0yNS41NDdjLTQuMDM0LTEuNjcxLTkuNDI4LTMuNzY1LTE2LjM2MSwzLjk5NHoiLz4gPHBhdGggZD0iTTE4Ny43MTUsMjc0LjA2OWMtMS4zNjgtOC45MTcsMi45My0xOS41MjgsNy41MzYtMzEuOTQyYzYuOTIyLTE4LjYyNiwyMi44OTMtMzcuMjU1LDEwLjExNy05Ni4zMzljLTkuNTIzLTQ0LjAyOS03My4zOTYtOS4xNjMtNzMuNDM2LTMuMTkzYy0wLjAzOSw1Ljk2OCwyLjg4OSwzMC4yNi0xLjA2Nyw1OC41NDhjLTUuMTYyLDM2LjkxMywyMy40ODgsNjguMTMyLDU2LjQ3OSw2NC45MzgiLz4gPHBhdGggZD0iTTE3Mi41MTcsMTQxLjdjLTAuMjg4LDIuMDM5LDMuNzMzLDcuNDgsOC45NzYsOC4yMDdjNS4yMzQsMC43Myw5LjcxNC0zLjUyMiw5Ljk5OC01LjU1OWMwLjI4NC0yLjAzOS0zLjczMi00LjI4NS04Ljk3Ny01LjAxNWMtNS4yMzctMC43MzEtOS43MTksMC4zMzMtOS45OTYsMi4zNjd6IiBzdHlsZT0iZmlsbDojRkZGRkZGO3N0cm9rZS13aWR0aDo0LjE1NTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNMzMxLjk0MSwxMzcuNTQzYzAuMjg0LDIuMDM5LTMuNzMyLDcuNDgtOC45NzYsOC4yMDdjLTUuMjM4LDAuNzMtOS43MTgtMy41MjItMTAuMDA1LTUuNTU5Yy0wLjI3Ny0yLjAzOSwzLjc0LTQuMjg1LDguOTc5LTUuMDE1YzUuMjM5LTAuNzMsOS43MTgsMC4zMzMsMTAuMDAyLDIuMzY4eiIgc3R5bGU9ImZpbGw6I0ZGRkZGRjtzdHJva2Utd2lkdGg6Mi4wNzc1O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyIi8+IDxwYXRoIGQ9Ik0zNTAuNjc2LDEyMy40MzJjMC44NjMsMTUuOTk0LTMuNDQ1LDI2Ljg4OC0zLjk4OCw0My45MTRjLTAuODA0LDI0Ljc0OCwxMS43OTksNTMuMDc0LTcuMTkxLDgxLjQzNSIvPiA8cGF0aCBkPSJNMCw2MC4yMzIiIHN0eWxlPSJzdHJva2Utd2lkdGg6MyIvPiA8L2c+PC9zdmc+Cjx0ZXh0IHg9IjcxMiIgeT0iMTAzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjEycHgiPk9DSSBQb3N0Z3JlU1FMPC90ZXh0Pgo8dGV4dCB4PSI3MTIiIHk9IjEyMiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPlBvc3RncmVTUUwgZW5naW5lPC90ZXh0Pgo8dGV4dCB4PSIyMDAiIHk9IjE1OCIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGIiPk1BTkFHRU1FTlQgUkVRVUVTVFMgwrcgVklBIFRFTlNPUjk8L3RleHQ+CjxsaW5lIHgxPSIxNTQiIHkxPSIxOTYiIHgyPSIzMDAiIHkyPSIxOTYiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtb2NpLXBvc3RncmVzcWwpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iMjI3IiB5PSIxODgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4Ij5SRFMgQVBJPC90ZXh0Pgo8cmVjdCB4PSIzMDQiIHk9IjE2NCIgd2lkdGg9IjE4MCIgaGVpZ2h0PSI2NiIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSIzOTQiIHk9IjE5MSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3Yjc7IGZvbnQtc2l6ZToxMnB4Ij5UZW5zb3I5PC90ZXh0PgogIDx0ZXh0IHg9IjM5NCIgeT0iMjA4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij5zZXJ2aWNlIGFkYXB0ZXI8L3RleHQ+CjxsaW5lIHgxPSI0ODQiIHkxPSIxOTYiIHgyPSI2MTAiIHkyPSIxOTYiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtb2NpLXBvc3RncmVzcWwpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHJlY3QgeD0iNjE0IiB5PSIxNjQiIHdpZHRoPSIxOTYiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iNzEyIiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTEuNXB4Ij5PQ0kgbWFuYWdlbWVudCBBUEk8L3RleHQ+Cjx0ZXh0IHg9IjcxMiIgeT0iMjEwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+dGhlIGJhY2tlbmQncyBtYW5hZ2VtZW50IEFQSTwvdGV4dD4KPC9zdmc+)

Queries reach the database directly; only the management calls are translated.

#### Database connections

Aurora stores data in an AWS-specific storage layer, but your application reaches it over the standard PostgreSQL wire protocol, which OCI Database with PostgreSQL also supports. Your SQL, drivers, object-relational mappers (ORMs), prepared statements, data types and transaction behavior stay the same; only the storage underneath changes.

AWS and Aurora add SQL functions for moving data through S3, invoking Lambda and machine learning. These functions do not exist on the backend, so a query that calls them returns an error.

#### Database management

At runtime your application and tools keep making the same RDS calls. Where OCI has an equivalent, the adapter accepts the RDS request, returns the RDS response format, and performs the operation on OCI: on-demand backups and restore from backup, in-region readers, stop / start, and compute, storage and configuration updates. The adapter does not translate every native OCI feature into Aurora behavior; the limitations below list the differences. An unsupported operation returns an error.

The adapter also runs the Aurora Data API (SQL over HTTPS, transactions included), executing each statement over a native connection to the backend database.

With Max, your tools call `CreateDBCluster` and `CreateDBInstance` through the RDS adapter to create a logical Aurora cluster and its members on OCI PostgreSQL. Tensor9 keeps a durable record of the logical cluster and its members and reconciles the OCI resources with it: it records each accepted request, then creates or removes the OCI resources in the background. `DescribeDBClusters` and `DescribeDBInstances` report status and endpoints. `DeleteDBInstance` removes members; `DeleteDBCluster` removes the cluster once its members are gone. Your application's SQL connection still goes directly to the database. With the Infrastructure-only option, Tensor9 compiles the declared cluster into OCI PostgreSQL resources, which you manage with Oracle's own tools; runtime RDS API calls require Max.

![The Tensor9 service adapter handles RDS management requests using OCI management API and returns RDS responses.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTk2IiB2aWV3Qm94PSIwIDAgODM2IDE5NiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgaGFuZGxlcyBSRFMgbWFuYWdlbWVudCByZXF1ZXN0cyB1c2luZyBPQ0kgbWFuYWdlbWVudCBBUEkgYW5kIHJldHVybnMgUkRTIHJlc3BvbnNlcy4iPjxzdHlsZT50ZXh0e2ZvbnQtZmFtaWx5OkludGVyLC1hcHBsZS1zeXN0ZW0sQmxpbmtNYWNTeXN0ZW1Gb250LCdTZWdvZSBVSScsUm9ib3RvLCdIZWx2ZXRpY2EgTmV1ZScsQXJpYWwsc2Fucy1zZXJpZjtmaWxsOiMzMzQxNTV9PC9zdHlsZT4KPGRlZnM+PG1hcmtlciBpZD0iYWhjLXJkcy1vY2ktbWFuYWdlbWVudC1hcGkiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjciIG1hcmtlckhlaWdodD0iNyIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6Izk0YTNiOCIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iMTYiIHk9IjM0IiB3aWR0aD0iMjM2IiBoZWlnaHQ9IjEyOCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSIxMzQiIHk9IjYwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjEyLjVweCI+UkRTIG1hbmFnZW1lbnQgY2FsbDwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSI4MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPnNuYXBzaG90IMK3IHJlc3RvcmUgZnJvbSBiYWNrdXA8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iOTkiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5yZWFkZXIgwrcgc3RvcCAvIHN0YXJ0PC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9IjExNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPkRhdGEgQVBJIMK3IGNvbmZpZ3VyYXRpb248L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iMTQyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YiI+c2FtZSByZXF1ZXN0IC8gcmVzcG9uc2Ugc2hhcGVzPC90ZXh0Pgo8bGluZSB4MT0iMjUyIiB5MT0iNzQiIHgyPSIzMTQiIHkyPSI3NCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtb2NpLW1hbmFnZW1lbnQtYXBpKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxsaW5lIHgxPSIzMTgiIHkxPSIxMjgiIHgyPSIyNTYiIHkyPSIxMjgiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLW9jaS1tYW5hZ2VtZW50LWFwaSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8cmVjdCB4PSIzMTgiIHk9IjU0IiB3aWR0aD0iMjA0IiBoZWlnaHQ9Ijg4IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjQyMCIgeT0iOTQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSI0MjAiIHk9IjExMiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+c2VydmljZSBhZGFwdGVyPC90ZXh0Pgo8bGluZSB4MT0iNTIyIiB5MT0iNzQiIHgyPSI1ODQiIHkyPSI3NCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtb2NpLW1hbmFnZW1lbnQtYXBpKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxsaW5lIHgxPSI1ODgiIHkxPSIxMjgiIHgyPSI1MjYiIHkyPSIxMjgiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLW9jaS1tYW5hZ2VtZW50LWFwaSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8cmVjdCB4PSI1ODgiIHk9IjM0IiB3aWR0aD0iMjMyIiBoZWlnaHQ9IjEyOCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSI3MDQiIHk9IjYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjEycHgiPk9DSSBtYW5hZ2VtZW50IEFQSTwvdGV4dD4KPHRleHQgeD0iNzA0IiB5PSI5NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPmJhY2t1cHMgwrcgcmVzdG9yZXMgwrcgcmVwbGljYXM8L3RleHQ+Cjx0ZXh0IHg9IjcwNCIgeT0iMTExIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+c3RvcCAvIHN0YXJ0IMK3IHVwZGF0ZXM8L3RleHQ+Cjwvc3ZnPg==)

![The Tensor9 service adapter handles RDS management requests using OCI management API and returns RDS responses.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTk2IiB2aWV3Qm94PSIwIDAgODM2IDE5NiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgaGFuZGxlcyBSRFMgbWFuYWdlbWVudCByZXF1ZXN0cyB1c2luZyBPQ0kgbWFuYWdlbWVudCBBUEkgYW5kIHJldHVybnMgUkRTIHJlc3BvbnNlcy4iPjxzdHlsZT50ZXh0e2ZvbnQtZmFtaWx5OkludGVyLC1hcHBsZS1zeXN0ZW0sQmxpbmtNYWNTeXN0ZW1Gb250LCdTZWdvZSBVSScsUm9ib3RvLCdIZWx2ZXRpY2EgTmV1ZScsQXJpYWwsc2Fucy1zZXJpZjtmaWxsOiNjYmQ1ZTF9PC9zdHlsZT4KPGRlZnM+PG1hcmtlciBpZD0iYWhjLXJkcy1vY2ktbWFuYWdlbWVudC1hcGkiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjciIG1hcmtlckhlaWdodD0iNyIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6IzY0NzQ4YiIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iMTYiIHk9IjM0IiB3aWR0aD0iMjM2IiBoZWlnaHQ9IjEyOCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSIxMzQiIHk9IjYwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjEyLjVweCI+UkRTIG1hbmFnZW1lbnQgY2FsbDwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSI4MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPnNuYXBzaG90IMK3IHJlc3RvcmUgZnJvbSBiYWNrdXA8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iOTkiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5yZWFkZXIgwrcgc3RvcCAvIHN0YXJ0PC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9IjExNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPkRhdGEgQVBJIMK3IGNvbmZpZ3VyYXRpb248L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iMTQyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiOCI+c2FtZSByZXF1ZXN0IC8gcmVzcG9uc2Ugc2hhcGVzPC90ZXh0Pgo8bGluZSB4MT0iMjUyIiB5MT0iNzQiIHgyPSIzMTQiIHkyPSI3NCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtb2NpLW1hbmFnZW1lbnQtYXBpKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxsaW5lIHgxPSIzMTgiIHkxPSIxMjgiIHgyPSIyNTYiIHkyPSIxMjgiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLW9jaS1tYW5hZ2VtZW50LWFwaSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8cmVjdCB4PSIzMTgiIHk9IjU0IiB3aWR0aD0iMjA0IiBoZWlnaHQ9Ijg4IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjQyMCIgeT0iOTQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSI0MjAiIHk9IjExMiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+c2VydmljZSBhZGFwdGVyPC90ZXh0Pgo8bGluZSB4MT0iNTIyIiB5MT0iNzQiIHgyPSI1ODQiIHkyPSI3NCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtb2NpLW1hbmFnZW1lbnQtYXBpKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxsaW5lIHgxPSI1ODgiIHkxPSIxMjgiIHgyPSI1MjYiIHkyPSIxMjgiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLW9jaS1tYW5hZ2VtZW50LWFwaSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8cmVjdCB4PSI1ODgiIHk9IjM0IiB3aWR0aD0iMjMyIiBoZWlnaHQ9IjEyOCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSI3MDQiIHk9IjYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjEycHgiPk9DSSBtYW5hZ2VtZW50IEFQSTwvdGV4dD4KPHRleHQgeD0iNzA0IiB5PSI5NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPmJhY2t1cHMgwrcgcmVzdG9yZXMgwrcgcmVwbGljYXM8L3RleHQ+Cjx0ZXh0IHg9IjcwNCIgeT0iMTExIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+c3RvcCAvIHN0YXJ0IMK3IHVwZGF0ZXM8L3RleHQ+Cjwvc3ZnPg==)

Tensor9 translates RDS management requests to the backend API and returns RDS responses.

#### Limitations

Where Aurora and OCI PostgreSQL differ

* **Parameter groups behave differently: Tensor9 keeps the group and applies its settings on OCI.** Tensor9 keeps named parameter groups and their overrides. Supported explicit PostgreSQL parameters become OCI PostgreSQL settings; the group object itself stays with Tensor9 and is not created on OCI PostgreSQL. The group family must match the PostgreSQL version, and OCI's limits on allowed values and restarts still apply. RDS-specific parameters and settings outside the backend's settable list are rejected.
* **RDS point-in-time restore is not supported.** OCI has its own point-in-time recovery: it keeps write-ahead logs (WAL) and periodic backups under a point-in-time recovery policy that must be configured, and recovery creates a new database system at a timestamp within the active recovery window. The documented adapter mapping does not promise AWS point-in-time restore translation.
* **RDS failover is not supported.** OCI has `FailoverDbSystem` for user-initiated failover to an existing local replica. The documented adapter mapping does not promise translation of the AWS failover operation.
* **Aurora global databases are not supported.** OCI supports readable warm standby systems in up to three disaster recovery regions. Replication is asynchronous and can lag; promotion and switchover are manual, with no automatic cross-region failover. Restore is not supported for either the primary or warm standby while configured for this replication. The documented adapter mapping does not promise Aurora global-cluster operations, global-reader routing, or automated promotion.
* **In-place major-version upgrades are not supported.** To move to a new PostgreSQL major version on OCI, you create a new database system and migrate to it.
* **Aurora-specific settings and event subscriptions are not supported.** Failover priority tiers, Serverless v2, global write forwarding, I/O-Optimized storage and event subscriptions have no equivalent, as on the other backends.

#### Other considerations

**Migration.** Moving the data is a one-time step, covered by this page's migration note: a logical dump and restore, or logical replication for a short cutover. This page describes how things work after cutover.

**Operations.** The customer owns the database service in their OCI tenancy. Maintenance windows, quotas and pricing are Oracle's.

**Features and capacity.** The comparison table on this page lists feature and high-availability differences. Check the backend's pricing and capacity limits when you size the deployment.

#### 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.

##### Aurora PostgreSQL · Primary allocated compute

Feature: Aurora PostgreSQL.

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.

![Aurora PostgreSQL · 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/f5890bf86b94d3cd23a29eecef7a5b36df223e1badcf57366db620c4c79dbc3f-light.svg)

![Aurora PostgreSQL · 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/7d2f16de4212ba66fbdc351c2bfcd31a6a3d8a973a32870142db81a536be99fe-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) | Aurora PostgreSQL | Target scenario | OCI Database with PostgreSQL | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | OCI Database with PostgreSQL (one copy) | 94.90 | 94.90 |
| 0 | 0.00 | OCI Database with PostgreSQL (two copies) | 173.64 | 173.64 |
| 1,460 | 211.70 | OCI Database with PostgreSQL (one copy) | 94.90 | -116.80 |
| 1,460 | 211.70 | OCI Database with PostgreSQL (two copies) | 173.64 | -38.06 |
| 2,920 | 423.40 | OCI Database with PostgreSQL (one copy) | 173.64 | -249.76 |
| 2,920 | 423.40 | OCI Database with PostgreSQL (two copies) | 340.08 | -83.32 |
| 5,840 | 846.80 | OCI Database with PostgreSQL (one copy) | 340.08 | -506.72 |
| 5,840 | 846.80 | OCI Database with PostgreSQL (two copies) | 672.96 | -173.84 |
| 11,680 | 1,693.60 | OCI Database with PostgreSQL (one copy) | 672.96 | -1,020.64 |
| 11,680 | 1,693.60 | OCI Database with PostgreSQL (two copies) | 1,338.72 | -354.88 |
| 23,360 | 3,387.20 | OCI Database with PostgreSQL (one copy) | 1,338.72 | -2,048.48 |
| 23,360 | 3,387.20 | OCI Database with PostgreSQL (two copies) | 2,670.24 | -716.96 |
| 46,720 | 6,774.40 | OCI Database with PostgreSQL (one copy) | 2,670.24 | -4,104.16 |
| 46,720 | 6,774.40 | OCI Database with PostgreSQL (two copies) | 5,333.28 | -1,441.12 |

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 Database with PostgreSQL (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| OCI Database with PostgreSQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| OCI Database with PostgreSQL (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| OCI Database with PostgreSQL (one copy) | Origin list price · Database reads | 0 | USD/operations |
| OCI Database with PostgreSQL (one copy) | Origin list price · Database writes | 0 | USD/operations |
| OCI Database with PostgreSQL (one copy) | Target CPU / source CPU | 1 | multiplier |
| OCI Database with PostgreSQL (one copy) | Target RAM / source RAM | 1 | multiplier |
| OCI Database with PostgreSQL (one copy) | Target disk / source disk | 1 | multiplier |
| OCI Database with PostgreSQL (one copy) | Target price guess · read | 0 | USD/read |
| OCI Database with PostgreSQL (one copy) | Target price guess · write | 0 | USD/write |
| OCI Database with PostgreSQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| OCI Database with PostgreSQL (one copy) | Target list price · GiB-month | 0.072 | USD/GiB-month |
| OCI Database with PostgreSQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| OCI Database with PostgreSQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| OCI Database with PostgreSQL (one copy) | Target list price · network GiB | 0 | USD/network GiB |
| OCI Database with PostgreSQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| OCI Database with PostgreSQL (one copy) | Target list price · vCPU-hour | 0.049 | USD/vCPU-hour |
| OCI Database with PostgreSQL (one copy) | Target list price · GiB-hour | 0.002 | USD/GiB-hour |
| OCI Database with PostgreSQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| OCI Database with PostgreSQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| OCI Database with PostgreSQL (one copy) | Target price guess · input token | 0 | USD/input token |
| OCI Database with PostgreSQL (one copy) | Target price guess · output token | 0 | USD/output token |
| OCI Database with PostgreSQL (one copy) | Target monthly base charge | 0 | USD/month |
| OCI Database with PostgreSQL (one copy) | Target service minimum | 94.9 | USD/month |
| OCI Database with PostgreSQL (one copy) | Minimum primary CPU | 2 | vCPU |
| OCI Database with PostgreSQL (one copy) | Minimum primary RAM | 8 | GiB |
| OCI Database with PostgreSQL (one copy) | Minimum primary disk | 100 | GiB |
| OCI Database with PostgreSQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| OCI Database with PostgreSQL (one copy) | Allocated share of provisioned cost | 1 | fraction |
| OCI Database with PostgreSQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| OCI Database with PostgreSQL (one copy) | Planning peak / mean work | 2 | multiplier |
| OCI Database with PostgreSQL (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| OCI Database with PostgreSQL (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| OCI Database with PostgreSQL (one copy) | Planning disk utilization | 0.8 | fraction |
| OCI Database with PostgreSQL (one copy) | Maintenance and log disk reserve | 20 | GiB |
| OCI Database with PostgreSQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| OCI Database with PostgreSQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| OCI Database with PostgreSQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| OCI Database with PostgreSQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| OCI Database with PostgreSQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| OCI Database with PostgreSQL (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| OCI Database with PostgreSQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| OCI Database with PostgreSQL (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| OCI Database with PostgreSQL (two copies) | Origin list price · Database reads | 0 | USD/operations |
| OCI Database with PostgreSQL (two copies) | Origin list price · Database writes | 0 | USD/operations |
| OCI Database with PostgreSQL (two copies) | Target CPU / source CPU | 1 | multiplier |
| OCI Database with PostgreSQL (two copies) | Target RAM / source RAM | 1 | multiplier |
| OCI Database with PostgreSQL (two copies) | Target disk / source disk | 1 | multiplier |
| OCI Database with PostgreSQL (two copies) | Target price guess · read | 0 | USD/read |
| OCI Database with PostgreSQL (two copies) | Target price guess · write | 0 | USD/write |
| OCI Database with PostgreSQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| OCI Database with PostgreSQL (two copies) | Target list price · GiB-month | 0.072 | USD/GiB-month |
| OCI Database with PostgreSQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| OCI Database with PostgreSQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| OCI Database with PostgreSQL (two copies) | Target list price · network GiB | 0 | USD/network GiB |
| OCI Database with PostgreSQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| OCI Database with PostgreSQL (two copies) | Target list price · vCPU-hour | 0.049 | USD/vCPU-hour |
| OCI Database with PostgreSQL (two copies) | Target list price · GiB-hour | 0.002 | USD/GiB-hour |
| OCI Database with PostgreSQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| OCI Database with PostgreSQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| OCI Database with PostgreSQL (two copies) | Target price guess · input token | 0 | USD/input token |
| OCI Database with PostgreSQL (two copies) | Target price guess · output token | 0 | USD/output token |
| OCI Database with PostgreSQL (two copies) | Target monthly base charge | 0 | USD/month |
| OCI Database with PostgreSQL (two copies) | Target service minimum | 94.9 | USD/month |
| OCI Database with PostgreSQL (two copies) | Minimum primary CPU | 2 | vCPU |
| OCI Database with PostgreSQL (two copies) | Minimum primary RAM | 8 | GiB |
| OCI Database with PostgreSQL (two copies) | Minimum primary disk | 100 | GiB |
| OCI Database with PostgreSQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| OCI Database with PostgreSQL (two copies) | Allocated share of provisioned cost | 1 | fraction |
| OCI Database with PostgreSQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| OCI Database with PostgreSQL (two copies) | Planning peak / mean work | 2 | multiplier |
| OCI Database with PostgreSQL (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| OCI Database with PostgreSQL (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| OCI Database with PostgreSQL (two copies) | Planning disk utilization | 0.8 | fraction |
| OCI Database with PostgreSQL (two copies) | Maintenance and log disk reserve | 20 | GiB |
| OCI Database with PostgreSQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| OCI Database with PostgreSQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| OCI Database with PostgreSQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| OCI Database with PostgreSQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| OCI Database with PostgreSQL (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* OCI Database with PostgreSQL bills provisioned OCPUs (one x86 OCPU is two vCPUs), a memory fee and Database Optimized Storage by used GB. The storage is one pool replicated across availability domains and shared by every node, so it is billed once however many copies run. The memory rate is an assumption (see its source). The smallest shape is PostgreSQL.VM.Standard.E5.Flex with 1 OCPU and 16 GB ([https://docs.oracle.com/en-us/iaas/Content/postgresql/supported-shapes.htm](https://docs.oracle.com/en-us/iaas/Content/postgresql/supported-shapes.htm)). Backups bill as Object Storage and 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: PostgreSQL.VM.Standard.E5.Flex reaches 64 OCPUs (128 vCPUs) and 1,024 GB ([https://docs.oracle.com/en-us/iaas/Content/postgresql/supported-shapes.htm](https://docs.oracle.com/en-us/iaas/Content/postgresql/supported-shapes.htm)); a database system stores up to 32 TB ([https://docs.oracle.com/en-us/iaas/Content/postgresql/manage-databases.htm](https://docs.oracle.com/en-us/iaas/Content/postgresql/manage-databases.htm)).
* 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/)
* Oracle Cloud price list: [https://www.oracle.com/cloud/price-list/](https://www.oracle.com/cloud/price-list/)

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-9631e4e7ad853051d4ac9c6ec36873c05803b586` / `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/), [Oracle Cloud price list](https://www.oracle.com/cloud/price-list/).

##### Aurora PostgreSQL · Stored data

Feature: Aurora PostgreSQL.

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.

![Aurora PostgreSQL · 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/3185a6537347bbe2fe890291046940d596905a322a534c60dee394fa7a35a167-light.svg)

![Aurora PostgreSQL · 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/677dbd986e7dd3de67d7f37f489434dfb93fac00b8f05d8722fd77c55839130a-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) | Aurora PostgreSQL | Target scenario | OCI Database with PostgreSQL | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | OCI Database with PostgreSQL (one copy) | 94.90 | 94.90 |
| 0 | 0.00 | OCI Database with PostgreSQL (two copies) | 173.64 | 173.64 |
| 10 | 1.00 | OCI Database with PostgreSQL (one copy) | 94.90 | 93.90 |
| 10 | 1.00 | OCI Database with PostgreSQL (two copies) | 173.64 | 172.64 |
| 100 | 10.00 | OCI Database with PostgreSQL (one copy) | 94.90 | 84.90 |
| 100 | 10.00 | OCI Database with PostgreSQL (two copies) | 177.24 | 167.24 |
| 1,000 | 100.00 | OCI Database with PostgreSQL (one copy) | 175.02 | 75.02 |
| 1,000 | 100.00 | OCI Database with PostgreSQL (two copies) | 258.24 | 158.24 |
| 10,000 | 1,000.00 | OCI Database with PostgreSQL (one copy) | 985.02 | -14.98 |
| 10,000 | 1,000.00 | OCI Database with PostgreSQL (two copies) | 1,068.24 | 68.24 |
| 100,000 | 10,000.00 | OCI Database with PostgreSQL (one copy) | Unpriced | Unavailable |
| 100,000 | 10,000.00 | OCI Database with PostgreSQL (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 Database with PostgreSQL (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| OCI Database with PostgreSQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| OCI Database with PostgreSQL (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| OCI Database with PostgreSQL (one copy) | Origin list price · Database reads | 0 | USD/operations |
| OCI Database with PostgreSQL (one copy) | Origin list price · Database writes | 0 | USD/operations |
| OCI Database with PostgreSQL (one copy) | Target CPU / source CPU | 1 | multiplier |
| OCI Database with PostgreSQL (one copy) | Target RAM / source RAM | 1 | multiplier |
| OCI Database with PostgreSQL (one copy) | Target disk / source disk | 1 | multiplier |
| OCI Database with PostgreSQL (one copy) | Target price guess · read | 0 | USD/read |
| OCI Database with PostgreSQL (one copy) | Target price guess · write | 0 | USD/write |
| OCI Database with PostgreSQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| OCI Database with PostgreSQL (one copy) | Target list price · GiB-month | 0.072 | USD/GiB-month |
| OCI Database with PostgreSQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| OCI Database with PostgreSQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| OCI Database with PostgreSQL (one copy) | Target list price · network GiB | 0 | USD/network GiB |
| OCI Database with PostgreSQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| OCI Database with PostgreSQL (one copy) | Target list price · vCPU-hour | 0.049 | USD/vCPU-hour |
| OCI Database with PostgreSQL (one copy) | Target list price · GiB-hour | 0.002 | USD/GiB-hour |
| OCI Database with PostgreSQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| OCI Database with PostgreSQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| OCI Database with PostgreSQL (one copy) | Target price guess · input token | 0 | USD/input token |
| OCI Database with PostgreSQL (one copy) | Target price guess · output token | 0 | USD/output token |
| OCI Database with PostgreSQL (one copy) | Target monthly base charge | 0 | USD/month |
| OCI Database with PostgreSQL (one copy) | Target service minimum | 94.9 | USD/month |
| OCI Database with PostgreSQL (one copy) | Minimum primary CPU | 2 | vCPU |
| OCI Database with PostgreSQL (one copy) | Minimum primary RAM | 8 | GiB |
| OCI Database with PostgreSQL (one copy) | Minimum primary disk | 100 | GiB |
| OCI Database with PostgreSQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| OCI Database with PostgreSQL (one copy) | Allocated share of provisioned cost | 1 | fraction |
| OCI Database with PostgreSQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| OCI Database with PostgreSQL (one copy) | Planning peak / mean work | 2 | multiplier |
| OCI Database with PostgreSQL (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| OCI Database with PostgreSQL (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| OCI Database with PostgreSQL (one copy) | Planning disk utilization | 0.8 | fraction |
| OCI Database with PostgreSQL (one copy) | Maintenance and log disk reserve | 20 | GiB |
| OCI Database with PostgreSQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| OCI Database with PostgreSQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| OCI Database with PostgreSQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| OCI Database with PostgreSQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| OCI Database with PostgreSQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| OCI Database with PostgreSQL (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| OCI Database with PostgreSQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| OCI Database with PostgreSQL (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| OCI Database with PostgreSQL (two copies) | Origin list price · Database reads | 0 | USD/operations |
| OCI Database with PostgreSQL (two copies) | Origin list price · Database writes | 0 | USD/operations |
| OCI Database with PostgreSQL (two copies) | Target CPU / source CPU | 1 | multiplier |
| OCI Database with PostgreSQL (two copies) | Target RAM / source RAM | 1 | multiplier |
| OCI Database with PostgreSQL (two copies) | Target disk / source disk | 1 | multiplier |
| OCI Database with PostgreSQL (two copies) | Target price guess · read | 0 | USD/read |
| OCI Database with PostgreSQL (two copies) | Target price guess · write | 0 | USD/write |
| OCI Database with PostgreSQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| OCI Database with PostgreSQL (two copies) | Target list price · GiB-month | 0.072 | USD/GiB-month |
| OCI Database with PostgreSQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| OCI Database with PostgreSQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| OCI Database with PostgreSQL (two copies) | Target list price · network GiB | 0 | USD/network GiB |
| OCI Database with PostgreSQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| OCI Database with PostgreSQL (two copies) | Target list price · vCPU-hour | 0.049 | USD/vCPU-hour |
| OCI Database with PostgreSQL (two copies) | Target list price · GiB-hour | 0.002 | USD/GiB-hour |
| OCI Database with PostgreSQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| OCI Database with PostgreSQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| OCI Database with PostgreSQL (two copies) | Target price guess · input token | 0 | USD/input token |
| OCI Database with PostgreSQL (two copies) | Target price guess · output token | 0 | USD/output token |
| OCI Database with PostgreSQL (two copies) | Target monthly base charge | 0 | USD/month |
| OCI Database with PostgreSQL (two copies) | Target service minimum | 94.9 | USD/month |
| OCI Database with PostgreSQL (two copies) | Minimum primary CPU | 2 | vCPU |
| OCI Database with PostgreSQL (two copies) | Minimum primary RAM | 8 | GiB |
| OCI Database with PostgreSQL (two copies) | Minimum primary disk | 100 | GiB |
| OCI Database with PostgreSQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| OCI Database with PostgreSQL (two copies) | Allocated share of provisioned cost | 1 | fraction |
| OCI Database with PostgreSQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| OCI Database with PostgreSQL (two copies) | Planning peak / mean work | 2 | multiplier |
| OCI Database with PostgreSQL (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| OCI Database with PostgreSQL (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| OCI Database with PostgreSQL (two copies) | Planning disk utilization | 0.8 | fraction |
| OCI Database with PostgreSQL (two copies) | Maintenance and log disk reserve | 20 | GiB |
| OCI Database with PostgreSQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| OCI Database with PostgreSQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| OCI Database with PostgreSQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| OCI Database with PostgreSQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| OCI Database with PostgreSQL (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* OCI Database with PostgreSQL bills provisioned OCPUs (one x86 OCPU is two vCPUs), a memory fee and Database Optimized Storage by used GB. The storage is one pool replicated across availability domains and shared by every node, so it is billed once however many copies run. The memory rate is an assumption (see its source). The smallest shape is PostgreSQL.VM.Standard.E5.Flex with 1 OCPU and 16 GB ([https://docs.oracle.com/en-us/iaas/Content/postgresql/supported-shapes.htm](https://docs.oracle.com/en-us/iaas/Content/postgresql/supported-shapes.htm)). Backups bill as Object Storage and 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: PostgreSQL.VM.Standard.E5.Flex reaches 64 OCPUs (128 vCPUs) and 1,024 GB ([https://docs.oracle.com/en-us/iaas/Content/postgresql/supported-shapes.htm](https://docs.oracle.com/en-us/iaas/Content/postgresql/supported-shapes.htm)); a database system stores up to 32 TB ([https://docs.oracle.com/en-us/iaas/Content/postgresql/manage-databases.htm](https://docs.oracle.com/en-us/iaas/Content/postgresql/manage-databases.htm)).
* 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/)
* Oracle Cloud price list: [https://www.oracle.com/cloud/price-list/](https://www.oracle.com/cloud/price-list/)

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-9631e4e7ad853051d4ac9c6ec36873c05803b586` / `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/), [Oracle Cloud price list](https://www.oracle.com/cloud/price-list/).

##### Aurora PostgreSQL · Database writes

Feature: Aurora PostgreSQL.

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.

![Aurora PostgreSQL · 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/0210e45475993a1768724734516931b5f8faa482c35f966c1c0ff5c6f472e757-light.svg)

![Aurora PostgreSQL · 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/c202643e299ef34107a74b9e15300d7cfeebf9234c2e1c4ef3bc2a0b62d3699c-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) | Aurora PostgreSQL | Target scenario | OCI Database with PostgreSQL | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | OCI Database with PostgreSQL (one copy) | 94.90 | 94.90 |
| 0 | 0.00 | OCI Database with PostgreSQL (two copies) | 173.64 | 173.64 |
| 1 | 0.00 | OCI Database with PostgreSQL (one copy) | 94.90 | 94.90 |
| 1 | 0.00 | OCI Database with PostgreSQL (two copies) | 173.64 | 173.64 |
| 10 | 0.00 | OCI Database with PostgreSQL (one copy) | 94.90 | 94.90 |
| 10 | 0.00 | OCI Database with PostgreSQL (two copies) | 173.64 | 173.64 |
| 100 | 0.00 | OCI Database with PostgreSQL (one copy) | 94.90 | 94.90 |
| 100 | 0.00 | OCI Database with PostgreSQL (two copies) | 173.64 | 173.64 |
| 1,000 | 0.00 | OCI Database with PostgreSQL (one copy) | 94.90 | 94.90 |
| 1,000 | 0.00 | OCI Database with PostgreSQL (two copies) | 173.64 | 173.64 |
| 10,000 | 0.00 | OCI Database with PostgreSQL (one copy) | 94.90 | 94.90 |
| 10,000 | 0.00 | OCI Database with PostgreSQL (two copies) | 173.64 | 173.64 |

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 Database with PostgreSQL (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| OCI Database with PostgreSQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| OCI Database with PostgreSQL (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| OCI Database with PostgreSQL (one copy) | Origin list price · Database reads | 0 | USD/operations |
| OCI Database with PostgreSQL (one copy) | Origin list price · Database writes | 0 | USD/operations |
| OCI Database with PostgreSQL (one copy) | Target CPU / source CPU | 1 | multiplier |
| OCI Database with PostgreSQL (one copy) | Target RAM / source RAM | 1 | multiplier |
| OCI Database with PostgreSQL (one copy) | Target disk / source disk | 1 | multiplier |
| OCI Database with PostgreSQL (one copy) | Target price guess · read | 0 | USD/read |
| OCI Database with PostgreSQL (one copy) | Target price guess · write | 0 | USD/write |
| OCI Database with PostgreSQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| OCI Database with PostgreSQL (one copy) | Target list price · GiB-month | 0.072 | USD/GiB-month |
| OCI Database with PostgreSQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| OCI Database with PostgreSQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| OCI Database with PostgreSQL (one copy) | Target list price · network GiB | 0 | USD/network GiB |
| OCI Database with PostgreSQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| OCI Database with PostgreSQL (one copy) | Target list price · vCPU-hour | 0.049 | USD/vCPU-hour |
| OCI Database with PostgreSQL (one copy) | Target list price · GiB-hour | 0.002 | USD/GiB-hour |
| OCI Database with PostgreSQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| OCI Database with PostgreSQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| OCI Database with PostgreSQL (one copy) | Target price guess · input token | 0 | USD/input token |
| OCI Database with PostgreSQL (one copy) | Target price guess · output token | 0 | USD/output token |
| OCI Database with PostgreSQL (one copy) | Target monthly base charge | 0 | USD/month |
| OCI Database with PostgreSQL (one copy) | Target service minimum | 94.9 | USD/month |
| OCI Database with PostgreSQL (one copy) | Minimum primary CPU | 2 | vCPU |
| OCI Database with PostgreSQL (one copy) | Minimum primary RAM | 8 | GiB |
| OCI Database with PostgreSQL (one copy) | Minimum primary disk | 100 | GiB |
| OCI Database with PostgreSQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| OCI Database with PostgreSQL (one copy) | Allocated share of provisioned cost | 1 | fraction |
| OCI Database with PostgreSQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| OCI Database with PostgreSQL (one copy) | Planning peak / mean work | 2 | multiplier |
| OCI Database with PostgreSQL (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| OCI Database with PostgreSQL (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| OCI Database with PostgreSQL (one copy) | Planning disk utilization | 0.8 | fraction |
| OCI Database with PostgreSQL (one copy) | Maintenance and log disk reserve | 20 | GiB |
| OCI Database with PostgreSQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| OCI Database with PostgreSQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| OCI Database with PostgreSQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| OCI Database with PostgreSQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| OCI Database with PostgreSQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| OCI Database with PostgreSQL (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| OCI Database with PostgreSQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| OCI Database with PostgreSQL (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| OCI Database with PostgreSQL (two copies) | Origin list price · Database reads | 0 | USD/operations |
| OCI Database with PostgreSQL (two copies) | Origin list price · Database writes | 0 | USD/operations |
| OCI Database with PostgreSQL (two copies) | Target CPU / source CPU | 1 | multiplier |
| OCI Database with PostgreSQL (two copies) | Target RAM / source RAM | 1 | multiplier |
| OCI Database with PostgreSQL (two copies) | Target disk / source disk | 1 | multiplier |
| OCI Database with PostgreSQL (two copies) | Target price guess · read | 0 | USD/read |
| OCI Database with PostgreSQL (two copies) | Target price guess · write | 0 | USD/write |
| OCI Database with PostgreSQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| OCI Database with PostgreSQL (two copies) | Target list price · GiB-month | 0.072 | USD/GiB-month |
| OCI Database with PostgreSQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| OCI Database with PostgreSQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| OCI Database with PostgreSQL (two copies) | Target list price · network GiB | 0 | USD/network GiB |
| OCI Database with PostgreSQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| OCI Database with PostgreSQL (two copies) | Target list price · vCPU-hour | 0.049 | USD/vCPU-hour |
| OCI Database with PostgreSQL (two copies) | Target list price · GiB-hour | 0.002 | USD/GiB-hour |
| OCI Database with PostgreSQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| OCI Database with PostgreSQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| OCI Database with PostgreSQL (two copies) | Target price guess · input token | 0 | USD/input token |
| OCI Database with PostgreSQL (two copies) | Target price guess · output token | 0 | USD/output token |
| OCI Database with PostgreSQL (two copies) | Target monthly base charge | 0 | USD/month |
| OCI Database with PostgreSQL (two copies) | Target service minimum | 94.9 | USD/month |
| OCI Database with PostgreSQL (two copies) | Minimum primary CPU | 2 | vCPU |
| OCI Database with PostgreSQL (two copies) | Minimum primary RAM | 8 | GiB |
| OCI Database with PostgreSQL (two copies) | Minimum primary disk | 100 | GiB |
| OCI Database with PostgreSQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| OCI Database with PostgreSQL (two copies) | Allocated share of provisioned cost | 1 | fraction |
| OCI Database with PostgreSQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| OCI Database with PostgreSQL (two copies) | Planning peak / mean work | 2 | multiplier |
| OCI Database with PostgreSQL (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| OCI Database with PostgreSQL (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| OCI Database with PostgreSQL (two copies) | Planning disk utilization | 0.8 | fraction |
| OCI Database with PostgreSQL (two copies) | Maintenance and log disk reserve | 20 | GiB |
| OCI Database with PostgreSQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| OCI Database with PostgreSQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| OCI Database with PostgreSQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| OCI Database with PostgreSQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| OCI Database with PostgreSQL (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* OCI Database with PostgreSQL bills provisioned OCPUs (one x86 OCPU is two vCPUs), a memory fee and Database Optimized Storage by used GB. The storage is one pool replicated across availability domains and shared by every node, so it is billed once however many copies run. The memory rate is an assumption (see its source). The smallest shape is PostgreSQL.VM.Standard.E5.Flex with 1 OCPU and 16 GB ([https://docs.oracle.com/en-us/iaas/Content/postgresql/supported-shapes.htm](https://docs.oracle.com/en-us/iaas/Content/postgresql/supported-shapes.htm)). Backups bill as Object Storage and 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: PostgreSQL.VM.Standard.E5.Flex reaches 64 OCPUs (128 vCPUs) and 1,024 GB ([https://docs.oracle.com/en-us/iaas/Content/postgresql/supported-shapes.htm](https://docs.oracle.com/en-us/iaas/Content/postgresql/supported-shapes.htm)); a database system stores up to 32 TB ([https://docs.oracle.com/en-us/iaas/Content/postgresql/manage-databases.htm](https://docs.oracle.com/en-us/iaas/Content/postgresql/manage-databases.htm)).
* 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/)
* Oracle Cloud price list: [https://www.oracle.com/cloud/price-list/](https://www.oracle.com/cloud/price-list/)

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-9631e4e7ad853051d4ac9c6ec36873c05803b586` / `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/), [Oracle Cloud price list](https://www.oracle.com/cloud/price-list/).

**Aurora PostgreSQL → OCI Database with PostgreSQL: 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 | 71.54 |
| Target: Provisioned primary RAM | 11.68 |
| Target: Provisioned primary disk | 7.20 |
| Target: Selected billable network | 0.00 |
| Target: Independent provisioned resources | 0.00 |
| Target: Independent managed resources | 0.00 |
| Target: Approximate target service minimum adjustment | 4.48 |
| **Origin service subtotal** | **0.00** |
| **Target service subtotal** | **94.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.145 | USD/vCPU-hours |
| Origin list price · Primary memory | 0 | USD/GiB-hours |
| Origin list price · Primary provisioned storage | 0.1 | 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.072 | 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.049 | USD/vCPU-hour |
| Target list price · GiB-hour | 0.002 | 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 | 94.9 | 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.

* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.

* OCI Database with PostgreSQL bills provisioned OCPUs (one x86 OCPU is two vCPUs), a memory fee and Database Optimized Storage by used GB. The storage is one pool replicated across availability domains and shared by every node, so it is billed once however many copies run. The memory rate is an assumption (see its source). The smallest shape is PostgreSQL.VM.Standard.E5.Flex with 1 OCPU and 16 GB ([https://docs.oracle.com/en-us/iaas/Content/postgresql/supported-shapes.htm](https://docs.oracle.com/en-us/iaas/Content/postgresql/supported-shapes.htm)). Backups bill as Object Storage and 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: PostgreSQL.VM.Standard.E5.Flex reaches 64 OCPUs (128 vCPUs) and 1,024 GB ([https://docs.oracle.com/en-us/iaas/Content/postgresql/supported-shapes.htm](https://docs.oracle.com/en-us/iaas/Content/postgresql/supported-shapes.htm)); a database system stores up to 32 TB ([https://docs.oracle.com/en-us/iaas/Content/postgresql/manage-databases.htm](https://docs.oracle.com/en-us/iaas/Content/postgresql/manage-databases.htm)).

* 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-9631e4e7ad853051d4ac9c6ec36873c05803b586` / `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/), [Oracle Cloud price list](https://www.oracle.com/cloud/price-list/).

## On Private Kubernetes and Scaleway

### PostgreSQL (CloudNativePG)

| Operation | Area | Support | Depth | Notes |
| - | - | - | - | - |
| AWS/Aurora-proprietary SQL: aws\_s3.*, aws\_lambda.invoke, Aurora ML (aws\_sagemaker / aws\_comprehend), aurora\_* / apg\_plan\_mgmt | SQL functions | Out of scope | Full surface | AWS and Aurora extension functions with no counterpart on vanilla PostgreSQL; a query calling them fails |
| pgwire protocol (application SQL) | Wire protocol | Supported | Common | wire-compatible PostgreSQL; application SQL is unchanged |

#### How it works

Your application's PostgreSQL driver connects directly to CloudNativePG. These database requests are the **data plane**. The driver and the PostgreSQL wire protocol stay the same, and Tensor9 adds no proxy, translation or latency to your queries.

Management requests, such as snapshots, restores, replicas, failover and configuration changes, are the **control plane**. Tensor9 runs the RDS API in the customer's Cloud Adapter deployment and translates each of these requests to the backend's management API. The sections below list which operations work and which return an error.

![Database requests (SQL over pgwire) connect directly to CloudNativePG. The Tensor9 service adapter translates RDS API management calls to CloudNativePG resources.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgcGd3aXJlKSBjb25uZWN0IGRpcmVjdGx5IHRvIENsb3VkTmF0aXZlUEcuIFRoZSBUZW5zb3I5IHNlcnZpY2UgYWRhcHRlciB0cmFuc2xhdGVzIFJEUyBBUEkgbWFuYWdlbWVudCBjYWxscyB0byBDbG91ZE5hdGl2ZVBHIHJlc291cmNlcy4iPjxzdHlsZT50ZXh0e2ZvbnQtZmFtaWx5OkludGVyLC1hcHBsZS1zeXN0ZW0sQmxpbmtNYWNTeXN0ZW1Gb250LCdTZWdvZSBVSScsUm9ib3RvLCdIZWx2ZXRpY2EgTmV1ZScsQXJpYWwsc2Fucy1zZXJpZjtmaWxsOiMzMzQxNTV9PC9zdHlsZT4KPGRlZnM+PG1hcmtlciBpZD0iYWhkLWNsb3VkbmF0aXZlcGciIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjciIG1hcmtlckhlaWdodD0iNyIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6Izk0YTNiOCIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iOCIgeT0iMzQiIHdpZHRoPSI4MjAiIGhlaWdodD0iMjA2IiByeD0iMTYiIHN0cm9rZS13aWR0aD0iMS40IiBzdHJva2UtZGFzaGFycmF5PSI1IDUiIHN0eWxlPSJmaWxsOiNmOGZhZmM7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iMjYiIHk9IjU0IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzk0YTNiODsgZmlsbDojMDQ3ODU3Ij5JTiBUSEUgVEFSR0VUIENMVVNURVI8L3RleHQ+PHN2ZyB4PSI3OTIiIHk9IjM2IiB3aWR0aD0iMTYiIGhlaWdodD0iMTYiIHZpZXdCb3g9IjAgMCAxNiAxNiIgcHJlc2VydmVBc3BlY3RSYXRpbz0ieE1pZFlNaWQgbWVldCIgZmlsbD0ibm9uZSI+PHBhdGggZmlsbD0iIzMyNkRFNiIgZD0iTTQuNSAxNC41NjljLjIxNC4yNzguNTM5LjQzMS44NzQuNDMxaDUuMjUxYy4zMzUgMCAuNjYtLjE2NS44NzUtLjQzNGwzLjI1OC00LjE3OGMuMjE0LS4yNzguMjg4LS42MzMuMjE0LS45NzhsLTEuMTY1LTUuMjA3YTEuMTI4IDEuMTI4IDAgMDAtLjYwNi0uNzc3bC00LjcxNC0yLjMxQTEuMDYyIDEuMDYyIDAgMDA4LjAwMiAxYy0uMTY4IDAtLjMzNS4wMzgtLjQ4NS4xMTVsLTQuNzE1IDIuMzJhMS4xMjkgMS4xMjkgMCAwMC0uNjA1Ljc3N0wxLjAzMiA5LjQyYy0uMDg0LjM0NSAwIC43LjIxNC45NzhMNC41IDE0LjU2OHoiLz48cGF0aCBmaWxsPSIjZmZmZmZmIiBmaWxsLXJ1bGU9ImV2ZW5vZGQiIGQ9Ik0xMi43NDEgOS4xMjhjLjA5OC4wMDIuMTk2LjAxLjI5My4wMjRsLjA1OC4wMTMuMDMxLjAwOGEuMzA4LjMwOCAwIDAxLjI2LjM3MS4zMDYuMzA2IDAgMDEtLjM5Ni4yMjNoLS4wMDRsLS4wMDMtLjAwMS0uMDAzLS4wMDJhMS41OCAxLjU4IDAgMDAtLjAzLS4wMDZsLS4wNS0uMDFhMi41NSAyLjU1IDAgMDEtLjI3NC0uMTA2IDIuODY3IDIuODY3IDAgMDAtLjUzMy0uMTU3LjI0Mi4yNDIgMCAwMC0uMTcxLjA2NCA0LjY1NiA0LjY1NiAwIDAwLS4xMzEtLjAyMyAzLjk3MSAzLjk3MSAwIDAxLTEuNzY0IDIuMjEyYy4wMTUuMDQyLjAzMi4wODMuMDUxLjEyM2EuMjM5LjIzOSAwIDAwLS4wMjMuMThjLjA3NC4xNy4xNjUuMzMyLjI3MS40ODQuMDYuMDc4LjExNC4xNi4xNjQuMjQ0bC4wMjguMDU3LjAxMi4wMjVhLjMwNi4zMDYgMCAwMS0uMzgxLjQ0LjMwOC4zMDggMCAwMS0uMTcyLS4xOGwtLjAxLS4wMmExLjU3IDEuNTcgMCAwMS0uMDI4LS4wNTggMi41NDYgMi41NDYgMCAwMS0uMDg5LS4yOCAyLjgzNyAyLjgzNyAwIDAwLS4yMS0uNTEyLjI0Mi4yNDIgMCAwMC0uMTU2LS4wOTVsLS4wMy0uMDUzLS4wMzUtLjA2NGEzLjk3IDMuOTcgMCAwMS0yLjgyMy0uMDA3bC0uMDcuMTI1YS4yNS4yNSAwIDAwLS4xMzIuMDY0IDIuMTMgMi4xMyAwIDAwLS4yMzcuNTQ4IDIuNTE4IDIuNTE4IDAgMDEtLjA4OC4yOCAxLjE5NiAxLjE5NiAwIDAxLS4wMjUuMDVsLS4wMTMuMDI3di4wMDFhLjMwNi4zMDYgMCAwMS0uNDIxLjE3My4zMDguMzA4IDAgMDEtLjE3My0uMzE0LjMwNi4zMDYgMCAwMS4wNDEtLjEybC4wMTQtLjAzLjAyNi0uMDUyYy4wNS0uMDg1LjEwNC0uMTY2LjE2NC0uMjQ0LjEwOC0uMTU2LjItLjMyMi4yNzctLjQ5NmEuMzAyLjMwMiAwIDAwLS4wMjgtLjE3M2wuMDU2LS4xMzNBMy45NzIgMy45NzIgMCAwMTQuMjIgOS41MzJsLS4xMzQuMDIzYS4zNC4zNCAwIDAwLS4xNzYtLjA2MiAyLjg3MSAyLjg3MSAwIDAwLS41MzMuMTU2Yy0uMDkuMDQtLjE4MS4wNzUtLjI3NC4xMDVhMS4wMTcgMS4wMTcgMCAwMS0uMDUuMDExbC0uMDMuMDA3SDMuMDJsLS4wMDIuMDAyaC0uMDA1YS4zMDguMzA4IDAgMDEtLjM5Ny0uMzQ5LjMwNi4zMDYgMCAwMS4yNjEtLjI0NWwuMDA1LS4wMDFoLjAwMmwuMDA2LS4wMDJjLjAyNC0uMDA2LjA1NC0uMDE0LjA3Ni0uMDE4LjA5Ny0uMDEzLjE5NS0uMDIxLjI5My0uMDIzLjE4Ni0uMDEzLjM3LS4wNDMuNTQ5LS4wOWEuNDIyLjQyMiAwIDAwLjEzMS0uMTMzbC4xMjgtLjAzN2EzLjkzOCAzLjkzOCAwIDAxLjYyNS0yLjc1MmwtLjA5OC0uMDg3YS4zMzguMzM4IDAgMDAtLjA2Mi0uMTc2IDIuODU0IDIuODU0IDAgMDAtLjQ1NS0uMzE5IDIuNTU3IDIuNTU3IDAgMDEtLjI1NC0uMTQ4bC0uMDQ4LS4wMzgtLjAxNS0uMDEzLS4wMDQtLjAwM2EuMzIzLjMyMyAwIDAxLS4wNzYtLjQ1LjI5NS4yOTUgMCAwMS4yNDQtLjEwNy4zNjUuMzY1IDAgMDEuMjEzLjA4bC4wMjIuMDE3Yy4wMTYuMDEzLjAzNC4wMjYuMDQ2LjAzNy4wNzIuMDY3LjEzOS4xMzkuMjAyLjIxMy4xMjUuMTM3LjI2My4yNjIuNDEyLjM3Mi4wNTYuMDMuMTIxLjAzNi4xODIuMDE4bC4xMS4wNzhhMy45MzggMy45MzggMCAwMTIuNTUyLTEuMjI0bC4wMDgtLjEyOWEuMzMyLjMzMiAwIDAwLjA5OS0uMTU4IDIuODQ0IDIuODQ0IDAgMDAtLjAzNC0uNTUzIDIuNTYgMi41NiAwIDAxLS4wNDItLjI5di0uMDgyLS4wMDVBLjMwNi4zMDYgMCAwMTggMi44MmEuMzA4LjMwOCAwIDAxLjMwNi4zMzd2LjA4N2EyLjUyOSAyLjUyOSAwIDAxLS4wNDEuMjkgMi44NSAyLjg1IDAgMDAtLjAzNS41NTMuMjQyLjI0MiAwIDAwLjEuMTUzdi4wMDdsLjAwNy4xMjljLjk2Ny4wODggMS44Ny41MjIgMi41NCAxLjIyM2wuMTE2LS4wODJhLjM0LjM0IDAgMDAuMTg2LS4wMmMuMTQ5LS4xMS4yODctLjIzNi40MTItLjM3My4wNjMtLjA3NS4xMy0uMTQ2LjIwMi0uMjEzbC4wNTEtLjA0LjAxNy0uMDE0YS4zMDcuMzA3IDAgMTEuMzgxLjQ3N2wtLjAyNC4wMmMtLjAxNS4wMTItLjAzLjAyNS0uMDQzLjAzNGEyLjUzNyAyLjUzNyAwIDAxLS4yNTQuMTQ4IDIuODcgMi44NyAwIDAwLS40NTUuMzIuMjQxLjI0MSAwIDAwLS4wNTguMTcybC0uMDUuMDQ0LS4wNTguMDUzYy41NDIuODA2Ljc3IDEuNzgzLjYzNyAyLjc0NWwuMTIzLjAzNmMuMDMxLjA1NS4wNzcuMTAxLjEzMy4xMzIuMTc5LjA0OC4zNjMuMDc4LjU0OC4wOXpNNy4yOTEgNS4yNGMuMTA3LS4wMjQuMjE2LS4wNDMuMzI2LS4wNTZsLS4wOSAxLjYtLjAwOC4wMDRhLjI2OC4yNjggMCAwMS0uMjkzLjI1Ni4yNy4yNyAwIDAxLS4xMzUtLjA1bC0uMDAyLjAwMS0xLjMxNi0uOTNjLjQxOS0uNDEuOTQ1LS42OTYgMS41MTgtLjgyNXptMS42MTggMS43NWwxLjMwOC0uOTI0YTMuMTgyIDMuMTgyIDAgMDAtMS44MzMtLjg4MmwuMDkgMS41OThoLjAwMmEuMjY4LjI2OCAwIDAwLjI5NC4yNTYuMjcuMjcgMCAwMC4xMzUtLjA1bC4wMDQuMDAyem0yLjI0OCAxLjY1Nkw5LjYwOSA4LjJsLS4wMDItLjAwNmEuMjcuMjcgMCAwMS0uMTg1LS4zNDMuMjcuMjcgMCAwMS4wOC0uMTJMOS41IDcuNzNsMS4xOTUtMS4wNjdjLjM2Ni41OTQuNTI3IDEuMjkuNDYgMS45ODN6TTkuMDk2IDkuNWwuNjE4IDEuNDlhMy4xNDggMy4xNDggMCAwMDEuMjc1LTEuNTk4bC0xLjU5My0uMjY5LS4wMDIuMDAzYS4yNi4yNiAwIDAwLS4xNjYuMDIzLjI3LjI3IDAgMDAtLjEzLjM0OGwtLjAwMi4wMDN6bS0uMzg1IDEuOTA1Yy0uNTczLjEzLTEuMTcuMS0xLjcyNy0uMDg4bC43NzctMS40aC4wMDFhLjI3LjI3IDAgMDEuNDc1LS4wMDFoLjAwNmwuNzc5IDEuNDAyYTMuMjg2IDMuMjg2IDAgMDEtLjMxMS4wODd6bS0yLjQxOC0uNDIybC42MTEtMS40NzQtLjAwNC0uMDA2YS4yNjguMjY4IDAgMDAtLjI5Ny0uMzdMNi42IDkuMTNsLTEuNTc5LjI2N2EzLjE2IDMuMTYgMCAwMDEuMjcyIDEuNTg2em0tLjk5Ny00LjMybDEuMjAxIDEuMDcxLS4wMDEuMDA3YS4yNjkuMjY5IDAgMDEtLjEwNi40NjJsLS4wMDEuMDA1LTEuNTQuNDQzYTMuMTM0IDMuMTM0IDAgMDEuNDQ3LTEuOTg4em0yLjk1IDEuMTU0aC0uNDkybC0uMzA3LjM4LjExLjQ3Ni40NDMuMjEzLjQ0Mi0uMjEyLjExLS40NzYtLjMwNi0uMzgxeiIgY2xpcC1ydWxlPSJldmVub2RkIi8+PC9zdmc+CjxyZWN0IHg9IjI2IiB5PSI4OCIgd2lkdGg9IjEyOCIgaGVpZ2h0PSIxMTIiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iOTAiIHk9IjEyNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxM3B4Ij5Zb3VyIGFwcDwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjE0NSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPlBvc3RncmVTUUwgZHJpdmVyPC90ZXh0Pgo8dGV4dCB4PSI5MCIgeT0iMTYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPnVuY2hhbmdlZDwvdGV4dD4KPHRleHQgeD0iMjAwIiB5PSI4MiIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjg7IGZpbGw6IzA0Nzg1NyI+REFUQUJBU0UgUkVRVUVTVFMgwrcgRElSRUNUIENPTk5FQ1RJT048L3RleHQ+CjxsaW5lIHgxPSIxNTQiIHkxPSIxMDgiIHgyPSI2MTAiIHkyPSIxMDgiIHN0cm9rZS13aWR0aD0iMi4yIiBtYXJrZXItZW5kPSJ1cmwoI2FoZC1jbG91ZG5hdGl2ZXBnKSIgc3R5bGU9InN0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjM4MiIgeT0iMTAwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YjsgZmlsbDojMDQ3ODU3Ij5TUUwgb3ZlciBwZ3dpcmU8L3RleHQ+CjxyZWN0IHg9IjYxNCIgeT0iNzYiIHdpZHRoPSIxOTYiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz48c3ZnIHg9Ijc4NiIgeT0iNTYiIHdpZHRoPSIyMCIgaGVpZ2h0PSIyMCIgdmlld0JveD0iMCAwIDQzMi4wNzEgNDQ1LjM4MyIgcHJlc2VydmVBc3BlY3RSYXRpbz0ieE1pZFlNaWQgbWVldCI+PGcgc3R5bGU9ImZpbGwtcnVsZTpub256ZXJvO2NsaXAtcnVsZTpub256ZXJvO3N0cm9rZTojMDAwMDAwO3N0cm9rZS1taXRlcmxpbWl0OjQiPiA8L2c+IDxnIHN0eWxlPSJmaWxsLXJ1bGU6bm9uemVybztjbGlwLXJ1bGU6bm9uemVybztmaWxsOm5vbmU7c3Ryb2tlOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjEyLjQ2NTE7c3Ryb2tlLWxpbmVjYXA6cm91bmQ7c3Ryb2tlLWxpbmVqb2luOnJvdW5kO3N0cm9rZS1taXRlcmxpbWl0OjQiPiA8cGF0aCBkPSJNMzIzLjIwNSwzMjQuMjI3YzIuODMzLTIzLjYwMSwxLjk4NC0yNy4wNjIsMTkuNTYzLTIzLjIzOWw0LjQ2MywwLjM5MmMxMy41MTcsMC42MTUsMzEuMTk5LTIuMTc0LDQxLjU4Ny03YzIyLjM2Mi0xMC4zNzYsMzUuNjIyLTI3LjcsMTMuNTcyLTIzLjE0OGMtNTAuMjk3LDEwLjM3Ni01My43NTUtNi42NTUtNTMuNzU1LTYuNjU1YzUzLjExMS03OC44MDMsNzUuMzEzLTE3OC44MzYsNTYuMTQ5LTIwMy4zMjIgQzM1Mi41MTQtNS41MzQsMjYyLjAzNiwyNi4wNDksMjYwLjUyMiwyNi44NjlsLTAuNDgyLDAuMDg5Yy05LjkzOC0yLjA2Mi0yMS4wNi0zLjI5NC0zMy41NTQtMy40OTZjLTIyLjc2MS0wLjM3NC00MC4wMzIsNS45NjctNTMuMTMzLDE1LjkwNGMwLDAtMTYxLjQwOC02Ni40OTgtMTUzLjg5OSw4My42MjhjMS41OTcsMzEuOTM2LDQ1Ljc3NywyNDEuNjU1LDk4LjQ3LDE3OC4zMSBjMTkuMjU5LTIzLjE2MywzNy44NzEtNDIuNzQ4LDM3Ljg3MS00Mi43NDhjOS4yNDIsNi4xNCwyMC4zMDcsOS4yNzIsMzEuOTEyLDguMTQ3bDAuODk3LTAuNzY1Yy0wLjI4MSwyLjg3Ni0wLjE1Nyw1LjY4OSwwLjM1OSw5LjAxOWMtMTMuNTcyLDE1LjE2Ny05LjU4NCwxNy44My0zNi43MjMsMjMuNDE2Yy0yNy40NTcsNS42NTktMTEuMzI2LDE1LjczNC0wLjc5NywxOC4zNjdjMTIuNzY4LDMuMTkzLDQyLjMwNSw3LjcxNiw2Mi4yNjgtMjAuMjI0IGwtMC43OTUsMy4xODhjNS4zMjUsNC4yNiw0Ljk2NSwzMC42MTksNS43Miw0OS40NTJjMC43NTYsMTguODM0LDIuMDE3LDM2LjQwOSw1Ljg1Niw0Ni43NzFjMy44MzksMTAuMzYsOC4zNjksMzcuMDUsNDQuMDM2LDI5LjQwNmMyOS44MDktNi4zODgsNTIuNi0xNS41ODIsNTQuNjc3LTEwMS4xMDciIHN0eWxlPSJmaWxsOiMwMDAwMDA7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjM3LjM5NTM7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTQwMi4zOTUsMjcxLjIzYy01MC4zMDIsMTAuMzc2LTUzLjc2LTYuNjU1LTUzLjc2LTYuNjU1YzUzLjExMS03OC44MDgsNzUuMzEzLTE3OC44NDMsNTYuMTUzLTIwMy4zMjZjLTUyLjI3LTY2Ljc4NS0xNDIuNzUyLTM1LjItMTQ0LjI2Mi0zNC4zOGwtMC40ODYsMC4wODdjLTkuOTM4LTIuMDYzLTIxLjA2LTMuMjkyLTMzLjU2LTMuNDk2Yy0yMi43NjEtMC4zNzMtNDAuMDI2LDUuOTY3LTUzLjEyNywxNS45MDIgYzAsMC0xNjEuNDExLTY2LjQ5NS0xNTMuOTA0LDgzLjYzYzEuNTk3LDMxLjkzOCw0NS43NzYsMjQxLjY1Nyw5OC40NzEsMTc4LjMxMmMxOS4yNi0yMy4xNjMsMzcuODY5LTQyLjc0OCwzNy44NjktNDIuNzQ4YzkuMjQzLDYuMTQsMjAuMzA4LDkuMjcyLDMxLjkwOCw4LjE0N2wwLjkwMS0wLjc2NWMtMC4yOCwyLjg3Ni0wLjE1Miw1LjY4OSwwLjM2MSw5LjAxOWMtMTMuNTc1LDE1LjE2Ny05LjU4NiwxNy44My0zNi43MjMsMjMuNDE2IGMtMjcuNDU5LDUuNjU5LTExLjMyOCwxNS43MzQtMC43OTYsMTguMzY3YzEyLjc2OCwzLjE5Myw0Mi4zMDcsNy43MTYsNjIuMjY2LTIwLjIyNGwtMC43OTYsMy4xODhjNS4zMTksNC4yNiw5LjA1NCwyNy43MTEsOC40MjgsNDguOTY5Yy0wLjYyNiwyMS4yNTktMS4wNDQsMzUuODU0LDMuMTQ3LDQ3LjI1NGM0LjE5MSwxMS40LDguMzY4LDM3LjA1LDQ0LjA0MiwyOS40MDZjMjkuODA5LTYuMzg4LDQ1LjI1Ni0yMi45NDIsNDcuNDA1LTUwLjU1NSBjMS41MjUtMTkuNjMxLDQuOTc2LTE2LjcyOSw1LjE5NC0zNC4yOGwyLjc2OC04LjMwOWMzLjE5Mi0yNi42MTEsMC41MDctMzUuMTk2LDE4Ljg3Mi0zMS4yMDNsNC40NjMsMC4zOTJjMTMuNTE3LDAuNjE1LDMxLjIwOC0yLjE3NCw0MS41OTEtN2MyMi4zNTgtMTAuMzc2LDM1LjYxOC0yNy43LDEzLjU3My0yMy4xNDh6IiBzdHlsZT0iZmlsbDojMzM2NzkxO3N0cm9rZTpub25lIi8+IDxwYXRoIGQ9Ik0yMTUuODY2LDI4Ni40ODRjLTEuMzg1LDQ5LjUxNiwwLjM0OCw5OS4zNzcsNS4xOTMsMTExLjQ5NWM0Ljg0OCwxMi4xMTgsMTUuMjIzLDM1LjY4OCw1MC45LDI4LjA0NWMyOS44MDYtNi4zOSw0MC42NTEtMTguNzU2LDQ1LjM1Ny00Ni4wNTFjMy40NjYtMjAuMDgyLDEwLjE0OC03NS44NTQsMTEuMDA1LTg3LjI4MSIvPiA8cGF0aCBkPSJNMTczLjEwNCwzOC4yNTZjMCwwLTE2MS41MjEtNjYuMDE2LTE1NC4wMTIsODQuMTA5YzEuNTk3LDMxLjkzOCw0NS43NzksMjQxLjY2NCw5OC40NzMsMTc4LjMxNmMxOS4yNTYtMjMuMTY2LDM2LjY3MS00MS4zMzUsMzYuNjcxLTQxLjMzNSIvPiA8cGF0aCBkPSJNMjYwLjM0OSwyNi4yMDdjLTUuNTkxLDEuNzUzLDg5Ljg0OC0zNC44ODksMTQ0LjA4NywzNC40MTdjMTkuMTU5LDI0LjQ4NC0zLjA0MywxMjQuNTE5LTU2LjE1MywyMDMuMzI5Ii8+IDxwYXRoIGQ9Ik0zNDguMjgyLDI2My45NTNjMCwwLDMuNDYxLDE3LjAzNiw1My43NjQsNi42NTNjMjIuMDQtNC41NTIsOC43NzYsMTIuNzc0LTEzLjU3NywyMy4xNTVjLTE4LjM0NSw4LjUxNC01OS40NzQsMTAuNjk2LTYwLjE0Ni0xLjA2OWMtMS43MjktMzAuMzU1LDIxLjY0Ny0yMS4xMzMsMTkuOTYtMjguNzM5Yy0xLjUyNS02Ljg1LTExLjk3OS0xMy41NzMtMTguODk0LTMwLjMzOCBjLTYuMDM3LTE0LjYzMy04Mi43OTYtMTI2Ljg0OSwyMS4yODctMTEwLjE4M2MzLjgxMy0wLjc4OS0yNy4xNDYtOTkuMDAyLTEyNC41NTMtMTAwLjU5OWMtOTcuMzg1LTEuNTk3LTk0LjE5LDExOS43NjItOTQuMTksMTE5Ljc2MiIgc3R5bGU9InN0cm9rZS1saW5lam9pbjpiZXZlbCIvPiA8cGF0aCBkPSJNMTg4LjYwNCwyNzQuMzM0Yy0xMy41NzcsMTUuMTY2LTkuNTg0LDE3LjgyOS0zNi43MjMsMjMuNDE3Yy0yNy40NTksNS42Ni0xMS4zMjYsMTUuNzMzLTAuNzk3LDE4LjM2NWMxMi43NjgsMy4xOTUsNDIuMzA3LDcuNzE4LDYyLjI2Ni0yMC4yMjljNi4wNzgtOC41MDktMC4wMzYtMjIuMDg2LTguMzg1LTI1LjU0N2MtNC4wMzQtMS42NzEtOS40MjgtMy43NjUtMTYuMzYxLDMuOTk0eiIvPiA8cGF0aCBkPSJNMTg3LjcxNSwyNzQuMDY5Yy0xLjM2OC04LjkxNywyLjkzLTE5LjUyOCw3LjUzNi0zMS45NDJjNi45MjItMTguNjI2LDIyLjg5My0zNy4yNTUsMTAuMTE3LTk2LjMzOWMtOS41MjMtNDQuMDI5LTczLjM5Ni05LjE2My03My40MzYtMy4xOTNjLTAuMDM5LDUuOTY4LDIuODg5LDMwLjI2LTEuMDY3LDU4LjU0OGMtNS4xNjIsMzYuOTEzLDIzLjQ4OCw2OC4xMzIsNTYuNDc5LDY0LjkzOCIvPiA8cGF0aCBkPSJNMTcyLjUxNywxNDEuN2MtMC4yODgsMi4wMzksMy43MzMsNy40OCw4Ljk3Niw4LjIwN2M1LjIzNCwwLjczLDkuNzE0LTMuNTIyLDkuOTk4LTUuNTU5YzAuMjg0LTIuMDM5LTMuNzMyLTQuMjg1LTguOTc3LTUuMDE1Yy01LjIzNy0wLjczMS05LjcxOSwwLjMzMy05Ljk5NiwyLjM2N3oiIHN0eWxlPSJmaWxsOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjQuMTU1O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyIi8+IDxwYXRoIGQ9Ik0zMzEuOTQxLDEzNy41NDNjMC4yODQsMi4wMzktMy43MzIsNy40OC04Ljk3Niw4LjIwN2MtNS4yMzgsMC43My05LjcxOC0zLjUyMi0xMC4wMDUtNS41NTljLTAuMjc3LTIuMDM5LDMuNzQtNC4yODUsOC45NzktNS4wMTVjNS4yMzktMC43Myw5LjcxOCwwLjMzMywxMC4wMDIsMi4zNjh6IiBzdHlsZT0iZmlsbDojRkZGRkZGO3N0cm9rZS13aWR0aDoyLjA3NzU7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTM1MC42NzYsMTIzLjQzMmMwLjg2MywxNS45OTQtMy40NDUsMjYuODg4LTMuOTg4LDQzLjkxNGMtMC44MDQsMjQuNzQ4LDExLjc5OSw1My4wNzQtNy4xOTEsODEuNDM1Ii8+IDxwYXRoIGQ9Ik0wLDYwLjIzMiIgc3R5bGU9InN0cm9rZS13aWR0aDozIi8+IDwvZz48L3N2Zz4KPHRleHQgeD0iNzEyIiB5PSIxMDMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTJweCI+Q2xvdWROYXRpdmVQRzwvdGV4dD4KPHRleHQgeD0iNzEyIiB5PSIxMjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5Qb3N0Z3JlU1FMIG9uIEt1YmVybmV0ZXM8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iMTU4IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzk0YTNiOCI+TUFOQUdFTUVOVCBSRVFVRVNUUyDCtyBWSUEgVEVOU09SOTwvdGV4dD4KPGxpbmUgeDE9IjE1NCIgeTE9IjE5NiIgeDI9IjMwMCIgeTI9IjE5NiIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoZC1jbG91ZG5hdGl2ZXBnKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjIyNyIgeT0iMTg4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YiI+UkRTIEFQSTwvdGV4dD4KPHJlY3QgeD0iMzA0IiB5PSIxNjQiIHdpZHRoPSIxODAiIGhlaWdodD0iNjYiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iMzk0IiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSIzOTQiIHk9IjIwOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+c2VydmljZSBhZGFwdGVyPC90ZXh0Pgo8bGluZSB4MT0iNDg0IiB5MT0iMTk2IiB4Mj0iNjEwIiB5Mj0iMTk2IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLWNsb3VkbmF0aXZlcGcpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHJlY3QgeD0iNjE0IiB5PSIxNjQiIHdpZHRoPSIxOTYiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iNzEyIiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTEuNXB4Ij5DbG91ZE5hdGl2ZVBHIHJlc291cmNlczwvdGV4dD4KPHRleHQgeD0iNzEyIiB5PSIyMTAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj50aGUgYmFja2VuZCdzIG1hbmFnZW1lbnQgQVBJPC90ZXh0Pgo8L3N2Zz4=)

![Database requests (SQL over pgwire) connect directly to CloudNativePG. The Tensor9 service adapter translates RDS API management calls to CloudNativePG resources.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgcGd3aXJlKSBjb25uZWN0IGRpcmVjdGx5IHRvIENsb3VkTmF0aXZlUEcuIFRoZSBUZW5zb3I5IHNlcnZpY2UgYWRhcHRlciB0cmFuc2xhdGVzIFJEUyBBUEkgbWFuYWdlbWVudCBjYWxscyB0byBDbG91ZE5hdGl2ZVBHIHJlc291cmNlcy4iPjxzdHlsZT50ZXh0e2ZvbnQtZmFtaWx5OkludGVyLC1hcHBsZS1zeXN0ZW0sQmxpbmtNYWNTeXN0ZW1Gb250LCdTZWdvZSBVSScsUm9ib3RvLCdIZWx2ZXRpY2EgTmV1ZScsQXJpYWwsc2Fucy1zZXJpZjtmaWxsOiNjYmQ1ZTF9PC9zdHlsZT4KPGRlZnM+PG1hcmtlciBpZD0iYWhkLWNsb3VkbmF0aXZlcGciIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjciIG1hcmtlckhlaWdodD0iNyIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6IzY0NzQ4YiIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iOCIgeT0iMzQiIHdpZHRoPSI4MjAiIGhlaWdodD0iMjA2IiByeD0iMTYiIHN0cm9rZS13aWR0aD0iMS40IiBzdHJva2UtZGFzaGFycmF5PSI1IDUiIHN0eWxlPSJmaWxsOiMwZjE3MmE7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iMjYiIHk9IjU0IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzY0NzQ4YjsgZmlsbDojNmVlN2I3Ij5JTiBUSEUgVEFSR0VUIENMVVNURVI8L3RleHQ+PHN2ZyB4PSI3OTIiIHk9IjM2IiB3aWR0aD0iMTYiIGhlaWdodD0iMTYiIHZpZXdCb3g9IjAgMCAxNiAxNiIgcHJlc2VydmVBc3BlY3RSYXRpbz0ieE1pZFlNaWQgbWVldCIgZmlsbD0ibm9uZSI+PHBhdGggZmlsbD0iIzMyNkRFNiIgZD0iTTQuNSAxNC41NjljLjIxNC4yNzguNTM5LjQzMS44NzQuNDMxaDUuMjUxYy4zMzUgMCAuNjYtLjE2NS44NzUtLjQzNGwzLjI1OC00LjE3OGMuMjE0LS4yNzguMjg4LS42MzMuMjE0LS45NzhsLTEuMTY1LTUuMjA3YTEuMTI4IDEuMTI4IDAgMDAtLjYwNi0uNzc3bC00LjcxNC0yLjMxQTEuMDYyIDEuMDYyIDAgMDA4LjAwMiAxYy0uMTY4IDAtLjMzNS4wMzgtLjQ4NS4xMTVsLTQuNzE1IDIuMzJhMS4xMjkgMS4xMjkgMCAwMC0uNjA1Ljc3N0wxLjAzMiA5LjQyYy0uMDg0LjM0NSAwIC43LjIxNC45NzhMNC41IDE0LjU2OHoiLz48cGF0aCBmaWxsPSIjZmZmZmZmIiBmaWxsLXJ1bGU9ImV2ZW5vZGQiIGQ9Ik0xMi43NDEgOS4xMjhjLjA5OC4wMDIuMTk2LjAxLjI5My4wMjRsLjA1OC4wMTMuMDMxLjAwOGEuMzA4LjMwOCAwIDAxLjI2LjM3MS4zMDYuMzA2IDAgMDEtLjM5Ni4yMjNoLS4wMDRsLS4wMDMtLjAwMS0uMDAzLS4wMDJhMS41OCAxLjU4IDAgMDAtLjAzLS4wMDZsLS4wNS0uMDFhMi41NSAyLjU1IDAgMDEtLjI3NC0uMTA2IDIuODY3IDIuODY3IDAgMDAtLjUzMy0uMTU3LjI0Mi4yNDIgMCAwMC0uMTcxLjA2NCA0LjY1NiA0LjY1NiAwIDAwLS4xMzEtLjAyMyAzLjk3MSAzLjk3MSAwIDAxLTEuNzY0IDIuMjEyYy4wMTUuMDQyLjAzMi4wODMuMDUxLjEyM2EuMjM5LjIzOSAwIDAwLS4wMjMuMThjLjA3NC4xNy4xNjUuMzMyLjI3MS40ODQuMDYuMDc4LjExNC4xNi4xNjQuMjQ0bC4wMjguMDU3LjAxMi4wMjVhLjMwNi4zMDYgMCAwMS0uMzgxLjQ0LjMwOC4zMDggMCAwMS0uMTcyLS4xOGwtLjAxLS4wMmExLjU3IDEuNTcgMCAwMS0uMDI4LS4wNTggMi41NDYgMi41NDYgMCAwMS0uMDg5LS4yOCAyLjgzNyAyLjgzNyAwIDAwLS4yMS0uNTEyLjI0Mi4yNDIgMCAwMC0uMTU2LS4wOTVsLS4wMy0uMDUzLS4wMzUtLjA2NGEzLjk3IDMuOTcgMCAwMS0yLjgyMy0uMDA3bC0uMDcuMTI1YS4yNS4yNSAwIDAwLS4xMzIuMDY0IDIuMTMgMi4xMyAwIDAwLS4yMzcuNTQ4IDIuNTE4IDIuNTE4IDAgMDEtLjA4OC4yOCAxLjE5NiAxLjE5NiAwIDAxLS4wMjUuMDVsLS4wMTMuMDI3di4wMDFhLjMwNi4zMDYgMCAwMS0uNDIxLjE3My4zMDguMzA4IDAgMDEtLjE3My0uMzE0LjMwNi4zMDYgMCAwMS4wNDEtLjEybC4wMTQtLjAzLjAyNi0uMDUyYy4wNS0uMDg1LjEwNC0uMTY2LjE2NC0uMjQ0LjEwOC0uMTU2LjItLjMyMi4yNzctLjQ5NmEuMzAyLjMwMiAwIDAwLS4wMjgtLjE3M2wuMDU2LS4xMzNBMy45NzIgMy45NzIgMCAwMTQuMjIgOS41MzJsLS4xMzQuMDIzYS4zNC4zNCAwIDAwLS4xNzYtLjA2MiAyLjg3MSAyLjg3MSAwIDAwLS41MzMuMTU2Yy0uMDkuMDQtLjE4MS4wNzUtLjI3NC4xMDVhMS4wMTcgMS4wMTcgMCAwMS0uMDUuMDExbC0uMDMuMDA3SDMuMDJsLS4wMDIuMDAyaC0uMDA1YS4zMDguMzA4IDAgMDEtLjM5Ny0uMzQ5LjMwNi4zMDYgMCAwMS4yNjEtLjI0NWwuMDA1LS4wMDFoLjAwMmwuMDA2LS4wMDJjLjAyNC0uMDA2LjA1NC0uMDE0LjA3Ni0uMDE4LjA5Ny0uMDEzLjE5NS0uMDIxLjI5My0uMDIzLjE4Ni0uMDEzLjM3LS4wNDMuNTQ5LS4wOWEuNDIyLjQyMiAwIDAwLjEzMS0uMTMzbC4xMjgtLjAzN2EzLjkzOCAzLjkzOCAwIDAxLjYyNS0yLjc1MmwtLjA5OC0uMDg3YS4zMzguMzM4IDAgMDAtLjA2Mi0uMTc2IDIuODU0IDIuODU0IDAgMDAtLjQ1NS0uMzE5IDIuNTU3IDIuNTU3IDAgMDEtLjI1NC0uMTQ4bC0uMDQ4LS4wMzgtLjAxNS0uMDEzLS4wMDQtLjAwM2EuMzIzLjMyMyAwIDAxLS4wNzYtLjQ1LjI5NS4yOTUgMCAwMS4yNDQtLjEwNy4zNjUuMzY1IDAgMDEuMjEzLjA4bC4wMjIuMDE3Yy4wMTYuMDEzLjAzNC4wMjYuMDQ2LjAzNy4wNzIuMDY3LjEzOS4xMzkuMjAyLjIxMy4xMjUuMTM3LjI2My4yNjIuNDEyLjM3Mi4wNTYuMDMuMTIxLjAzNi4xODIuMDE4bC4xMS4wNzhhMy45MzggMy45MzggMCAwMTIuNTUyLTEuMjI0bC4wMDgtLjEyOWEuMzMyLjMzMiAwIDAwLjA5OS0uMTU4IDIuODQ0IDIuODQ0IDAgMDAtLjAzNC0uNTUzIDIuNTYgMi41NiAwIDAxLS4wNDItLjI5di0uMDgyLS4wMDVBLjMwNi4zMDYgMCAwMTggMi44MmEuMzA4LjMwOCAwIDAxLjMwNi4zMzd2LjA4N2EyLjUyOSAyLjUyOSAwIDAxLS4wNDEuMjkgMi44NSAyLjg1IDAgMDAtLjAzNS41NTMuMjQyLjI0MiAwIDAwLjEuMTUzdi4wMDdsLjAwNy4xMjljLjk2Ny4wODggMS44Ny41MjIgMi41NCAxLjIyM2wuMTE2LS4wODJhLjM0LjM0IDAgMDAuMTg2LS4wMmMuMTQ5LS4xMS4yODctLjIzNi40MTItLjM3My4wNjMtLjA3NS4xMy0uMTQ2LjIwMi0uMjEzbC4wNTEtLjA0LjAxNy0uMDE0YS4zMDcuMzA3IDAgMTEuMzgxLjQ3N2wtLjAyNC4wMmMtLjAxNS4wMTItLjAzLjAyNS0uMDQzLjAzNGEyLjUzNyAyLjUzNyAwIDAxLS4yNTQuMTQ4IDIuODcgMi44NyAwIDAwLS40NTUuMzIuMjQxLjI0MSAwIDAwLS4wNTguMTcybC0uMDUuMDQ0LS4wNTguMDUzYy41NDIuODA2Ljc3IDEuNzgzLjYzNyAyLjc0NWwuMTIzLjAzNmMuMDMxLjA1NS4wNzcuMTAxLjEzMy4xMzIuMTc5LjA0OC4zNjMuMDc4LjU0OC4wOXpNNy4yOTEgNS4yNGMuMTA3LS4wMjQuMjE2LS4wNDMuMzI2LS4wNTZsLS4wOSAxLjYtLjAwOC4wMDRhLjI2OC4yNjggMCAwMS0uMjkzLjI1Ni4yNy4yNyAwIDAxLS4xMzUtLjA1bC0uMDAyLjAwMS0xLjMxNi0uOTNjLjQxOS0uNDEuOTQ1LS42OTYgMS41MTgtLjgyNXptMS42MTggMS43NWwxLjMwOC0uOTI0YTMuMTgyIDMuMTgyIDAgMDAtMS44MzMtLjg4MmwuMDkgMS41OThoLjAwMmEuMjY4LjI2OCAwIDAwLjI5NC4yNTYuMjcuMjcgMCAwMC4xMzUtLjA1bC4wMDQuMDAyem0yLjI0OCAxLjY1Nkw5LjYwOSA4LjJsLS4wMDItLjAwNmEuMjcuMjcgMCAwMS0uMTg1LS4zNDMuMjcuMjcgMCAwMS4wOC0uMTJMOS41IDcuNzNsMS4xOTUtMS4wNjdjLjM2Ni41OTQuNTI3IDEuMjkuNDYgMS45ODN6TTkuMDk2IDkuNWwuNjE4IDEuNDlhMy4xNDggMy4xNDggMCAwMDEuMjc1LTEuNTk4bC0xLjU5My0uMjY5LS4wMDIuMDAzYS4yNi4yNiAwIDAwLS4xNjYuMDIzLjI3LjI3IDAgMDAtLjEzLjM0OGwtLjAwMi4wMDN6bS0uMzg1IDEuOTA1Yy0uNTczLjEzLTEuMTcuMS0xLjcyNy0uMDg4bC43NzctMS40aC4wMDFhLjI3LjI3IDAgMDEuNDc1LS4wMDFoLjAwNmwuNzc5IDEuNDAyYTMuMjg2IDMuMjg2IDAgMDEtLjMxMS4wODd6bS0yLjQxOC0uNDIybC42MTEtMS40NzQtLjAwNC0uMDA2YS4yNjguMjY4IDAgMDAtLjI5Ny0uMzdMNi42IDkuMTNsLTEuNTc5LjI2N2EzLjE2IDMuMTYgMCAwMDEuMjcyIDEuNTg2em0tLjk5Ny00LjMybDEuMjAxIDEuMDcxLS4wMDEuMDA3YS4yNjkuMjY5IDAgMDEtLjEwNi40NjJsLS4wMDEuMDA1LTEuNTQuNDQzYTMuMTM0IDMuMTM0IDAgMDEuNDQ3LTEuOTg4em0yLjk1IDEuMTU0aC0uNDkybC0uMzA3LjM4LjExLjQ3Ni40NDMuMjEzLjQ0Mi0uMjEyLjExLS40NzYtLjMwNi0uMzgxeiIgY2xpcC1ydWxlPSJldmVub2RkIi8+PC9zdmc+CjxyZWN0IHg9IjI2IiB5PSI4OCIgd2lkdGg9IjEyOCIgaGVpZ2h0PSIxMTIiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iOTAiIHk9IjEyNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxM3B4Ij5Zb3VyIGFwcDwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjE0NSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPlBvc3RncmVTUUwgZHJpdmVyPC90ZXh0Pgo8dGV4dCB4PSI5MCIgeT0iMTYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPnVuY2hhbmdlZDwvdGV4dD4KPHRleHQgeD0iMjAwIiB5PSI4MiIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGI7IGZpbGw6IzZlZTdiNyI+REFUQUJBU0UgUkVRVUVTVFMgwrcgRElSRUNUIENPTk5FQ1RJT048L3RleHQ+CjxsaW5lIHgxPSIxNTQiIHkxPSIxMDgiIHgyPSI2MTAiIHkyPSIxMDgiIHN0cm9rZS13aWR0aD0iMi4yIiBtYXJrZXItZW5kPSJ1cmwoI2FoZC1jbG91ZG5hdGl2ZXBnKSIgc3R5bGU9InN0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjM4MiIgeT0iMTAwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiODsgZmlsbDojNmVlN2I3Ij5TUUwgb3ZlciBwZ3dpcmU8L3RleHQ+CjxyZWN0IHg9IjYxNCIgeT0iNzYiIHdpZHRoPSIxOTYiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz48c3ZnIHg9Ijc4NiIgeT0iNTYiIHdpZHRoPSIyMCIgaGVpZ2h0PSIyMCIgdmlld0JveD0iMCAwIDQzMi4wNzEgNDQ1LjM4MyIgcHJlc2VydmVBc3BlY3RSYXRpbz0ieE1pZFlNaWQgbWVldCI+PGcgc3R5bGU9ImZpbGwtcnVsZTpub256ZXJvO2NsaXAtcnVsZTpub256ZXJvO3N0cm9rZTojMDAwMDAwO3N0cm9rZS1taXRlcmxpbWl0OjQiPiA8L2c+IDxnIHN0eWxlPSJmaWxsLXJ1bGU6bm9uemVybztjbGlwLXJ1bGU6bm9uemVybztmaWxsOm5vbmU7c3Ryb2tlOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjEyLjQ2NTE7c3Ryb2tlLWxpbmVjYXA6cm91bmQ7c3Ryb2tlLWxpbmVqb2luOnJvdW5kO3N0cm9rZS1taXRlcmxpbWl0OjQiPiA8cGF0aCBkPSJNMzIzLjIwNSwzMjQuMjI3YzIuODMzLTIzLjYwMSwxLjk4NC0yNy4wNjIsMTkuNTYzLTIzLjIzOWw0LjQ2MywwLjM5MmMxMy41MTcsMC42MTUsMzEuMTk5LTIuMTc0LDQxLjU4Ny03YzIyLjM2Mi0xMC4zNzYsMzUuNjIyLTI3LjcsMTMuNTcyLTIzLjE0OGMtNTAuMjk3LDEwLjM3Ni01My43NTUtNi42NTUtNTMuNzU1LTYuNjU1YzUzLjExMS03OC44MDMsNzUuMzEzLTE3OC44MzYsNTYuMTQ5LTIwMy4zMjIgQzM1Mi41MTQtNS41MzQsMjYyLjAzNiwyNi4wNDksMjYwLjUyMiwyNi44NjlsLTAuNDgyLDAuMDg5Yy05LjkzOC0yLjA2Mi0yMS4wNi0zLjI5NC0zMy41NTQtMy40OTZjLTIyLjc2MS0wLjM3NC00MC4wMzIsNS45NjctNTMuMTMzLDE1LjkwNGMwLDAtMTYxLjQwOC02Ni40OTgtMTUzLjg5OSw4My42MjhjMS41OTcsMzEuOTM2LDQ1Ljc3NywyNDEuNjU1LDk4LjQ3LDE3OC4zMSBjMTkuMjU5LTIzLjE2MywzNy44NzEtNDIuNzQ4LDM3Ljg3MS00Mi43NDhjOS4yNDIsNi4xNCwyMC4zMDcsOS4yNzIsMzEuOTEyLDguMTQ3bDAuODk3LTAuNzY1Yy0wLjI4MSwyLjg3Ni0wLjE1Nyw1LjY4OSwwLjM1OSw5LjAxOWMtMTMuNTcyLDE1LjE2Ny05LjU4NCwxNy44My0zNi43MjMsMjMuNDE2Yy0yNy40NTcsNS42NTktMTEuMzI2LDE1LjczNC0wLjc5NywxOC4zNjdjMTIuNzY4LDMuMTkzLDQyLjMwNSw3LjcxNiw2Mi4yNjgtMjAuMjI0IGwtMC43OTUsMy4xODhjNS4zMjUsNC4yNiw0Ljk2NSwzMC42MTksNS43Miw0OS40NTJjMC43NTYsMTguODM0LDIuMDE3LDM2LjQwOSw1Ljg1Niw0Ni43NzFjMy44MzksMTAuMzYsOC4zNjksMzcuMDUsNDQuMDM2LDI5LjQwNmMyOS44MDktNi4zODgsNTIuNi0xNS41ODIsNTQuNjc3LTEwMS4xMDciIHN0eWxlPSJmaWxsOiMwMDAwMDA7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjM3LjM5NTM7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTQwMi4zOTUsMjcxLjIzYy01MC4zMDIsMTAuMzc2LTUzLjc2LTYuNjU1LTUzLjc2LTYuNjU1YzUzLjExMS03OC44MDgsNzUuMzEzLTE3OC44NDMsNTYuMTUzLTIwMy4zMjZjLTUyLjI3LTY2Ljc4NS0xNDIuNzUyLTM1LjItMTQ0LjI2Mi0zNC4zOGwtMC40ODYsMC4wODdjLTkuOTM4LTIuMDYzLTIxLjA2LTMuMjkyLTMzLjU2LTMuNDk2Yy0yMi43NjEtMC4zNzMtNDAuMDI2LDUuOTY3LTUzLjEyNywxNS45MDIgYzAsMC0xNjEuNDExLTY2LjQ5NS0xNTMuOTA0LDgzLjYzYzEuNTk3LDMxLjkzOCw0NS43NzYsMjQxLjY1Nyw5OC40NzEsMTc4LjMxMmMxOS4yNi0yMy4xNjMsMzcuODY5LTQyLjc0OCwzNy44NjktNDIuNzQ4YzkuMjQzLDYuMTQsMjAuMzA4LDkuMjcyLDMxLjkwOCw4LjE0N2wwLjkwMS0wLjc2NWMtMC4yOCwyLjg3Ni0wLjE1Miw1LjY4OSwwLjM2MSw5LjAxOWMtMTMuNTc1LDE1LjE2Ny05LjU4NiwxNy44My0zNi43MjMsMjMuNDE2IGMtMjcuNDU5LDUuNjU5LTExLjMyOCwxNS43MzQtMC43OTYsMTguMzY3YzEyLjc2OCwzLjE5Myw0Mi4zMDcsNy43MTYsNjIuMjY2LTIwLjIyNGwtMC43OTYsMy4xODhjNS4zMTksNC4yNiw5LjA1NCwyNy43MTEsOC40MjgsNDguOTY5Yy0wLjYyNiwyMS4yNTktMS4wNDQsMzUuODU0LDMuMTQ3LDQ3LjI1NGM0LjE5MSwxMS40LDguMzY4LDM3LjA1LDQ0LjA0MiwyOS40MDZjMjkuODA5LTYuMzg4LDQ1LjI1Ni0yMi45NDIsNDcuNDA1LTUwLjU1NSBjMS41MjUtMTkuNjMxLDQuOTc2LTE2LjcyOSw1LjE5NC0zNC4yOGwyLjc2OC04LjMwOWMzLjE5Mi0yNi42MTEsMC41MDctMzUuMTk2LDE4Ljg3Mi0zMS4yMDNsNC40NjMsMC4zOTJjMTMuNTE3LDAuNjE1LDMxLjIwOC0yLjE3NCw0MS41OTEtN2MyMi4zNTgtMTAuMzc2LDM1LjYxOC0yNy43LDEzLjU3My0yMy4xNDh6IiBzdHlsZT0iZmlsbDojMzM2NzkxO3N0cm9rZTpub25lIi8+IDxwYXRoIGQ9Ik0yMTUuODY2LDI4Ni40ODRjLTEuMzg1LDQ5LjUxNiwwLjM0OCw5OS4zNzcsNS4xOTMsMTExLjQ5NWM0Ljg0OCwxMi4xMTgsMTUuMjIzLDM1LjY4OCw1MC45LDI4LjA0NWMyOS44MDYtNi4zOSw0MC42NTEtMTguNzU2LDQ1LjM1Ny00Ni4wNTFjMy40NjYtMjAuMDgyLDEwLjE0OC03NS44NTQsMTEuMDA1LTg3LjI4MSIvPiA8cGF0aCBkPSJNMTczLjEwNCwzOC4yNTZjMCwwLTE2MS41MjEtNjYuMDE2LTE1NC4wMTIsODQuMTA5YzEuNTk3LDMxLjkzOCw0NS43NzksMjQxLjY2NCw5OC40NzMsMTc4LjMxNmMxOS4yNTYtMjMuMTY2LDM2LjY3MS00MS4zMzUsMzYuNjcxLTQxLjMzNSIvPiA8cGF0aCBkPSJNMjYwLjM0OSwyNi4yMDdjLTUuNTkxLDEuNzUzLDg5Ljg0OC0zNC44ODksMTQ0LjA4NywzNC40MTdjMTkuMTU5LDI0LjQ4NC0zLjA0MywxMjQuNTE5LTU2LjE1MywyMDMuMzI5Ii8+IDxwYXRoIGQ9Ik0zNDguMjgyLDI2My45NTNjMCwwLDMuNDYxLDE3LjAzNiw1My43NjQsNi42NTNjMjIuMDQtNC41NTIsOC43NzYsMTIuNzc0LTEzLjU3NywyMy4xNTVjLTE4LjM0NSw4LjUxNC01OS40NzQsMTAuNjk2LTYwLjE0Ni0xLjA2OWMtMS43MjktMzAuMzU1LDIxLjY0Ny0yMS4xMzMsMTkuOTYtMjguNzM5Yy0xLjUyNS02Ljg1LTExLjk3OS0xMy41NzMtMTguODk0LTMwLjMzOCBjLTYuMDM3LTE0LjYzMy04Mi43OTYtMTI2Ljg0OSwyMS4yODctMTEwLjE4M2MzLjgxMy0wLjc4OS0yNy4xNDYtOTkuMDAyLTEyNC41NTMtMTAwLjU5OWMtOTcuMzg1LTEuNTk3LTk0LjE5LDExOS43NjItOTQuMTksMTE5Ljc2MiIgc3R5bGU9InN0cm9rZS1saW5lam9pbjpiZXZlbCIvPiA8cGF0aCBkPSJNMTg4LjYwNCwyNzQuMzM0Yy0xMy41NzcsMTUuMTY2LTkuNTg0LDE3LjgyOS0zNi43MjMsMjMuNDE3Yy0yNy40NTksNS42Ni0xMS4zMjYsMTUuNzMzLTAuNzk3LDE4LjM2NWMxMi43NjgsMy4xOTUsNDIuMzA3LDcuNzE4LDYyLjI2Ni0yMC4yMjljNi4wNzgtOC41MDktMC4wMzYtMjIuMDg2LTguMzg1LTI1LjU0N2MtNC4wMzQtMS42NzEtOS40MjgtMy43NjUtMTYuMzYxLDMuOTk0eiIvPiA8cGF0aCBkPSJNMTg3LjcxNSwyNzQuMDY5Yy0xLjM2OC04LjkxNywyLjkzLTE5LjUyOCw3LjUzNi0zMS45NDJjNi45MjItMTguNjI2LDIyLjg5My0zNy4yNTUsMTAuMTE3LTk2LjMzOWMtOS41MjMtNDQuMDI5LTczLjM5Ni05LjE2My03My40MzYtMy4xOTNjLTAuMDM5LDUuOTY4LDIuODg5LDMwLjI2LTEuMDY3LDU4LjU0OGMtNS4xNjIsMzYuOTEzLDIzLjQ4OCw2OC4xMzIsNTYuNDc5LDY0LjkzOCIvPiA8cGF0aCBkPSJNMTcyLjUxNywxNDEuN2MtMC4yODgsMi4wMzksMy43MzMsNy40OCw4Ljk3Niw4LjIwN2M1LjIzNCwwLjczLDkuNzE0LTMuNTIyLDkuOTk4LTUuNTU5YzAuMjg0LTIuMDM5LTMuNzMyLTQuMjg1LTguOTc3LTUuMDE1Yy01LjIzNy0wLjczMS05LjcxOSwwLjMzMy05Ljk5NiwyLjM2N3oiIHN0eWxlPSJmaWxsOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjQuMTU1O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyIi8+IDxwYXRoIGQ9Ik0zMzEuOTQxLDEzNy41NDNjMC4yODQsMi4wMzktMy43MzIsNy40OC04Ljk3Niw4LjIwN2MtNS4yMzgsMC43My05LjcxOC0zLjUyMi0xMC4wMDUtNS41NTljLTAuMjc3LTIuMDM5LDMuNzQtNC4yODUsOC45NzktNS4wMTVjNS4yMzktMC43Myw5LjcxOCwwLjMzMywxMC4wMDIsMi4zNjh6IiBzdHlsZT0iZmlsbDojRkZGRkZGO3N0cm9rZS13aWR0aDoyLjA3NzU7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTM1MC42NzYsMTIzLjQzMmMwLjg2MywxNS45OTQtMy40NDUsMjYuODg4LTMuOTg4LDQzLjkxNGMtMC44MDQsMjQuNzQ4LDExLjc5OSw1My4wNzQtNy4xOTEsODEuNDM1Ii8+IDxwYXRoIGQ9Ik0wLDYwLjIzMiIgc3R5bGU9InN0cm9rZS13aWR0aDozIi8+IDwvZz48L3N2Zz4KPHRleHQgeD0iNzEyIiB5PSIxMDMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTJweCI+Q2xvdWROYXRpdmVQRzwvdGV4dD4KPHRleHQgeD0iNzEyIiB5PSIxMjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5Qb3N0Z3JlU1FMIG9uIEt1YmVybmV0ZXM8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iMTU4IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzY0NzQ4YiI+TUFOQUdFTUVOVCBSRVFVRVNUUyDCtyBWSUEgVEVOU09SOTwvdGV4dD4KPGxpbmUgeDE9IjE1NCIgeTE9IjE5NiIgeDI9IjMwMCIgeTI9IjE5NiIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoZC1jbG91ZG5hdGl2ZXBnKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjIyNyIgeT0iMTg4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiOCI+UkRTIEFQSTwvdGV4dD4KPHJlY3QgeD0iMzA0IiB5PSIxNjQiIHdpZHRoPSIxODAiIGhlaWdodD0iNjYiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iMzk0IiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSIzOTQiIHk9IjIwOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+c2VydmljZSBhZGFwdGVyPC90ZXh0Pgo8bGluZSB4MT0iNDg0IiB5MT0iMTk2IiB4Mj0iNjEwIiB5Mj0iMTk2IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLWNsb3VkbmF0aXZlcGcpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHJlY3QgeD0iNjE0IiB5PSIxNjQiIHdpZHRoPSIxOTYiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iNzEyIiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTEuNXB4Ij5DbG91ZE5hdGl2ZVBHIHJlc291cmNlczwvdGV4dD4KPHRleHQgeD0iNzEyIiB5PSIyMTAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij50aGUgYmFja2VuZCdzIG1hbmFnZW1lbnQgQVBJPC90ZXh0Pgo8L3N2Zz4=)

Queries reach the database directly; only the management calls are translated.

#### Database connections

Aurora stores data in an AWS-specific storage layer, but your application reaches it over the standard PostgreSQL wire protocol, which CloudNativePG also supports. Your SQL, drivers, object-relational mappers (ORMs), prepared statements, data types and transaction behavior stay the same; only the storage underneath changes.

AWS and Aurora add SQL functions for moving data through S3, invoking Lambda and machine learning. These functions do not exist on the backend, so a query that calls them returns an error.

#### Database management

At runtime your application and tools keep making the same RDS calls. For each supported operation, the adapter accepts the RDS request, returns the RDS response format, and performs it through CloudNativePG's Kubernetes resources. Backups and restores use its backup and recovery objects, and point-in-time restore uses its own point-in-time recovery. Readers change the cluster's instance count, and manual failover promotes a replica. Stop / start scales the cluster down and back up. Parameter changes update the cluster's PostgreSQL configuration. CloudNativePG's built-in pooler takes the place of RDS Proxy for managed connection pooling.

The adapter also runs the Aurora Data API (SQL over HTTPS, transactions included), executing each statement over a native connection to the backend database.

When your product is deployed into the target environment, Tensor9 compiles the cluster your stack already declares into the matching CloudNativePG resources and puts the endpoint and credentials in your application's configuration. The adapter then handles the management calls your running system makes.

![The Tensor9 service adapter handles RDS management requests using CloudNativePG resources and returns RDS responses.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTk2IiB2aWV3Qm94PSIwIDAgODM2IDE5NiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgaGFuZGxlcyBSRFMgbWFuYWdlbWVudCByZXF1ZXN0cyB1c2luZyBDbG91ZE5hdGl2ZVBHIHJlc291cmNlcyBhbmQgcmV0dXJucyBSRFMgcmVzcG9uc2VzLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaGMtcmRzLWNsb3VkbmF0aXZlcGctcmVzb3VyY2VzIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM5NGEzYjgiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjE2IiB5PSIzNCIgd2lkdGg9IjIzNiIgaGVpZ2h0PSIxMjgiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iMTM0IiB5PSI2MCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMi41cHgiPlJEUyBtYW5hZ2VtZW50IGNhbGw8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iODIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5zbmFwc2hvdCDCtyBwb2ludC1pbi10aW1lIHJlc3RvcmU8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iOTkiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5yZWFkZXIgwrcgcmVwbGljYSBwcm9tb3Rpb248L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iMTE2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+RGF0YSBBUEkgwrcgcGFyYW1ldGVyczwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSIxNDIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiIj5zYW1lIHJlcXVlc3QgLyByZXNwb25zZSBzaGFwZXM8L3RleHQ+CjxsaW5lIHgxPSIyNTIiIHkxPSI3NCIgeDI9IjMxNCIgeTI9Ijc0IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhjLXJkcy1jbG91ZG5hdGl2ZXBnLXJlc291cmNlcykiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8bGluZSB4MT0iMzE4IiB5MT0iMTI4IiB4Mj0iMjU2IiB5Mj0iMTI4IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhjLXJkcy1jbG91ZG5hdGl2ZXBnLXJlc291cmNlcykiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8cmVjdCB4PSIzMTgiIHk9IjU0IiB3aWR0aD0iMjA0IiBoZWlnaHQ9Ijg4IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjQyMCIgeT0iOTQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSI0MjAiIHk9IjExMiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+c2VydmljZSBhZGFwdGVyPC90ZXh0Pgo8bGluZSB4MT0iNTIyIiB5MT0iNzQiIHgyPSI1ODQiIHkyPSI3NCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtY2xvdWRuYXRpdmVwZy1yZXNvdXJjZXMpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPGxpbmUgeDE9IjU4OCIgeTE9IjEyOCIgeDI9IjUyNiIgeTI9IjEyOCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtY2xvdWRuYXRpdmVwZy1yZXNvdXJjZXMpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHJlY3QgeD0iNTg4IiB5PSIzNCIgd2lkdGg9IjIzMiIgaGVpZ2h0PSIxMjgiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iNzA0IiB5PSI2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMnB4Ij5DbG91ZE5hdGl2ZVBHIHJlc291cmNlczwvdGV4dD4KPHRleHQgeD0iNzA0IiB5PSI5NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPmJhY2t1cHMgwrcgcmVjb3ZlcnkgwrcgcmVwbGljYXM8L3RleHQ+Cjx0ZXh0IHg9IjcwNCIgeT0iMTExIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+cHJvbW90aW9uIMK3IGNvbmZpZ3VyYXRpb248L3RleHQ+Cjwvc3ZnPg==)

![The Tensor9 service adapter handles RDS management requests using CloudNativePG resources and returns RDS responses.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTk2IiB2aWV3Qm94PSIwIDAgODM2IDE5NiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgaGFuZGxlcyBSRFMgbWFuYWdlbWVudCByZXF1ZXN0cyB1c2luZyBDbG91ZE5hdGl2ZVBHIHJlc291cmNlcyBhbmQgcmV0dXJucyBSRFMgcmVzcG9uc2VzLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaGMtcmRzLWNsb3VkbmF0aXZlcGctcmVzb3VyY2VzIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM2NDc0OGIiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjE2IiB5PSIzNCIgd2lkdGg9IjIzNiIgaGVpZ2h0PSIxMjgiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iMTM0IiB5PSI2MCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMi41cHgiPlJEUyBtYW5hZ2VtZW50IGNhbGw8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iODIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5zbmFwc2hvdCDCtyBwb2ludC1pbi10aW1lIHJlc3RvcmU8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iOTkiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5yZWFkZXIgwrcgcmVwbGljYSBwcm9tb3Rpb248L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iMTE2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+RGF0YSBBUEkgwrcgcGFyYW1ldGVyczwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSIxNDIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4Ij5zYW1lIHJlcXVlc3QgLyByZXNwb25zZSBzaGFwZXM8L3RleHQ+CjxsaW5lIHgxPSIyNTIiIHkxPSI3NCIgeDI9IjMxNCIgeTI9Ijc0IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhjLXJkcy1jbG91ZG5hdGl2ZXBnLXJlc291cmNlcykiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8bGluZSB4MT0iMzE4IiB5MT0iMTI4IiB4Mj0iMjU2IiB5Mj0iMTI4IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhjLXJkcy1jbG91ZG5hdGl2ZXBnLXJlc291cmNlcykiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8cmVjdCB4PSIzMTgiIHk9IjU0IiB3aWR0aD0iMjA0IiBoZWlnaHQ9Ijg4IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjQyMCIgeT0iOTQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSI0MjAiIHk9IjExMiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+c2VydmljZSBhZGFwdGVyPC90ZXh0Pgo8bGluZSB4MT0iNTIyIiB5MT0iNzQiIHgyPSI1ODQiIHkyPSI3NCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtY2xvdWRuYXRpdmVwZy1yZXNvdXJjZXMpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPGxpbmUgeDE9IjU4OCIgeTE9IjEyOCIgeDI9IjUyNiIgeTI9IjEyOCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtY2xvdWRuYXRpdmVwZy1yZXNvdXJjZXMpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHJlY3QgeD0iNTg4IiB5PSIzNCIgd2lkdGg9IjIzMiIgaGVpZ2h0PSIxMjgiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iNzA0IiB5PSI2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMnB4Ij5DbG91ZE5hdGl2ZVBHIHJlc291cmNlczwvdGV4dD4KPHRleHQgeD0iNzA0IiB5PSI5NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPmJhY2t1cHMgwrcgcmVjb3ZlcnkgwrcgcmVwbGljYXM8L3RleHQ+Cjx0ZXh0IHg9IjcwNCIgeT0iMTExIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+cHJvbW90aW9uIMK3IGNvbmZpZ3VyYXRpb248L3RleHQ+Cjwvc3ZnPg==)

Tensor9 translates RDS management requests to the backend API and returns RDS responses.

#### Limitations

Where Aurora and CloudNativePG differ

* **Global databases are not supported.** The Cloud Adapter deployment runs a single CloudNativePG cluster; cross-region readers or a standby region would need a second Cloud Adapter deployment.
* **Aurora-specific settings are not supported.** Failover priority / promotion tiers, Serverless v2 autoscaling, global write forwarding and I/O-Optimized storage have no CloudNativePG equivalent.
* **RDS event subscriptions are not supported.** RDS event notifications publish to SNS. Here the closest equivalents are Kubernetes events and Prometheus alerts, which work differently.
* **Parameter groups behave differently: each parameter becomes a cluster setting.** Each PostgreSQL parameter goes into the cluster's configuration; the group object itself is not created.

#### Other considerations

**Migration.** Moving the data is a one-time step, covered by this page's migration note: a logical dump and restore, or logical replication for a short cutover. This page describes how things work after cutover.

**Operations.** CloudNativePG is self-operated: after cutover the customer's team runs the cluster (backups, upgrades, failover drills), with no cloud database vendor behind it.

**Features and capacity.** The comparison table on this page lists feature and high-availability differences. Check the backend's pricing and capacity limits when you size the deployment.

#### 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.

##### Aurora PostgreSQL · Primary allocated compute

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Primary allocated compute. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Aurora PostgreSQL · 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/d3758fe8cc074e4f64f798bbe54b725cf933d6afcfeca963602cf6012ccbadf4-light.svg)

![Aurora PostgreSQL · 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/edd5ba991a97c4bc06701c09b9a402d9974e136a605a2b86420d159a8a81cba4-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) | Aurora PostgreSQL | Target scenario | PostgreSQL (CloudNativePG) | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | PostgreSQL (CloudNativePG) (one copy) | 80.90 | 80.90 |
| 0 | 0.00 | PostgreSQL (CloudNativePG) (two copies) | 161.79 | 161.79 |
| 1,460 | 211.70 | PostgreSQL (CloudNativePG) (one copy) | 80.90 | -130.80 |
| 1,460 | 211.70 | PostgreSQL (CloudNativePG) (two copies) | 161.79 | -49.91 |
| 2,920 | 423.40 | PostgreSQL (CloudNativePG) (one copy) | 151.79 | -271.61 |
| 2,920 | 423.40 | PostgreSQL (CloudNativePG) (two copies) | 303.58 | -119.82 |
| 5,840 | 846.80 | PostgreSQL (CloudNativePG) (one copy) | 293.58 | -553.22 |
| 5,840 | 846.80 | PostgreSQL (CloudNativePG) (two copies) | 587.17 | -259.63 |
| 11,680 | 1,693.60 | PostgreSQL (CloudNativePG) (one copy) | 577.17 | -1,116.43 |
| 11,680 | 1,693.60 | PostgreSQL (CloudNativePG) (two copies) | 1,154.34 | -539.26 |
| 23,360 | 3,387.20 | PostgreSQL (CloudNativePG) (one copy) | 1,144.34 | -2,242.86 |
| 23,360 | 3,387.20 | PostgreSQL (CloudNativePG) (two copies) | 2,288.68 | -1,098.52 |
| 46,720 | 6,774.40 | PostgreSQL (CloudNativePG) (one copy) | 2,278.68 | -4,495.72 |
| 46,720 | 6,774.40 | PostgreSQL (CloudNativePG) (two copies) | 4,557.35 | -2,217.05 |

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 |
| - | - | -: | - |
| PostgreSQL (CloudNativePG) (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| PostgreSQL (CloudNativePG) (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| PostgreSQL (CloudNativePG) (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (one copy) | Origin list price · Database reads | 0 | USD/operations |
| PostgreSQL (CloudNativePG) (one copy) | Origin list price · Database writes | 0 | USD/operations |
| PostgreSQL (CloudNativePG) (one copy) | Target CPU / source CPU | 1 | multiplier |
| PostgreSQL (CloudNativePG) (one copy) | Target RAM / source RAM | 1 | multiplier |
| PostgreSQL (CloudNativePG) (one copy) | Target disk / source disk | 1 | multiplier |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · read | 0 | USD/read |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · write | 0 | USD/write |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL (CloudNativePG) (one copy) | Target list price · GiB-month | 0.1 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL (CloudNativePG) (one copy) | Target list price · network GiB | 0.12 | USD/network GiB |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL (CloudNativePG) (one copy) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| PostgreSQL (CloudNativePG) (one copy) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL (CloudNativePG) (one copy) | Target monthly base charge | 0 | USD/month |
| PostgreSQL (CloudNativePG) (one copy) | Approximate target service minimum | 0 | USD/month |
| PostgreSQL (CloudNativePG) (one copy) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL (CloudNativePG) (one copy) | Minimum primary RAM | 8 | GiB |
| PostgreSQL (CloudNativePG) (one copy) | Minimum primary disk | 100 | GiB |
| PostgreSQL (CloudNativePG) (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| PostgreSQL (CloudNativePG) (one copy) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL (CloudNativePG) (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL (CloudNativePG) (one copy) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL (CloudNativePG) (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL (CloudNativePG) (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL (CloudNativePG) (one copy) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL (CloudNativePG) (one copy) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL (CloudNativePG) (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL (CloudNativePG) (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL (CloudNativePG) (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| PostgreSQL (CloudNativePG) (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| PostgreSQL (CloudNativePG) (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| PostgreSQL (CloudNativePG) (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (two copies) | Origin list price · Database reads | 0 | USD/operations |
| PostgreSQL (CloudNativePG) (two copies) | Origin list price · Database writes | 0 | USD/operations |
| PostgreSQL (CloudNativePG) (two copies) | Target CPU / source CPU | 1 | multiplier |
| PostgreSQL (CloudNativePG) (two copies) | Target RAM / source RAM | 1 | multiplier |
| PostgreSQL (CloudNativePG) (two copies) | Target disk / source disk | 1 | multiplier |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · read | 0 | USD/read |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · write | 0 | USD/write |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL (CloudNativePG) (two copies) | Target list price · GiB-month | 0.1 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL (CloudNativePG) (two copies) | Target list price · network GiB | 0.12 | USD/network GiB |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL (CloudNativePG) (two copies) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| PostgreSQL (CloudNativePG) (two copies) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL (CloudNativePG) (two copies) | Target monthly base charge | 0 | USD/month |
| PostgreSQL (CloudNativePG) (two copies) | Approximate target service minimum | 0 | USD/month |
| PostgreSQL (CloudNativePG) (two copies) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL (CloudNativePG) (two copies) | Minimum primary RAM | 8 | GiB |
| PostgreSQL (CloudNativePG) (two copies) | Minimum primary disk | 100 | GiB |
| PostgreSQL (CloudNativePG) (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| PostgreSQL (CloudNativePG) (two copies) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL (CloudNativePG) (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL (CloudNativePG) (two copies) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL (CloudNativePG) (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL (CloudNativePG) (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL (CloudNativePG) (two copies) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL (CloudNativePG) (two copies) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL (CloudNativePG) (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL (CloudNativePG) (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL (CloudNativePG) (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* Self-hosted target: CloudNativePG (Apache-2.0, [https://github.com/cloudnative-pg/cloudnative-pg/blob/main/LICENSE](https://github.com/cloudnative-pg/cloudnative-pg/blob/main/LICENSE)) with PostgreSQL. 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-dd3a8615165abfe7fa17fb70889dc6979bc55d1a` / `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).

##### Aurora PostgreSQL · Stored data

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Aurora PostgreSQL · 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/5785b16cdccc0a1bccaf1ae22d7545450eedf82398949a4e6af3d5e444c18e7e-light.svg)

![Aurora PostgreSQL · 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/1faa672955f9419b92a8d7716341997bd6344cd457bb894b16fb36ddcdda11bf-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) | Aurora PostgreSQL | Target scenario | PostgreSQL (CloudNativePG) | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | PostgreSQL (CloudNativePG) (one copy) | 80.90 | 80.90 |
| 0 | 0.00 | PostgreSQL (CloudNativePG) (two copies) | 161.79 | 161.79 |
| 10 | 1.00 | PostgreSQL (CloudNativePG) (one copy) | 80.90 | 79.90 |
| 10 | 1.00 | PostgreSQL (CloudNativePG) (two copies) | 161.79 | 160.79 |
| 100 | 10.00 | PostgreSQL (CloudNativePG) (one copy) | 85.90 | 75.90 |
| 100 | 10.00 | PostgreSQL (CloudNativePG) (two copies) | 171.79 | 161.79 |
| 1,000 | 100.00 | PostgreSQL (CloudNativePG) (one copy) | 198.40 | 98.40 |
| 1,000 | 100.00 | PostgreSQL (CloudNativePG) (two copies) | 396.79 | 296.79 |
| 10,000 | 1,000.00 | PostgreSQL (CloudNativePG) (one copy) | 1,323.40 | 323.40 |
| 10,000 | 1,000.00 | PostgreSQL (CloudNativePG) (two copies) | 2,646.79 | 1,646.79 |
| 100,000 | 10,000.00 | PostgreSQL (CloudNativePG) (one copy) | Unpriced | Unavailable |
| 100,000 | 10,000.00 | PostgreSQL (CloudNativePG) (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 |
| - | - | -: | - |
| PostgreSQL (CloudNativePG) (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| PostgreSQL (CloudNativePG) (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| PostgreSQL (CloudNativePG) (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (one copy) | Origin list price · Database reads | 0 | USD/operations |
| PostgreSQL (CloudNativePG) (one copy) | Origin list price · Database writes | 0 | USD/operations |
| PostgreSQL (CloudNativePG) (one copy) | Target CPU / source CPU | 1 | multiplier |
| PostgreSQL (CloudNativePG) (one copy) | Target RAM / source RAM | 1 | multiplier |
| PostgreSQL (CloudNativePG) (one copy) | Target disk / source disk | 1 | multiplier |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · read | 0 | USD/read |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · write | 0 | USD/write |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL (CloudNativePG) (one copy) | Target list price · GiB-month | 0.1 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL (CloudNativePG) (one copy) | Target list price · network GiB | 0.12 | USD/network GiB |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL (CloudNativePG) (one copy) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| PostgreSQL (CloudNativePG) (one copy) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL (CloudNativePG) (one copy) | Target monthly base charge | 0 | USD/month |
| PostgreSQL (CloudNativePG) (one copy) | Approximate target service minimum | 0 | USD/month |
| PostgreSQL (CloudNativePG) (one copy) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL (CloudNativePG) (one copy) | Minimum primary RAM | 8 | GiB |
| PostgreSQL (CloudNativePG) (one copy) | Minimum primary disk | 100 | GiB |
| PostgreSQL (CloudNativePG) (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| PostgreSQL (CloudNativePG) (one copy) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL (CloudNativePG) (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL (CloudNativePG) (one copy) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL (CloudNativePG) (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL (CloudNativePG) (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL (CloudNativePG) (one copy) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL (CloudNativePG) (one copy) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL (CloudNativePG) (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL (CloudNativePG) (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL (CloudNativePG) (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| PostgreSQL (CloudNativePG) (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| PostgreSQL (CloudNativePG) (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| PostgreSQL (CloudNativePG) (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (two copies) | Origin list price · Database reads | 0 | USD/operations |
| PostgreSQL (CloudNativePG) (two copies) | Origin list price · Database writes | 0 | USD/operations |
| PostgreSQL (CloudNativePG) (two copies) | Target CPU / source CPU | 1 | multiplier |
| PostgreSQL (CloudNativePG) (two copies) | Target RAM / source RAM | 1 | multiplier |
| PostgreSQL (CloudNativePG) (two copies) | Target disk / source disk | 1 | multiplier |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · read | 0 | USD/read |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · write | 0 | USD/write |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL (CloudNativePG) (two copies) | Target list price · GiB-month | 0.1 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL (CloudNativePG) (two copies) | Target list price · network GiB | 0.12 | USD/network GiB |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL (CloudNativePG) (two copies) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| PostgreSQL (CloudNativePG) (two copies) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL (CloudNativePG) (two copies) | Target monthly base charge | 0 | USD/month |
| PostgreSQL (CloudNativePG) (two copies) | Approximate target service minimum | 0 | USD/month |
| PostgreSQL (CloudNativePG) (two copies) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL (CloudNativePG) (two copies) | Minimum primary RAM | 8 | GiB |
| PostgreSQL (CloudNativePG) (two copies) | Minimum primary disk | 100 | GiB |
| PostgreSQL (CloudNativePG) (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| PostgreSQL (CloudNativePG) (two copies) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL (CloudNativePG) (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL (CloudNativePG) (two copies) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL (CloudNativePG) (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL (CloudNativePG) (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL (CloudNativePG) (two copies) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL (CloudNativePG) (two copies) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL (CloudNativePG) (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL (CloudNativePG) (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL (CloudNativePG) (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* Self-hosted target: CloudNativePG (Apache-2.0, [https://github.com/cloudnative-pg/cloudnative-pg/blob/main/LICENSE](https://github.com/cloudnative-pg/cloudnative-pg/blob/main/LICENSE)) with PostgreSQL. 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-dd3a8615165abfe7fa17fb70889dc6979bc55d1a` / `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).

##### Aurora PostgreSQL · Database writes

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Database writes. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

![Aurora PostgreSQL · 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/6ae6cf77035812d00446fead0bc84bb1499d164d312e1fc1be8893867dd8f7a0-light.svg)

![Aurora PostgreSQL · 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/ed82e031086e05b1cd403d5ab08cd08da66dcf956aff1979bf1c64808844a3f0-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) | Aurora PostgreSQL | Target scenario | PostgreSQL (CloudNativePG) | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | PostgreSQL (CloudNativePG) (one copy) | 80.90 | 80.90 |
| 0 | 0.00 | PostgreSQL (CloudNativePG) (two copies) | 161.79 | 161.79 |
| 1 | 0.00 | PostgreSQL (CloudNativePG) (one copy) | 80.90 | 80.90 |
| 1 | 0.00 | PostgreSQL (CloudNativePG) (two copies) | 161.79 | 161.79 |
| 10 | 0.00 | PostgreSQL (CloudNativePG) (one copy) | 80.90 | 80.90 |
| 10 | 0.00 | PostgreSQL (CloudNativePG) (two copies) | 161.79 | 161.79 |
| 100 | 0.00 | PostgreSQL (CloudNativePG) (one copy) | 80.90 | 80.90 |
| 100 | 0.00 | PostgreSQL (CloudNativePG) (two copies) | 161.79 | 161.79 |
| 1,000 | 0.00 | PostgreSQL (CloudNativePG) (one copy) | 80.90 | 80.90 |
| 1,000 | 0.00 | PostgreSQL (CloudNativePG) (two copies) | 161.79 | 161.79 |
| 10,000 | 0.00 | PostgreSQL (CloudNativePG) (one copy) | 80.90 | 80.90 |
| 10,000 | 0.00 | PostgreSQL (CloudNativePG) (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 |
| - | - | -: | - |
| PostgreSQL (CloudNativePG) (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| PostgreSQL (CloudNativePG) (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| PostgreSQL (CloudNativePG) (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (one copy) | Origin list price · Database reads | 0 | USD/operations |
| PostgreSQL (CloudNativePG) (one copy) | Origin list price · Database writes | 0 | USD/operations |
| PostgreSQL (CloudNativePG) (one copy) | Target CPU / source CPU | 1 | multiplier |
| PostgreSQL (CloudNativePG) (one copy) | Target RAM / source RAM | 1 | multiplier |
| PostgreSQL (CloudNativePG) (one copy) | Target disk / source disk | 1 | multiplier |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · read | 0 | USD/read |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · write | 0 | USD/write |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL (CloudNativePG) (one copy) | Target list price · GiB-month | 0.1 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL (CloudNativePG) (one copy) | Target list price · network GiB | 0.12 | USD/network GiB |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL (CloudNativePG) (one copy) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| PostgreSQL (CloudNativePG) (one copy) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL (CloudNativePG) (one copy) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL (CloudNativePG) (one copy) | Target monthly base charge | 0 | USD/month |
| PostgreSQL (CloudNativePG) (one copy) | Approximate target service minimum | 0 | USD/month |
| PostgreSQL (CloudNativePG) (one copy) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL (CloudNativePG) (one copy) | Minimum primary RAM | 8 | GiB |
| PostgreSQL (CloudNativePG) (one copy) | Minimum primary disk | 100 | GiB |
| PostgreSQL (CloudNativePG) (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| PostgreSQL (CloudNativePG) (one copy) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL (CloudNativePG) (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL (CloudNativePG) (one copy) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL (CloudNativePG) (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL (CloudNativePG) (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL (CloudNativePG) (one copy) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL (CloudNativePG) (one copy) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL (CloudNativePG) (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL (CloudNativePG) (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL (CloudNativePG) (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| PostgreSQL (CloudNativePG) (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| PostgreSQL (CloudNativePG) (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| PostgreSQL (CloudNativePG) (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (two copies) | Origin list price · Database reads | 0 | USD/operations |
| PostgreSQL (CloudNativePG) (two copies) | Origin list price · Database writes | 0 | USD/operations |
| PostgreSQL (CloudNativePG) (two copies) | Target CPU / source CPU | 1 | multiplier |
| PostgreSQL (CloudNativePG) (two copies) | Target RAM / source RAM | 1 | multiplier |
| PostgreSQL (CloudNativePG) (two copies) | Target disk / source disk | 1 | multiplier |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · read | 0 | USD/read |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · write | 0 | USD/write |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| PostgreSQL (CloudNativePG) (two copies) | Target list price · GiB-month | 0.1 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| PostgreSQL (CloudNativePG) (two copies) | Target list price · network GiB | 0.12 | USD/network GiB |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| PostgreSQL (CloudNativePG) (two copies) | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour |
| PostgreSQL (CloudNativePG) (two copies) | Target list price · GiB-hour | 0.004237 | USD/GiB-hour |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · input token | 0 | USD/input token |
| PostgreSQL (CloudNativePG) (two copies) | Target price guess · output token | 0 | USD/output token |
| PostgreSQL (CloudNativePG) (two copies) | Target monthly base charge | 0 | USD/month |
| PostgreSQL (CloudNativePG) (two copies) | Approximate target service minimum | 0 | USD/month |
| PostgreSQL (CloudNativePG) (two copies) | Minimum primary CPU | 2 | vCPU |
| PostgreSQL (CloudNativePG) (two copies) | Minimum primary RAM | 8 | GiB |
| PostgreSQL (CloudNativePG) (two copies) | Minimum primary disk | 100 | GiB |
| PostgreSQL (CloudNativePG) (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| PostgreSQL (CloudNativePG) (two copies) | Allocated share of provisioned cost | 1 | fraction |
| PostgreSQL (CloudNativePG) (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| PostgreSQL (CloudNativePG) (two copies) | Planning peak / mean work | 2 | multiplier |
| PostgreSQL (CloudNativePG) (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| PostgreSQL (CloudNativePG) (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| PostgreSQL (CloudNativePG) (two copies) | Planning disk utilization | 0.8 | fraction |
| PostgreSQL (CloudNativePG) (two copies) | Maintenance and log disk reserve | 20 | GiB |
| PostgreSQL (CloudNativePG) (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| PostgreSQL (CloudNativePG) (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| PostgreSQL (CloudNativePG) (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| PostgreSQL (CloudNativePG) (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* Self-hosted target: CloudNativePG (Apache-2.0, [https://github.com/cloudnative-pg/cloudnative-pg/blob/main/LICENSE](https://github.com/cloudnative-pg/cloudnative-pg/blob/main/LICENSE)) with PostgreSQL. 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-dd3a8615165abfe7fa17fb70889dc6979bc55d1a` / `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).

**Aurora PostgreSQL → PostgreSQL (CloudNativePG): 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.145 | USD/vCPU-hours |
| Origin list price · Primary memory | 0 | USD/GiB-hours |
| Origin list price · Primary provisioned storage | 0.1 | 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.

* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.

* Self-hosted target: CloudNativePG (Apache-2.0, [https://github.com/cloudnative-pg/cloudnative-pg/blob/main/LICENSE](https://github.com/cloudnative-pg/cloudnative-pg/blob/main/LICENSE)) with PostgreSQL. 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-dd3a8615165abfe7fa17fb70889dc6979bc55d1a` / `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 PostgreSQL

| 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. |
| Aurora-only surfaces | Capacity | Out of scope | Most usage | Serverless v2 scaling, global database and fast clones do not project -- Scaleway Managed Database has none of them. Capacity is taken from your primary cluster instance, and reader traffic collapses onto the instance endpoint, because a Scaleway read replica is a separate resource rather than a reader endpoint on the same cluster. |
| Non-default port | Engine | Partial | Most usage | An origin listening on a non-standard port is surfaced rather than silently moved -- Scaleway PostgreSQL listens where PostgreSQL listens. |
| The database | Engine | Supported | Common | Your PostgreSQL instance becomes a Scaleway Managed Database for PostgreSQL, 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 Aurora PostgreSQL cluster your stack declares into a Scaleway Managed Database for PostgreSQL instance. The instance class selects a Scaleway node type, the allocated storage becomes a block storage volume, and the PostgreSQL major version is preserved where Scaleway still supports it. Capacity comes from the cluster's primary instance, and a cluster with two or more instances becomes a high-availability instance with a hot standby.

Your application's PostgreSQL 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 pgwire) connect directly to Scaleway Managed DB. Tensor9 compiles the Aurora PostgreSQL cluster into Scaleway Managed DB at deployment; there is no management API at runtime.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgcGd3aXJlKSBjb25uZWN0IGRpcmVjdGx5IHRvIFNjYWxld2F5IE1hbmFnZWQgREIuIFRlbnNvcjkgY29tcGlsZXMgdGhlIEF1cm9yYSBQb3N0Z3JlU1FMIGNsdXN0ZXIgaW50byBTY2FsZXdheSBNYW5hZ2VkIERCIGF0IGRlcGxveW1lbnQ7IHRoZXJlIGlzIG5vIG1hbmFnZW1lbnQgQVBJIGF0IHJ1bnRpbWUuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojMzM0MTU1fTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImFoZC1kZXBsb3ktc2NhbGV3YXktbWFuYWdlZC1kYiIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNyIgbWFya2VySGVpZ2h0PSI3IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+PHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBzdHlsZT0iZmlsbDojOTRhM2I4Ii8+PC9tYXJrZXI+PC9kZWZzPgo8cmVjdCB4PSI4IiB5PSIzNCIgd2lkdGg9IjgyMCIgaGVpZ2h0PSIyMDYiIHJ4PSIxNiIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0cm9rZS1kYXNoYXJyYXk9IjUgNSIgc3R5bGU9ImZpbGw6I2Y4ZmFmYztzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSIyNiIgeT0iNTQiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4OyBmaWxsOiMwNDc4NTciPk9OIFNDQUxFV0FZPC90ZXh0Pgo8c3ZnIHg9Ijc5MiIgeT0iMzYiIHdpZHRoPSIxNiIgaGVpZ2h0PSIxNiIgdmlld0JveD0iMCAwIDE2IDE2IiBwcmVzZXJ2ZUFzcGVjdFJhdGlvPSJ4TWlkWU1pZCBtZWV0IiBmaWxsPSJub25lIj48cGF0aCBkPSJNOC4zNyAzLjY2Nkg1LjczNkExLjE4MiAxLjE4MiAwIDAgMCA0LjY5IDQuNzl2My44MWMwIC4yNTcuMS40OC4yNjcuNjQ3LjE2Ni4xNjcuMzg5LjI2Ny42NDQuMjY3LjUgMCAuOTEyLS40MTIuOTEyLS45MTNWNi4xODRjMC0uMzc5LjMxMS0uNjkxLjY5LS42OTFoMS4xODljLjI1NSAwIC40NzgtLjEuNjQ0LS4yNjdhLjkyNy45MjcgMCAwIDAgLjI2Ny0uNjU4YzAtLjUwMS0uNDMzLS45MDItLjkzNC0uOTAyWk03LjE4MSAxMi4zNTdoMi42MzVhMS4xODEgMS4xODEgMCAwIDAgMS4wNDUtMS4xMjZ2LTMuODFhLjkuOSAwIDAgMC0uMjY3LS42NDcuODk3Ljg5NyAwIDAgMC0uNjQ1LS4yNjdjLS41IDAtLjkxMi40MTItLjkxMi45MTR2Mi40MTdjMCAuMzgtLjMxLjY5MS0uNjg5LjY5MWgtMS4xOWMtLjI1NSAwLS40NzcuMS0uNjQ0LjI2OGEuOTI3LjkyNyAwIDAgMC0uMjY3LjY1Ny45MzQuOTM0IDAgMCAwIC45MzQuOTAyWiIgZmlsbD0iI0JGOTVGOSIvPiA8cGF0aCBmaWxsLXJ1bGU9ImV2ZW5vZGQiIGNsaXAtcnVsZT0iZXZlbm9kZCIgZD0iTTQuMDI0IDBoNC43OTFhNS42ODMgNS42ODMgMCAwIDEgNS42OTIgNS43MTZ2Ny41ODhBMy4wMjcgMy4wMjcgMCAwIDEgMTEuNzUgMTZINi43MDNDMy41NTcgMTYgMSAxMy40MzcgMSAxMC4yODRWMy4wMzFBMy4wMyAzLjAzIDAgMCAxIDQuMDI0IDBabTguNjcgNS43MTZjMC0yLjE0LTEuNzQ0LTMuODg5LTMuODc5LTMuODg5aC00Ljc4Yy0uNjY3IDAtMS4yLjUzNS0xLjIgMS4yMDR2Ny4yNTNhMy44OCAzLjg4IDAgMCAwIDMuODggMy44ODloNC45NTdhMS4xOTMgMS4xOTMgMCAwIDAgMS4wMjMtLjk4VjUuNzE1WiIgZmlsbD0iI0JGOTVGOSIvPjwvc3ZnPgo8cmVjdCB4PSIyNiIgeT0iNzYiIHdpZHRoPSIxMjgiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iOTAiIHk9IjEwMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxM3B4Ij5Zb3VyIGFwcDwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjExNyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPlBvc3RncmVTUUwgZHJpdmVyPC90ZXh0Pgo8dGV4dCB4PSI5MCIgeT0iMTMyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPnVuY2hhbmdlZDwvdGV4dD4KPHRleHQgeD0iMjAwIiB5PSI4MiIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjg7IGZpbGw6IzA0Nzg1NyI+REFUQUJBU0UgUkVRVUVTVFMgwrcgRElSRUNUIENPTk5FQ1RJT048L3RleHQ+CjxsaW5lIHgxPSIxNTQiIHkxPSIxMDgiIHgyPSI2MTAiIHkyPSIxMDgiIHN0cm9rZS13aWR0aD0iMi4yIiBtYXJrZXItZW5kPSJ1cmwoI2FoZC1kZXBsb3ktc2NhbGV3YXktbWFuYWdlZC1kYikiIHN0eWxlPSJzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSIzODIiIHk9IjEwMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZpbGw6IzA0Nzg1NyI+U1FMIG92ZXIgcGd3aXJlPC90ZXh0Pgo8cmVjdCB4PSI2MTQiIHk9Ijc2IiB3aWR0aD0iMTk2IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+CjxzdmcgeD0iNzg2IiB5PSI1NiIgd2lkdGg9IjIwIiBoZWlnaHQ9IjIwIiB2aWV3Qm94PSIwIDAgNDMyLjA3MSA0NDUuMzgzIiBwcmVzZXJ2ZUFzcGVjdFJhdGlvPSJ4TWlkWU1pZCBtZWV0Ij48ZyBzdHlsZT0iZmlsbC1ydWxlOm5vbnplcm87Y2xpcC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLW1pdGVybGltaXQ6NCI+IDwvZz4gPGcgc3R5bGU9ImZpbGwtcnVsZTpub256ZXJvO2NsaXAtcnVsZTpub256ZXJvO2ZpbGw6bm9uZTtzdHJva2U6I0ZGRkZGRjtzdHJva2Utd2lkdGg6MTIuNDY1MTtzdHJva2UtbGluZWNhcDpyb3VuZDtzdHJva2UtbGluZWpvaW46cm91bmQ7c3Ryb2tlLW1pdGVybGltaXQ6NCI+IDxwYXRoIGQ9Ik0zMjMuMjA1LDMyNC4yMjdjMi44MzMtMjMuNjAxLDEuOTg0LTI3LjA2MiwxOS41NjMtMjMuMjM5bDQuNDYzLDAuMzkyYzEzLjUxNywwLjYxNSwzMS4xOTktMi4xNzQsNDEuNTg3LTdjMjIuMzYyLTEwLjM3NiwzNS42MjItMjcuNywxMy41NzItMjMuMTQ4Yy01MC4yOTcsMTAuMzc2LTUzLjc1NS02LjY1NS01My43NTUtNi42NTVjNTMuMTExLTc4LjgwMyw3NS4zMTMtMTc4LjgzNiw1Ni4xNDktMjAzLjMyMiBDMzUyLjUxNC01LjUzNCwyNjIuMDM2LDI2LjA0OSwyNjAuNTIyLDI2Ljg2OWwtMC40ODIsMC4wODljLTkuOTM4LTIuMDYyLTIxLjA2LTMuMjk0LTMzLjU1NC0zLjQ5NmMtMjIuNzYxLTAuMzc0LTQwLjAzMiw1Ljk2Ny01My4xMzMsMTUuOTA0YzAsMC0xNjEuNDA4LTY2LjQ5OC0xNTMuODk5LDgzLjYyOGMxLjU5NywzMS45MzYsNDUuNzc3LDI0MS42NTUsOTguNDcsMTc4LjMxIGMxOS4yNTktMjMuMTYzLDM3Ljg3MS00Mi43NDgsMzcuODcxLTQyLjc0OGM5LjI0Miw2LjE0LDIwLjMwNyw5LjI3MiwzMS45MTIsOC4xNDdsMC44OTctMC43NjVjLTAuMjgxLDIuODc2LTAuMTU3LDUuNjg5LDAuMzU5LDkuMDE5Yy0xMy41NzIsMTUuMTY3LTkuNTg0LDE3LjgzLTM2LjcyMywyMy40MTZjLTI3LjQ1Nyw1LjY1OS0xMS4zMjYsMTUuNzM0LTAuNzk3LDE4LjM2N2MxMi43NjgsMy4xOTMsNDIuMzA1LDcuNzE2LDYyLjI2OC0yMC4yMjQgbC0wLjc5NSwzLjE4OGM1LjMyNSw0LjI2LDQuOTY1LDMwLjYxOSw1LjcyLDQ5LjQ1MmMwLjc1NiwxOC44MzQsMi4wMTcsMzYuNDA5LDUuODU2LDQ2Ljc3MWMzLjgzOSwxMC4zNiw4LjM2OSwzNy4wNSw0NC4wMzYsMjkuNDA2YzI5LjgwOS02LjM4OCw1Mi42LTE1LjU4Miw1NC42NzctMTAxLjEwNyIgc3R5bGU9ImZpbGw6IzAwMDAwMDtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MzcuMzk1MztzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNNDAyLjM5NSwyNzEuMjNjLTUwLjMwMiwxMC4zNzYtNTMuNzYtNi42NTUtNTMuNzYtNi42NTVjNTMuMTExLTc4LjgwOCw3NS4zMTMtMTc4Ljg0Myw1Ni4xNTMtMjAzLjMyNmMtNTIuMjctNjYuNzg1LTE0Mi43NTItMzUuMi0xNDQuMjYyLTM0LjM4bC0wLjQ4NiwwLjA4N2MtOS45MzgtMi4wNjMtMjEuMDYtMy4yOTItMzMuNTYtMy40OTZjLTIyLjc2MS0wLjM3My00MC4wMjYsNS45NjctNTMuMTI3LDE1LjkwMiBjMCwwLTE2MS40MTEtNjYuNDk1LTE1My45MDQsODMuNjNjMS41OTcsMzEuOTM4LDQ1Ljc3NiwyNDEuNjU3LDk4LjQ3MSwxNzguMzEyYzE5LjI2LTIzLjE2MywzNy44NjktNDIuNzQ4LDM3Ljg2OS00Mi43NDhjOS4yNDMsNi4xNCwyMC4zMDgsOS4yNzIsMzEuOTA4LDguMTQ3bDAuOTAxLTAuNzY1Yy0wLjI4LDIuODc2LTAuMTUyLDUuNjg5LDAuMzYxLDkuMDE5Yy0xMy41NzUsMTUuMTY3LTkuNTg2LDE3LjgzLTM2LjcyMywyMy40MTYgYy0yNy40NTksNS42NTktMTEuMzI4LDE1LjczNC0wLjc5NiwxOC4zNjdjMTIuNzY4LDMuMTkzLDQyLjMwNyw3LjcxNiw2Mi4yNjYtMjAuMjI0bC0wLjc5NiwzLjE4OGM1LjMxOSw0LjI2LDkuMDU0LDI3LjcxMSw4LjQyOCw0OC45NjljLTAuNjI2LDIxLjI1OS0xLjA0NCwzNS44NTQsMy4xNDcsNDcuMjU0YzQuMTkxLDExLjQsOC4zNjgsMzcuMDUsNDQuMDQyLDI5LjQwNmMyOS44MDktNi4zODgsNDUuMjU2LTIyLjk0Miw0Ny40MDUtNTAuNTU1IGMxLjUyNS0xOS42MzEsNC45NzYtMTYuNzI5LDUuMTk0LTM0LjI4bDIuNzY4LTguMzA5YzMuMTkyLTI2LjYxMSwwLjUwNy0zNS4xOTYsMTguODcyLTMxLjIwM2w0LjQ2MywwLjM5MmMxMy41MTcsMC42MTUsMzEuMjA4LTIuMTc0LDQxLjU5MS03YzIyLjM1OC0xMC4zNzYsMzUuNjE4LTI3LjcsMTMuNTczLTIzLjE0OHoiIHN0eWxlPSJmaWxsOiMzMzY3OTE7c3Ryb2tlOm5vbmUiLz4gPHBhdGggZD0iTTIxNS44NjYsMjg2LjQ4NGMtMS4zODUsNDkuNTE2LDAuMzQ4LDk5LjM3Nyw1LjE5MywxMTEuNDk1YzQuODQ4LDEyLjExOCwxNS4yMjMsMzUuNjg4LDUwLjksMjguMDQ1YzI5LjgwNi02LjM5LDQwLjY1MS0xOC43NTYsNDUuMzU3LTQ2LjA1MWMzLjQ2Ni0yMC4wODIsMTAuMTQ4LTc1Ljg1NCwxMS4wMDUtODcuMjgxIi8+IDxwYXRoIGQ9Ik0xNzMuMTA0LDM4LjI1NmMwLDAtMTYxLjUyMS02Ni4wMTYtMTU0LjAxMiw4NC4xMDljMS41OTcsMzEuOTM4LDQ1Ljc3OSwyNDEuNjY0LDk4LjQ3MywxNzguMzE2YzE5LjI1Ni0yMy4xNjYsMzYuNjcxLTQxLjMzNSwzNi42NzEtNDEuMzM1Ii8+IDxwYXRoIGQ9Ik0yNjAuMzQ5LDI2LjIwN2MtNS41OTEsMS43NTMsODkuODQ4LTM0Ljg4OSwxNDQuMDg3LDM0LjQxN2MxOS4xNTksMjQuNDg0LTMuMDQzLDEyNC41MTktNTYuMTUzLDIwMy4zMjkiLz4gPHBhdGggZD0iTTM0OC4yODIsMjYzLjk1M2MwLDAsMy40NjEsMTcuMDM2LDUzLjc2NCw2LjY1M2MyMi4wNC00LjU1Miw4Ljc3NiwxMi43NzQtMTMuNTc3LDIzLjE1NWMtMTguMzQ1LDguNTE0LTU5LjQ3NCwxMC42OTYtNjAuMTQ2LTEuMDY5Yy0xLjcyOS0zMC4zNTUsMjEuNjQ3LTIxLjEzMywxOS45Ni0yOC43MzljLTEuNTI1LTYuODUtMTEuOTc5LTEzLjU3My0xOC44OTQtMzAuMzM4IGMtNi4wMzctMTQuNjMzLTgyLjc5Ni0xMjYuODQ5LDIxLjI4Ny0xMTAuMTgzYzMuODEzLTAuNzg5LTI3LjE0Ni05OS4wMDItMTI0LjU1My0xMDAuNTk5Yy05Ny4zODUtMS41OTctOTQuMTksMTE5Ljc2Mi05NC4xOSwxMTkuNzYyIiBzdHlsZT0ic3Ryb2tlLWxpbmVqb2luOmJldmVsIi8+IDxwYXRoIGQ9Ik0xODguNjA0LDI3NC4zMzRjLTEzLjU3NywxNS4xNjYtOS41ODQsMTcuODI5LTM2LjcyMywyMy40MTdjLTI3LjQ1OSw1LjY2LTExLjMyNiwxNS43MzMtMC43OTcsMTguMzY1YzEyLjc2OCwzLjE5NSw0Mi4zMDcsNy43MTgsNjIuMjY2LTIwLjIyOWM2LjA3OC04LjUwOS0wLjAzNi0yMi4wODYtOC4zODUtMjUuNTQ3Yy00LjAzNC0xLjY3MS05LjQyOC0zLjc2NS0xNi4zNjEsMy45OTR6Ii8+IDxwYXRoIGQ9Ik0xODcuNzE1LDI3NC4wNjljLTEuMzY4LTguOTE3LDIuOTMtMTkuNTI4LDcuNTM2LTMxLjk0MmM2LjkyMi0xOC42MjYsMjIuODkzLTM3LjI1NSwxMC4xMTctOTYuMzM5Yy05LjUyMy00NC4wMjktNzMuMzk2LTkuMTYzLTczLjQzNi0zLjE5M2MtMC4wMzksNS45NjgsMi44ODksMzAuMjYtMS4wNjcsNTguNTQ4Yy01LjE2MiwzNi45MTMsMjMuNDg4LDY4LjEzMiw1Ni40NzksNjQuOTM4Ii8+IDxwYXRoIGQ9Ik0xNzIuNTE3LDE0MS43Yy0wLjI4OCwyLjAzOSwzLjczMyw3LjQ4LDguOTc2LDguMjA3YzUuMjM0LDAuNzMsOS43MTQtMy41MjIsOS45OTgtNS41NTljMC4yODQtMi4wMzktMy43MzItNC4yODUtOC45NzctNS4wMTVjLTUuMjM3LTAuNzMxLTkuNzE5LDAuMzMzLTkuOTk2LDIuMzY3eiIgc3R5bGU9ImZpbGw6I0ZGRkZGRjtzdHJva2Utd2lkdGg6NC4xNTU7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTMzMS45NDEsMTM3LjU0M2MwLjI4NCwyLjAzOS0zLjczMiw3LjQ4LTguOTc2LDguMjA3Yy01LjIzOCwwLjczLTkuNzE4LTMuNTIyLTEwLjAwNS01LjU1OWMtMC4yNzctMi4wMzksMy43NC00LjI4NSw4Ljk3OS01LjAxNWM1LjIzOS0wLjczLDkuNzE4LDAuMzMzLDEwLjAwMiwyLjM2OHoiIHN0eWxlPSJmaWxsOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjIuMDc3NTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNMzUwLjY3NiwxMjMuNDMyYzAuODYzLDE1Ljk5NC0zLjQ0NSwyNi44ODgtMy45ODgsNDMuOTE0Yy0wLjgwNCwyNC43NDgsMTEuNzk5LDUzLjA3NC03LjE5MSw4MS40MzUiLz4gPHBhdGggZD0iTTAsNjAuMjMyIiBzdHlsZT0ic3Ryb2tlLXdpZHRoOjMiLz4gPC9nPjwvc3ZnPgo8dGV4dCB4PSI3MTIiIHk9IjEwMyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMnB4Ij5TY2FsZXdheSBNYW5hZ2VkIERCPC90ZXh0Pgo8dGV4dCB4PSI3MTIiIHk9IjEyMiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPlBvc3RncmVTUUwgZW5naW5lPC90ZXh0Pgo8dGV4dCB4PSIyMDAiIHk9IjE1OCIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM5NGEzYjgiPkFUIERFUExPWU1FTlQgwrcgVklBIFRFTlNPUjk8L3RleHQ+CjxyZWN0IHg9IjI2IiB5PSIxNjQiIHdpZHRoPSIxMjgiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iOTAiIHk9IjE4NiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMnB4Ij5Zb3VyIHN0YWNrPC90ZXh0Pgo8dGV4dCB4PSI5MCIgeT0iMjAzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+QXVyb3JhIFBvc3RncmVTUUw8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIyMTgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5jbHVzdGVyPC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTk2IiB4Mj0iMzAwIiB5Mj0iMTk2IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLWRlcGxveS1zY2FsZXdheS1tYW5hZ2VkLWRiKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjIyNyIgeT0iMTg4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YiI+ZGVjbGFyYXRpb248L3RleHQ+CjxyZWN0IHg9IjMwNCIgeT0iMTY0IiB3aWR0aD0iMTgwIiBoZWlnaHQ9IjY2IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojZWNmZGY1O3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjM5NCIgeT0iMTkxIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC1zaXplOjEycHgiPlRlbnNvcjk8L3RleHQ+CiAgPHRleHQgeD0iMzk0IiB5PSIyMDgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPmNvbXBpbGVzIG9uY2U8L3RleHQ+CjxwYXRoIGQ9Ik00ODQsMTk2IEw3MTIsMTk2IEw3MTIsMTQ2IiBmaWxsPSJub25lIiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLWRlcGxveS1zY2FsZXdheS1tYW5hZ2VkLWRiKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjU5OCIgeT0iMTg4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YiI+cHJvdmlzaW9ucyB0aGUgaW5zdGFuY2U8L3RleHQ+Cjx0ZXh0IHg9IjU5OCIgeT0iMjIyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+bm8gUkRTIG1hbmFnZW1lbnQgQVBJIGF0IHJ1bnRpbWU8L3RleHQ+Cjwvc3ZnPg==)

![Database requests (SQL over pgwire) connect directly to Scaleway Managed DB. Tensor9 compiles the Aurora PostgreSQL cluster into Scaleway Managed DB at deployment; there is no management API at runtime.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgcGd3aXJlKSBjb25uZWN0IGRpcmVjdGx5IHRvIFNjYWxld2F5IE1hbmFnZWQgREIuIFRlbnNvcjkgY29tcGlsZXMgdGhlIEF1cm9yYSBQb3N0Z3JlU1FMIGNsdXN0ZXIgaW50byBTY2FsZXdheSBNYW5hZ2VkIERCIGF0IGRlcGxveW1lbnQ7IHRoZXJlIGlzIG5vIG1hbmFnZW1lbnQgQVBJIGF0IHJ1bnRpbWUuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojY2JkNWUxfTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImFoZC1kZXBsb3ktc2NhbGV3YXktbWFuYWdlZC1kYiIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNyIgbWFya2VySGVpZ2h0PSI3IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+PHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBzdHlsZT0iZmlsbDojNjQ3NDhiIi8+PC9tYXJrZXI+PC9kZWZzPgo8cmVjdCB4PSI4IiB5PSIzNCIgd2lkdGg9IjgyMCIgaGVpZ2h0PSIyMDYiIHJ4PSIxNiIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0cm9rZS1kYXNoYXJyYXk9IjUgNSIgc3R5bGU9ImZpbGw6IzBmMTcyYTtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSIyNiIgeT0iNTQiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiM2ZWU3YjciPk9OIFNDQUxFV0FZPC90ZXh0Pgo8c3ZnIHg9Ijc5MiIgeT0iMzYiIHdpZHRoPSIxNiIgaGVpZ2h0PSIxNiIgdmlld0JveD0iMCAwIDE2IDE2IiBwcmVzZXJ2ZUFzcGVjdFJhdGlvPSJ4TWlkWU1pZCBtZWV0IiBmaWxsPSJub25lIj48cGF0aCBkPSJNOC4zNyAzLjY2Nkg1LjczNkExLjE4MiAxLjE4MiAwIDAgMCA0LjY5IDQuNzl2My44MWMwIC4yNTcuMS40OC4yNjcuNjQ3LjE2Ni4xNjcuMzg5LjI2Ny42NDQuMjY3LjUgMCAuOTEyLS40MTIuOTEyLS45MTNWNi4xODRjMC0uMzc5LjMxMS0uNjkxLjY5LS42OTFoMS4xODljLjI1NSAwIC40NzgtLjEuNjQ0LS4yNjdhLjkyNy45MjcgMCAwIDAgLjI2Ny0uNjU4YzAtLjUwMS0uNDMzLS45MDItLjkzNC0uOTAyWk03LjE4MSAxMi4zNTdoMi42MzVhMS4xODEgMS4xODEgMCAwIDAgMS4wNDUtMS4xMjZ2LTMuODFhLjkuOSAwIDAgMC0uMjY3LS42NDcuODk3Ljg5NyAwIDAgMC0uNjQ1LS4yNjdjLS41IDAtLjkxMi40MTItLjkxMi45MTR2Mi40MTdjMCAuMzgtLjMxLjY5MS0uNjg5LjY5MWgtMS4xOWMtLjI1NSAwLS40NzcuMS0uNjQ0LjI2OGEuOTI3LjkyNyAwIDAgMC0uMjY3LjY1Ny45MzQuOTM0IDAgMCAwIC45MzQuOTAyWiIgZmlsbD0iI0JGOTVGOSIvPiA8cGF0aCBmaWxsLXJ1bGU9ImV2ZW5vZGQiIGNsaXAtcnVsZT0iZXZlbm9kZCIgZD0iTTQuMDI0IDBoNC43OTFhNS42ODMgNS42ODMgMCAwIDEgNS42OTIgNS43MTZ2Ny41ODhBMy4wMjcgMy4wMjcgMCAwIDEgMTEuNzUgMTZINi43MDNDMy41NTcgMTYgMSAxMy40MzcgMSAxMC4yODRWMy4wMzFBMy4wMyAzLjAzIDAgMCAxIDQuMDI0IDBabTguNjcgNS43MTZjMC0yLjE0LTEuNzQ0LTMuODg5LTMuODc5LTMuODg5aC00Ljc4Yy0uNjY3IDAtMS4yLjUzNS0xLjIgMS4yMDR2Ny4yNTNhMy44OCAzLjg4IDAgMCAwIDMuODggMy44ODloNC45NTdhMS4xOTMgMS4xOTMgMCAwIDAgMS4wMjMtLjk4VjUuNzE1WiIgZmlsbD0iI0JGOTVGOSIvPjwvc3ZnPgo8cmVjdCB4PSIyNiIgeT0iNzYiIHdpZHRoPSIxMjgiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iOTAiIHk9IjEwMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxM3B4Ij5Zb3VyIGFwcDwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjExNyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPlBvc3RncmVTUUwgZHJpdmVyPC90ZXh0Pgo8dGV4dCB4PSI5MCIgeT0iMTMyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjAwIDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPnVuY2hhbmdlZDwvdGV4dD4KPHRleHQgeD0iMjAwIiB5PSI4MiIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGI7IGZpbGw6IzZlZTdiNyI+REFUQUJBU0UgUkVRVUVTVFMgwrcgRElSRUNUIENPTk5FQ1RJT048L3RleHQ+CjxsaW5lIHgxPSIxNTQiIHkxPSIxMDgiIHgyPSI2MTAiIHkyPSIxMDgiIHN0cm9rZS13aWR0aD0iMi4yIiBtYXJrZXItZW5kPSJ1cmwoI2FoZC1kZXBsb3ktc2NhbGV3YXktbWFuYWdlZC1kYikiIHN0eWxlPSJzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSIzODIiIHk9IjEwMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZpbGw6IzZlZTdiNyI+U1FMIG92ZXIgcGd3aXJlPC90ZXh0Pgo8cmVjdCB4PSI2MTQiIHk9Ijc2IiB3aWR0aD0iMTk2IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+CjxzdmcgeD0iNzg2IiB5PSI1NiIgd2lkdGg9IjIwIiBoZWlnaHQ9IjIwIiB2aWV3Qm94PSIwIDAgNDMyLjA3MSA0NDUuMzgzIiBwcmVzZXJ2ZUFzcGVjdFJhdGlvPSJ4TWlkWU1pZCBtZWV0Ij48ZyBzdHlsZT0iZmlsbC1ydWxlOm5vbnplcm87Y2xpcC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLW1pdGVybGltaXQ6NCI+IDwvZz4gPGcgc3R5bGU9ImZpbGwtcnVsZTpub256ZXJvO2NsaXAtcnVsZTpub256ZXJvO2ZpbGw6bm9uZTtzdHJva2U6I0ZGRkZGRjtzdHJva2Utd2lkdGg6MTIuNDY1MTtzdHJva2UtbGluZWNhcDpyb3VuZDtzdHJva2UtbGluZWpvaW46cm91bmQ7c3Ryb2tlLW1pdGVybGltaXQ6NCI+IDxwYXRoIGQ9Ik0zMjMuMjA1LDMyNC4yMjdjMi44MzMtMjMuNjAxLDEuOTg0LTI3LjA2MiwxOS41NjMtMjMuMjM5bDQuNDYzLDAuMzkyYzEzLjUxNywwLjYxNSwzMS4xOTktMi4xNzQsNDEuNTg3LTdjMjIuMzYyLTEwLjM3NiwzNS42MjItMjcuNywxMy41NzItMjMuMTQ4Yy01MC4yOTcsMTAuMzc2LTUzLjc1NS02LjY1NS01My43NTUtNi42NTVjNTMuMTExLTc4LjgwMyw3NS4zMTMtMTc4LjgzNiw1Ni4xNDktMjAzLjMyMiBDMzUyLjUxNC01LjUzNCwyNjIuMDM2LDI2LjA0OSwyNjAuNTIyLDI2Ljg2OWwtMC40ODIsMC4wODljLTkuOTM4LTIuMDYyLTIxLjA2LTMuMjk0LTMzLjU1NC0zLjQ5NmMtMjIuNzYxLTAuMzc0LTQwLjAzMiw1Ljk2Ny01My4xMzMsMTUuOTA0YzAsMC0xNjEuNDA4LTY2LjQ5OC0xNTMuODk5LDgzLjYyOGMxLjU5NywzMS45MzYsNDUuNzc3LDI0MS42NTUsOTguNDcsMTc4LjMxIGMxOS4yNTktMjMuMTYzLDM3Ljg3MS00Mi43NDgsMzcuODcxLTQyLjc0OGM5LjI0Miw2LjE0LDIwLjMwNyw5LjI3MiwzMS45MTIsOC4xNDdsMC44OTctMC43NjVjLTAuMjgxLDIuODc2LTAuMTU3LDUuNjg5LDAuMzU5LDkuMDE5Yy0xMy41NzIsMTUuMTY3LTkuNTg0LDE3LjgzLTM2LjcyMywyMy40MTZjLTI3LjQ1Nyw1LjY1OS0xMS4zMjYsMTUuNzM0LTAuNzk3LDE4LjM2N2MxMi43NjgsMy4xOTMsNDIuMzA1LDcuNzE2LDYyLjI2OC0yMC4yMjQgbC0wLjc5NSwzLjE4OGM1LjMyNSw0LjI2LDQuOTY1LDMwLjYxOSw1LjcyLDQ5LjQ1MmMwLjc1NiwxOC44MzQsMi4wMTcsMzYuNDA5LDUuODU2LDQ2Ljc3MWMzLjgzOSwxMC4zNiw4LjM2OSwzNy4wNSw0NC4wMzYsMjkuNDA2YzI5LjgwOS02LjM4OCw1Mi42LTE1LjU4Miw1NC42NzctMTAxLjEwNyIgc3R5bGU9ImZpbGw6IzAwMDAwMDtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MzcuMzk1MztzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNNDAyLjM5NSwyNzEuMjNjLTUwLjMwMiwxMC4zNzYtNTMuNzYtNi42NTUtNTMuNzYtNi42NTVjNTMuMTExLTc4LjgwOCw3NS4zMTMtMTc4Ljg0Myw1Ni4xNTMtMjAzLjMyNmMtNTIuMjctNjYuNzg1LTE0Mi43NTItMzUuMi0xNDQuMjYyLTM0LjM4bC0wLjQ4NiwwLjA4N2MtOS45MzgtMi4wNjMtMjEuMDYtMy4yOTItMzMuNTYtMy40OTZjLTIyLjc2MS0wLjM3My00MC4wMjYsNS45NjctNTMuMTI3LDE1LjkwMiBjMCwwLTE2MS40MTEtNjYuNDk1LTE1My45MDQsODMuNjNjMS41OTcsMzEuOTM4LDQ1Ljc3NiwyNDEuNjU3LDk4LjQ3MSwxNzguMzEyYzE5LjI2LTIzLjE2MywzNy44NjktNDIuNzQ4LDM3Ljg2OS00Mi43NDhjOS4yNDMsNi4xNCwyMC4zMDgsOS4yNzIsMzEuOTA4LDguMTQ3bDAuOTAxLTAuNzY1Yy0wLjI4LDIuODc2LTAuMTUyLDUuNjg5LDAuMzYxLDkuMDE5Yy0xMy41NzUsMTUuMTY3LTkuNTg2LDE3LjgzLTM2LjcyMywyMy40MTYgYy0yNy40NTksNS42NTktMTEuMzI4LDE1LjczNC0wLjc5NiwxOC4zNjdjMTIuNzY4LDMuMTkzLDQyLjMwNyw3LjcxNiw2Mi4yNjYtMjAuMjI0bC0wLjc5NiwzLjE4OGM1LjMxOSw0LjI2LDkuMDU0LDI3LjcxMSw4LjQyOCw0OC45NjljLTAuNjI2LDIxLjI1OS0xLjA0NCwzNS44NTQsMy4xNDcsNDcuMjU0YzQuMTkxLDExLjQsOC4zNjgsMzcuMDUsNDQuMDQyLDI5LjQwNmMyOS44MDktNi4zODgsNDUuMjU2LTIyLjk0Miw0Ny40MDUtNTAuNTU1IGMxLjUyNS0xOS42MzEsNC45NzYtMTYuNzI5LDUuMTk0LTM0LjI4bDIuNzY4LTguMzA5YzMuMTkyLTI2LjYxMSwwLjUwNy0zNS4xOTYsMTguODcyLTMxLjIwM2w0LjQ2MywwLjM5MmMxMy41MTcsMC42MTUsMzEuMjA4LTIuMTc0LDQxLjU5MS03YzIyLjM1OC0xMC4zNzYsMzUuNjE4LTI3LjcsMTMuNTczLTIzLjE0OHoiIHN0eWxlPSJmaWxsOiMzMzY3OTE7c3Ryb2tlOm5vbmUiLz4gPHBhdGggZD0iTTIxNS44NjYsMjg2LjQ4NGMtMS4zODUsNDkuNTE2LDAuMzQ4LDk5LjM3Nyw1LjE5MywxMTEuNDk1YzQuODQ4LDEyLjExOCwxNS4yMjMsMzUuNjg4LDUwLjksMjguMDQ1YzI5LjgwNi02LjM5LDQwLjY1MS0xOC43NTYsNDUuMzU3LTQ2LjA1MWMzLjQ2Ni0yMC4wODIsMTAuMTQ4LTc1Ljg1NCwxMS4wMDUtODcuMjgxIi8+IDxwYXRoIGQ9Ik0xNzMuMTA0LDM4LjI1NmMwLDAtMTYxLjUyMS02Ni4wMTYtMTU0LjAxMiw4NC4xMDljMS41OTcsMzEuOTM4LDQ1Ljc3OSwyNDEuNjY0LDk4LjQ3MywxNzguMzE2YzE5LjI1Ni0yMy4xNjYsMzYuNjcxLTQxLjMzNSwzNi42NzEtNDEuMzM1Ii8+IDxwYXRoIGQ9Ik0yNjAuMzQ5LDI2LjIwN2MtNS41OTEsMS43NTMsODkuODQ4LTM0Ljg4OSwxNDQuMDg3LDM0LjQxN2MxOS4xNTksMjQuNDg0LTMuMDQzLDEyNC41MTktNTYuMTUzLDIwMy4zMjkiLz4gPHBhdGggZD0iTTM0OC4yODIsMjYzLjk1M2MwLDAsMy40NjEsMTcuMDM2LDUzLjc2NCw2LjY1M2MyMi4wNC00LjU1Miw4Ljc3NiwxMi43NzQtMTMuNTc3LDIzLjE1NWMtMTguMzQ1LDguNTE0LTU5LjQ3NCwxMC42OTYtNjAuMTQ2LTEuMDY5Yy0xLjcyOS0zMC4zNTUsMjEuNjQ3LTIxLjEzMywxOS45Ni0yOC43MzljLTEuNTI1LTYuODUtMTEuOTc5LTEzLjU3My0xOC44OTQtMzAuMzM4IGMtNi4wMzctMTQuNjMzLTgyLjc5Ni0xMjYuODQ5LDIxLjI4Ny0xMTAuMTgzYzMuODEzLTAuNzg5LTI3LjE0Ni05OS4wMDItMTI0LjU1My0xMDAuNTk5Yy05Ny4zODUtMS41OTctOTQuMTksMTE5Ljc2Mi05NC4xOSwxMTkuNzYyIiBzdHlsZT0ic3Ryb2tlLWxpbmVqb2luOmJldmVsIi8+IDxwYXRoIGQ9Ik0xODguNjA0LDI3NC4zMzRjLTEzLjU3NywxNS4xNjYtOS41ODQsMTcuODI5LTM2LjcyMywyMy40MTdjLTI3LjQ1OSw1LjY2LTExLjMyNiwxNS43MzMtMC43OTcsMTguMzY1YzEyLjc2OCwzLjE5NSw0Mi4zMDcsNy43MTgsNjIuMjY2LTIwLjIyOWM2LjA3OC04LjUwOS0wLjAzNi0yMi4wODYtOC4zODUtMjUuNTQ3Yy00LjAzNC0xLjY3MS05LjQyOC0zLjc2NS0xNi4zNjEsMy45OTR6Ii8+IDxwYXRoIGQ9Ik0xODcuNzE1LDI3NC4wNjljLTEuMzY4LTguOTE3LDIuOTMtMTkuNTI4LDcuNTM2LTMxLjk0MmM2LjkyMi0xOC42MjYsMjIuODkzLTM3LjI1NSwxMC4xMTctOTYuMzM5Yy05LjUyMy00NC4wMjktNzMuMzk2LTkuMTYzLTczLjQzNi0zLjE5M2MtMC4wMzksNS45NjgsMi44ODksMzAuMjYtMS4wNjcsNTguNTQ4Yy01LjE2MiwzNi45MTMsMjMuNDg4LDY4LjEzMiw1Ni40NzksNjQuOTM4Ii8+IDxwYXRoIGQ9Ik0xNzIuNTE3LDE0MS43Yy0wLjI4OCwyLjAzOSwzLjczMyw3LjQ4LDguOTc2LDguMjA3YzUuMjM0LDAuNzMsOS43MTQtMy41MjIsOS45OTgtNS41NTljMC4yODQtMi4wMzktMy43MzItNC4yODUtOC45NzctNS4wMTVjLTUuMjM3LTAuNzMxLTkuNzE5LDAuMzMzLTkuOTk2LDIuMzY3eiIgc3R5bGU9ImZpbGw6I0ZGRkZGRjtzdHJva2Utd2lkdGg6NC4xNTU7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTMzMS45NDEsMTM3LjU0M2MwLjI4NCwyLjAzOS0zLjczMiw3LjQ4LTguOTc2LDguMjA3Yy01LjIzOCwwLjczLTkuNzE4LTMuNTIyLTEwLjAwNS01LjU1OWMtMC4yNzctMi4wMzksMy43NC00LjI4NSw4Ljk3OS01LjAxNWM1LjIzOS0wLjczLDkuNzE4LDAuMzMzLDEwLjAwMiwyLjM2OHoiIHN0eWxlPSJmaWxsOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjIuMDc3NTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNMzUwLjY3NiwxMjMuNDMyYzAuODYzLDE1Ljk5NC0zLjQ0NSwyNi44ODgtMy45ODgsNDMuOTE0Yy0wLjgwNCwyNC43NDgsMTEuNzk5LDUzLjA3NC03LjE5MSw4MS40MzUiLz4gPHBhdGggZD0iTTAsNjAuMjMyIiBzdHlsZT0ic3Ryb2tlLXdpZHRoOjMiLz4gPC9nPjwvc3ZnPgo8dGV4dCB4PSI3MTIiIHk9IjEwMyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMnB4Ij5TY2FsZXdheSBNYW5hZ2VkIERCPC90ZXh0Pgo8dGV4dCB4PSI3MTIiIHk9IjEyMiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPlBvc3RncmVTUUwgZW5naW5lPC90ZXh0Pgo8dGV4dCB4PSIyMDAiIHk9IjE1OCIgc3R5bGU9ImZvbnQ6IDcwMCAxMHB4IEludGVyLCBzYW5zLXNlcmlmOyBsZXR0ZXItc3BhY2luZzogMS4zcHg7IGZpbGw6ICM2NDc0OGIiPkFUIERFUExPWU1FTlQgwrcgVklBIFRFTlNPUjk8L3RleHQ+CjxyZWN0IHg9IjI2IiB5PSIxNjQiIHdpZHRoPSIxMjgiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iOTAiIHk9IjE4NiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMnB4Ij5Zb3VyIHN0YWNrPC90ZXh0Pgo8dGV4dCB4PSI5MCIgeT0iMjAzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+QXVyb3JhIFBvc3RncmVTUUw8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIyMTgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5jbHVzdGVyPC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTk2IiB4Mj0iMzAwIiB5Mj0iMTk2IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLWRlcGxveS1zY2FsZXdheS1tYW5hZ2VkLWRiKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjIyNyIgeT0iMTg4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiOCI+ZGVjbGFyYXRpb248L3RleHQ+CjxyZWN0IHg9IjMwNCIgeT0iMTY0IiB3aWR0aD0iMTgwIiBoZWlnaHQ9IjY2IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS43IiBzdHlsZT0iZmlsbDojMDY0ZTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjM5NCIgeT0iMTkxIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC1zaXplOjEycHgiPlRlbnNvcjk8L3RleHQ+CiAgPHRleHQgeD0iMzk0IiB5PSIyMDgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPmNvbXBpbGVzIG9uY2U8L3RleHQ+CjxwYXRoIGQ9Ik00ODQsMTk2IEw3MTIsMTk2IEw3MTIsMTQ2IiBmaWxsPSJub25lIiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhkLWRlcGxveS1zY2FsZXdheS1tYW5hZ2VkLWRiKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjU5OCIgeT0iMTg4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiOCI+cHJvdmlzaW9ucyB0aGUgaW5zdGFuY2U8L3RleHQ+Cjx0ZXh0IHg9IjU5OCIgeT0iMjIyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+bm8gUkRTIG1hbmFnZW1lbnQgQVBJIGF0IHJ1bnRpbWU8L3RleHQ+Cjwvc3ZnPg==)

Queries reach the database directly; Tensor9 acts only when the product is deployed.

#### Database connections

Scaleway runs standard PostgreSQL, 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 cluster 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 AURORA POSTGRESQL DECLARATION setting becomes on ON SCALEWAY when Tensor9 deploys the product.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iNDAwIiB2aWV3Qm94PSIwIDAgODM2IDQwMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJXaGF0IGVhY2ggWU9VUiBBVVJPUkEgUE9TVEdSRVNRTCBERUNMQVJBVElPTiBzZXR0aW5nIGJlY29tZXMgb24gT04gU0NBTEVXQVkgd2hlbiBUZW5zb3I5IGRlcGxveXMgdGhlIHByb2R1Y3QuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojMzM0MTU1fTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImFodC15b3VyLWF1cm9yYS1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5IiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI2IiBtYXJrZXJIZWlnaHQ9IjYiIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM5NGEzYjgiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjE2IiB5PSIyMCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzNzIiIHJ4PSIxMiIgZmlsbD0ibm9uZSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSIzMiIgeT0iNDQiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4Ij5ZT1VSIEFVUk9SQSBQT1NUR1JFU1FMIERFQ0xBUkFUSU9OPC90ZXh0Pgo8dGV4dCB4PSIzODQiIHk9IjQ0IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzk0YTNiODsgZmlsbDojMDQ3ODU3Ij5PTiBTQ0FMRVdBWTwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjU4IiB3aWR0aD0iODA0IiBoZWlnaHQ9IjMwIiBzdHlsZT0iZmlsbDojZmZmZmZmIi8+Cjx0ZXh0IHg9IjMyIiB5PSI3NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+UHJpbWFyeSBpbnN0YW5jZSBjbGFzczwvdGV4dD4KPGxpbmUgeDE9IjMxOCIgeTE9IjczIiB4Mj0iMzY4IiB5Mj0iNzMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLWF1cm9yYS1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjM4NCIgeT0iNzciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiOyBmb250LXNpemU6MTJweDtmaWxsOiMwZjE3MmEiPkdlbmVyYWwtcHVycG9zZSBub2RlLCAyLTggdkNQVTwvdGV4dD4KPHJlY3QgeD0iNzA0IiB5PSI2NCIgd2lkdGg9IjEwMCIgaGVpZ2h0PSIxOCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojYjQ1MzA5Ii8+Cjx0ZXh0IHg9Ijc1NCIgeT0iNzciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiNiNDUzMDkiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSI4OCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzMCIgc3R5bGU9ImZpbGw6I2Y4ZmFmYyIvPgo8dGV4dCB4PSIzMiIgeT0iMTA3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjEycHg7ZmlsbDojMGYxNzJhIj5Ud28gb3IgbW9yZSBjbHVzdGVyIGluc3RhbmNlczwvdGV4dD4KPGxpbmUgeDE9IjMxOCIgeTE9IjEwMyIgeDI9IjM2OCIgeTI9IjEwMyIgc3Ryb2tlLXdpZHRoPSIxLjYiIG1hcmtlci1lbmQ9InVybCgjYWh0LXlvdXItYXVyb3JhLXBvc3RncmVzcWwtZGVjbGFyYXRpb24tb24tc2NhbGV3YXkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iMzg0IiB5PSIxMDciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiOyBmb250LXNpemU6MTJweDtmaWxsOiMwZjE3MmEiPkhvdCBzdGFuZGJ5IGluIHRoZSBzYW1lIGRhdGEgY2VudGVyPC90ZXh0Pgo8cmVjdCB4PSI3MDQiIHk9Ijk0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNiNDUzMDkiLz4KPHRleHQgeD0iNzU0IiB5PSIxMDciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiNiNDUzMDkiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIxMTgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiNmZmZmZmYiLz4KPHRleHQgeD0iMzIiIHk9IjEzNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+UmVhZGVyIGVuZHBvaW50PC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMTMzIiB4Mj0iMzY4IiB5Mj0iMTMzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1hdXJvcmEtcG9zdGdyZXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8dGV4dCB4PSIzODQiIHk9IjEzNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+SW5zdGFuY2UgZW5kcG9pbnQ7IGFkZCByZWFkIHJlcGxpY2FzIHNlcGFyYXRlbHk8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMTI0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNiNDUzMDkiLz4KPHRleHQgeD0iNzU0IiB5PSIxMzciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiNiNDUzMDkiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIxNDgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiNmOGZhZmMiLz4KPHRleHQgeD0iMzIiIHk9IjE2NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+QWxsb2NhdGVkIHN0b3JhZ2U8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIxNjMiIHgyPSIzNjgiIHkyPSIxNjMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLWF1cm9yYS1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjM4NCIgeT0iMTY3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjEycHg7ZmlsbDojMGYxNzJhIj5CbG9jayBzdG9yYWdlIHZvbHVtZSwgNS0xMCwwMDAgR0I8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMTU0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iNzU0IiB5PSIxNjciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiMwNDc4NTciPm1hcHBlZDwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjE3OCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzMCIgc3R5bGU9ImZpbGw6I2ZmZmZmZiIvPgo8dGV4dCB4PSIzMiIgeT0iMTk3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjEycHg7ZmlsbDojMGYxNzJhIj5Qb3N0Z3JlU1FMIG1ham9yIHZlcnNpb248L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIxOTMiIHgyPSIzNjgiIHkyPSIxOTMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLWF1cm9yYS1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjM4NCIgeT0iMTk3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjEycHg7ZmlsbDojMGYxNzJhIj5Qb3N0Z3JlU1FMIDE0LTE3IChvbGRlciBtYWpvcnMgbW92ZSB0byAxNyk8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMTg0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNiNDUzMDkiLz4KPHRleHQgeD0iNzU0IiB5PSIxOTciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiNiNDUzMDkiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIyMDgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiNmOGZhZmMiLz4KPHRleHQgeD0iMzIiIHk9IjIyNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+TWFzdGVyIHVzZXJuYW1lIGFuZCBwYXNzd29yZDwvdGV4dD4KPGxpbmUgeDE9IjMxOCIgeTE9IjIyMyIgeDI9IjM2OCIgeTI9IjIyMyIgc3Ryb2tlLXdpZHRoPSIxLjYiIG1hcmtlci1lbmQ9InVybCgjYWh0LXlvdXItYXVyb3JhLXBvc3RncmVzcWwtZGVjbGFyYXRpb24tb24tc2NhbGV3YXkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iMzg0IiB5PSIyMjciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiOyBmb250LXNpemU6MTJweDtmaWxsOiMwZjE3MmEiPlByb3Zpc2lvbmVkIGFkbWluIHVzZXIsIHBhc3N3b3JkIHZpYSB2YXJpYWJsZTwvdGV4dD4KPHJlY3QgeD0iNzA0IiB5PSIyMTQiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTgiIHJ4PSI5IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2I0NTMwOSIvPgo8dGV4dCB4PSI3NTQiIHk9IjIyNyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZpbGw6I2I0NTMwOSI+Y2hhbmdlZDwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjIzOCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzMCIgc3R5bGU9ImZpbGw6I2ZmZmZmZiIvPgo8dGV4dCB4PSIzMiIgeT0iMjU3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjEycHg7ZmlsbDojMGYxNzJhIj5JQU0gZGF0YWJhc2UgYXV0aGVudGljYXRpb248L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIyNTMiIHgyPSIzNjgiIHkyPSIyNTMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLWF1cm9yYS1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjM4NCIgeT0iMjU3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjEycHg7ZmlsbDojMGYxNzJhIj5ObyBlcXVpdmFsZW50OyBjbGllbnRzIGNhbm5vdCBjb25uZWN0PC90ZXh0Pgo8cmVjdCB4PSI3MDQiIHk9IjI0NCIgd2lkdGg9IjEwMCIgaGVpZ2h0PSIxOCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojZGMyNjI2Ii8+Cjx0ZXh0IHg9Ijc1NCIgeT0iMjU3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YjsgZmlsbDojZGMyNjI2Ij5vbWl0dGVkPC90ZXh0Pgo8cmVjdCB4PSIxNiIgeT0iMjY4IiB3aWR0aD0iODA0IiBoZWlnaHQ9IjMwIiBzdHlsZT0iZmlsbDojZjhmYWZjIi8+Cjx0ZXh0IHg9IjMyIiB5PSIyODciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiOyBmb250LXNpemU6MTJweDtmaWxsOiMwZjE3MmEiPkJhY2t1cCByZXRlbnRpb24gYW5kIHdpbmRvdzwvdGV4dD4KPGxpbmUgeDE9IjMxOCIgeTE9IjI4MyIgeDI9IjM2OCIgeTI9IjI4MyIgc3Ryb2tlLXdpZHRoPSIxLjYiIG1hcmtlci1lbmQ9InVybCgjYWh0LXlvdXItYXVyb3JhLXBvc3RncmVzcWwtZGVjbGFyYXRpb24tb24tc2NhbGV3YXkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iMzg0IiB5PSIyODciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiOyBmb250LXNpemU6MTJweDtmaWxsOiMwZjE3MmEiPlNjYWxld2F5J3Mgb3duIGJhY2t1cCBzY2hlZHVsZTwvdGV4dD4KPHJlY3QgeD0iNzA0IiB5PSIyNzQiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTgiIHJ4PSI5IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2I0NTMwOSIvPgo8dGV4dCB4PSI3NTQiIHk9IjI4NyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZpbGw6I2I0NTMwOSI+Y2hhbmdlZDwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjI5OCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzMCIgc3R5bGU9ImZpbGw6I2ZmZmZmZiIvPgo8dGV4dCB4PSIzMiIgeT0iMzE3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjEycHg7ZmlsbDojMGYxNzJhIj5DdXN0b21lci1tYW5hZ2VkIEtNUyBrZXk8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIzMTMiIHgyPSIzNjgiIHkyPSIzMTMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLWF1cm9yYS1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjM4NCIgeT0iMzE3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjEycHg7ZmlsbDojMGYxNzJhIj5TY2FsZXdheS1tYW5hZ2VkIGVuY3J5cHRpb24gYXQgcmVzdDwvdGV4dD4KPHJlY3QgeD0iNzA0IiB5PSIzMDQiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTgiIHJ4PSI5IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2I0NTMwOSIvPgo8dGV4dCB4PSI3NTQiIHk9IjMxNyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZpbGw6I2I0NTMwOSI+Y2hhbmdlZDwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjMyOCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzMCIgc3R5bGU9ImZpbGw6I2Y4ZmFmYyIvPgo8dGV4dCB4PSIzMiIgeT0iMzQ3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjEycHg7ZmlsbDojMGYxNzJhIj5QYXJhbWV0ZXIgYW5kIG9wdGlvbiBncm91cHM8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIzNDMiIHgyPSIzNjgiIHkyPSIzNDMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLWF1cm9yYS1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjM4NCIgeT0iMzQ3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjEycHg7ZmlsbDojMGYxNzJhIj5SZW1vdmVkOyBzZXQgZW5naW5lIHNldHRpbmdzIG9uIHRoZSBpbnN0YW5jZTwvdGV4dD4KPHJlY3QgeD0iNzA0IiB5PSIzMzQiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTgiIHJ4PSI5IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2RjMjYyNiIvPgo8dGV4dCB4PSI3NTQiIHk9IjM0NyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZpbGw6I2RjMjYyNiI+b21pdHRlZDwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjM1OCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzMCIgc3R5bGU9ImZpbGw6I2ZmZmZmZiIvPgo8dGV4dCB4PSIzMiIgeT0iMzc3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjEycHg7ZmlsbDojMGYxNzJhIj5TZXJ2ZXJsZXNzIHYyLCBnbG9iYWwgZGF0YWJhc2UsIGZhc3QgY2xvbmVzPC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMzczIiB4Mj0iMzY4IiB5Mj0iMzczIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1hdXJvcmEtcG9zdGdyZXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8dGV4dCB4PSIzODQiIHk9IjM3NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+Tm8gZXF1aXZhbGVudDwvdGV4dD4KPHJlY3QgeD0iNzA0IiB5PSIzNjQiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTgiIHJ4PSI5IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2RjMjYyNiIvPgo8dGV4dCB4PSI3NTQiIHk9IjM3NyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZpbGw6I2RjMjYyNiI+b21pdHRlZDwvdGV4dD4KPC9zdmc+)

![What each YOUR AURORA POSTGRESQL DECLARATION setting becomes on ON SCALEWAY when Tensor9 deploys the product.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iNDAwIiB2aWV3Qm94PSIwIDAgODM2IDQwMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJXaGF0IGVhY2ggWU9VUiBBVVJPUkEgUE9TVEdSRVNRTCBERUNMQVJBVElPTiBzZXR0aW5nIGJlY29tZXMgb24gT04gU0NBTEVXQVkgd2hlbiBUZW5zb3I5IGRlcGxveXMgdGhlIHByb2R1Y3QuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojY2JkNWUxfTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImFodC15b3VyLWF1cm9yYS1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5IiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI2IiBtYXJrZXJIZWlnaHQ9IjYiIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM2NDc0OGIiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjE2IiB5PSIyMCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzNzIiIHJ4PSIxMiIgZmlsbD0ibm9uZSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSIzMiIgeT0iNDQiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiIj5ZT1VSIEFVUk9SQSBQT1NUR1JFU1FMIERFQ0xBUkFUSU9OPC90ZXh0Pgo8dGV4dCB4PSIzODQiIHk9IjQ0IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzY0NzQ4YjsgZmlsbDojNmVlN2I3Ij5PTiBTQ0FMRVdBWTwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjU4IiB3aWR0aD0iODA0IiBoZWlnaHQ9IjMwIiBzdHlsZT0iZmlsbDojMWUyOTNiIi8+Cjx0ZXh0IHg9IjMyIiB5PSI3NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+UHJpbWFyeSBpbnN0YW5jZSBjbGFzczwvdGV4dD4KPGxpbmUgeDE9IjMxOCIgeTE9IjczIiB4Mj0iMzY4IiB5Mj0iNzMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLWF1cm9yYS1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjM4NCIgeT0iNzciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4OyBmb250LXNpemU6MTJweDtmaWxsOiNmMWY1ZjkiPkdlbmVyYWwtcHVycG9zZSBub2RlLCAyLTggdkNQVTwvdGV4dD4KPHJlY3QgeD0iNzA0IiB5PSI2NCIgd2lkdGg9IjEwMCIgaGVpZ2h0PSIxOCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojZmJiZjI0Ii8+Cjx0ZXh0IHg9Ijc1NCIgeT0iNzciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiNmYmJmMjQiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSI4OCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzMCIgc3R5bGU9ImZpbGw6IzBmMTcyYSIvPgo8dGV4dCB4PSIzMiIgeT0iMTA3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjEycHg7ZmlsbDojZjFmNWY5Ij5Ud28gb3IgbW9yZSBjbHVzdGVyIGluc3RhbmNlczwvdGV4dD4KPGxpbmUgeDE9IjMxOCIgeTE9IjEwMyIgeDI9IjM2OCIgeTI9IjEwMyIgc3Ryb2tlLXdpZHRoPSIxLjYiIG1hcmtlci1lbmQ9InVybCgjYWh0LXlvdXItYXVyb3JhLXBvc3RncmVzcWwtZGVjbGFyYXRpb24tb24tc2NhbGV3YXkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iMzg0IiB5PSIxMDciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4OyBmb250LXNpemU6MTJweDtmaWxsOiNmMWY1ZjkiPkhvdCBzdGFuZGJ5IGluIHRoZSBzYW1lIGRhdGEgY2VudGVyPC90ZXh0Pgo8cmVjdCB4PSI3MDQiIHk9Ijk0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiNmYmJmMjQiLz4KPHRleHQgeD0iNzU0IiB5PSIxMDciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiNmYmJmMjQiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIxMTgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiMxZTI5M2IiLz4KPHRleHQgeD0iMzIiIHk9IjEzNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+UmVhZGVyIGVuZHBvaW50PC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMTMzIiB4Mj0iMzY4IiB5Mj0iMTMzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1hdXJvcmEtcG9zdGdyZXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8dGV4dCB4PSIzODQiIHk9IjEzNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+SW5zdGFuY2UgZW5kcG9pbnQ7IGFkZCByZWFkIHJlcGxpY2FzIHNlcGFyYXRlbHk8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMTI0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiNmYmJmMjQiLz4KPHRleHQgeD0iNzU0IiB5PSIxMzciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiNmYmJmMjQiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIxNDgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiMwZjE3MmEiLz4KPHRleHQgeD0iMzIiIHk9IjE2NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+QWxsb2NhdGVkIHN0b3JhZ2U8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIxNjMiIHgyPSIzNjgiIHkyPSIxNjMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLWF1cm9yYS1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjM4NCIgeT0iMTY3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjEycHg7ZmlsbDojZjFmNWY5Ij5CbG9jayBzdG9yYWdlIHZvbHVtZSwgNS0xMCwwMDAgR0I8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMTU0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iNzU0IiB5PSIxNjciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiM2ZWU3YjciPm1hcHBlZDwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjE3OCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzMCIgc3R5bGU9ImZpbGw6IzFlMjkzYiIvPgo8dGV4dCB4PSIzMiIgeT0iMTk3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjEycHg7ZmlsbDojZjFmNWY5Ij5Qb3N0Z3JlU1FMIG1ham9yIHZlcnNpb248L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIxOTMiIHgyPSIzNjgiIHkyPSIxOTMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLWF1cm9yYS1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjM4NCIgeT0iMTk3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjEycHg7ZmlsbDojZjFmNWY5Ij5Qb3N0Z3JlU1FMIDE0LTE3IChvbGRlciBtYWpvcnMgbW92ZSB0byAxNyk8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMTg0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiNmYmJmMjQiLz4KPHRleHQgeD0iNzU0IiB5PSIxOTciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiNmYmJmMjQiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIyMDgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiMwZjE3MmEiLz4KPHRleHQgeD0iMzIiIHk9IjIyNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+TWFzdGVyIHVzZXJuYW1lIGFuZCBwYXNzd29yZDwvdGV4dD4KPGxpbmUgeDE9IjMxOCIgeTE9IjIyMyIgeDI9IjM2OCIgeTI9IjIyMyIgc3Ryb2tlLXdpZHRoPSIxLjYiIG1hcmtlci1lbmQ9InVybCgjYWh0LXlvdXItYXVyb3JhLXBvc3RncmVzcWwtZGVjbGFyYXRpb24tb24tc2NhbGV3YXkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iMzg0IiB5PSIyMjciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4OyBmb250LXNpemU6MTJweDtmaWxsOiNmMWY1ZjkiPlByb3Zpc2lvbmVkIGFkbWluIHVzZXIsIHBhc3N3b3JkIHZpYSB2YXJpYWJsZTwvdGV4dD4KPHJlY3QgeD0iNzA0IiB5PSIyMTQiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTgiIHJ4PSI5IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6I2ZiYmYyNCIvPgo8dGV4dCB4PSI3NTQiIHk9IjIyNyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZpbGw6I2ZiYmYyNCI+Y2hhbmdlZDwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjIzOCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzMCIgc3R5bGU9ImZpbGw6IzFlMjkzYiIvPgo8dGV4dCB4PSIzMiIgeT0iMjU3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjEycHg7ZmlsbDojZjFmNWY5Ij5JQU0gZGF0YWJhc2UgYXV0aGVudGljYXRpb248L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIyNTMiIHgyPSIzNjgiIHkyPSIyNTMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLWF1cm9yYS1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjM4NCIgeT0iMjU3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjEycHg7ZmlsbDojZjFmNWY5Ij5ObyBlcXVpdmFsZW50OyBjbGllbnRzIGNhbm5vdCBjb25uZWN0PC90ZXh0Pgo8cmVjdCB4PSI3MDQiIHk9IjI0NCIgd2lkdGg9IjEwMCIgaGVpZ2h0PSIxOCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojZjg3MTcxIi8+Cjx0ZXh0IHg9Ijc1NCIgeT0iMjU3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiODsgZmlsbDojZjg3MTcxIj5vbWl0dGVkPC90ZXh0Pgo8cmVjdCB4PSIxNiIgeT0iMjY4IiB3aWR0aD0iODA0IiBoZWlnaHQ9IjMwIiBzdHlsZT0iZmlsbDojMGYxNzJhIi8+Cjx0ZXh0IHg9IjMyIiB5PSIyODciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4OyBmb250LXNpemU6MTJweDtmaWxsOiNmMWY1ZjkiPkJhY2t1cCByZXRlbnRpb24gYW5kIHdpbmRvdzwvdGV4dD4KPGxpbmUgeDE9IjMxOCIgeTE9IjI4MyIgeDI9IjM2OCIgeTI9IjI4MyIgc3Ryb2tlLXdpZHRoPSIxLjYiIG1hcmtlci1lbmQ9InVybCgjYWh0LXlvdXItYXVyb3JhLXBvc3RncmVzcWwtZGVjbGFyYXRpb24tb24tc2NhbGV3YXkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iMzg0IiB5PSIyODciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4OyBmb250LXNpemU6MTJweDtmaWxsOiNmMWY1ZjkiPlNjYWxld2F5J3Mgb3duIGJhY2t1cCBzY2hlZHVsZTwvdGV4dD4KPHJlY3QgeD0iNzA0IiB5PSIyNzQiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTgiIHJ4PSI5IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6I2ZiYmYyNCIvPgo8dGV4dCB4PSI3NTQiIHk9IjI4NyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZpbGw6I2ZiYmYyNCI+Y2hhbmdlZDwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjI5OCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzMCIgc3R5bGU9ImZpbGw6IzFlMjkzYiIvPgo8dGV4dCB4PSIzMiIgeT0iMzE3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjEycHg7ZmlsbDojZjFmNWY5Ij5DdXN0b21lci1tYW5hZ2VkIEtNUyBrZXk8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIzMTMiIHgyPSIzNjgiIHkyPSIzMTMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLWF1cm9yYS1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjM4NCIgeT0iMzE3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjEycHg7ZmlsbDojZjFmNWY5Ij5TY2FsZXdheS1tYW5hZ2VkIGVuY3J5cHRpb24gYXQgcmVzdDwvdGV4dD4KPHJlY3QgeD0iNzA0IiB5PSIzMDQiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTgiIHJ4PSI5IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6I2ZiYmYyNCIvPgo8dGV4dCB4PSI3NTQiIHk9IjMxNyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZpbGw6I2ZiYmYyNCI+Y2hhbmdlZDwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjMyOCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzMCIgc3R5bGU9ImZpbGw6IzBmMTcyYSIvPgo8dGV4dCB4PSIzMiIgeT0iMzQ3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjEycHg7ZmlsbDojZjFmNWY5Ij5QYXJhbWV0ZXIgYW5kIG9wdGlvbiBncm91cHM8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIzNDMiIHgyPSIzNjgiIHkyPSIzNDMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLWF1cm9yYS1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjM4NCIgeT0iMzQ3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjEycHg7ZmlsbDojZjFmNWY5Ij5SZW1vdmVkOyBzZXQgZW5naW5lIHNldHRpbmdzIG9uIHRoZSBpbnN0YW5jZTwvdGV4dD4KPHJlY3QgeD0iNzA0IiB5PSIzMzQiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTgiIHJ4PSI5IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6I2Y4NzE3MSIvPgo8dGV4dCB4PSI3NTQiIHk9IjM0NyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZpbGw6I2Y4NzE3MSI+b21pdHRlZDwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjM1OCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzMCIgc3R5bGU9ImZpbGw6IzFlMjkzYiIvPgo8dGV4dCB4PSIzMiIgeT0iMzc3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjEycHg7ZmlsbDojZjFmNWY5Ij5TZXJ2ZXJsZXNzIHYyLCBnbG9iYWwgZGF0YWJhc2UsIGZhc3QgY2xvbmVzPC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMzczIiB4Mj0iMzY4IiB5Mj0iMzczIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1hdXJvcmEtcG9zdGdyZXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8dGV4dCB4PSIzODQiIHk9IjM3NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+Tm8gZXF1aXZhbGVudDwvdGV4dD4KPHJlY3QgeD0iNzA0IiB5PSIzNjQiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTgiIHJ4PSI5IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6I2Y4NzE3MSIvPgo8dGV4dCB4PSI3NTQiIHk9IjM3NyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZpbGw6I2Y4NzE3MSI+b21pdHRlZDwvdGV4dD4KPC9zdmc+)

Tensor9 applies this translation once, when the product is deployed.

#### Limitations

Where Aurora PostgreSQL and Scaleway differ

* **Aurora-specific features are not supported.** Serverless v2 scaling, global databases, fast clones, promotion tiers and I/O-Optimized storage have no equivalent on this backend. Aurora SQL functions for S3, Lambda and machine learning return an error.
* **Readers behave differently: there is no reader endpoint.** Reader traffic goes to the instance endpoint. Scaleway read replicas are separate, asynchronously replicated resources that you add deliberately; they are not created from the cluster's reader instances.
* **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.

##### Aurora PostgreSQL · Primary allocated compute

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Primary allocated compute. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: fr-par; currency: USD.

![Aurora PostgreSQL · 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/0d46f3d3ba025155bd07598402bda8183d5cc045f4e6b1c6fbc5eaa4d496fb1a-light.svg)

![Aurora PostgreSQL · 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/10f9c92768835b686272e9d8edda14912ed8d7a5e37b30ad3da9f2020f3936d4-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) | Aurora PostgreSQL | Target scenario | Scaleway Managed Database for PostgreSQL | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Scaleway Managed Database for PostgreSQL (one copy) | 101.10 | 101.10 |
| 0 | 0.00 | Scaleway Managed Database for PostgreSQL (two copies) | 154.69 | 154.69 |
| 1,460 | 211.70 | Scaleway Managed Database for PostgreSQL (one copy) | 101.10 | -110.60 |
| 1,460 | 211.70 | Scaleway Managed Database for PostgreSQL (two copies) | 154.69 | -57.01 |
| 2,920 | 423.40 | Scaleway Managed Database for PostgreSQL (one copy) | 191.08 | -232.32 |
| 2,920 | 423.40 | Scaleway Managed Database for PostgreSQL (two copies) | 292.35 | -131.05 |
| 5,840 | 846.80 | Scaleway Managed Database for PostgreSQL (one copy) | 371.03 | -475.77 |
| 5,840 | 846.80 | Scaleway Managed Database for PostgreSQL (two copies) | 567.68 | -279.12 |
| 11,680 | 1,693.60 | Scaleway Managed Database for PostgreSQL (one copy) | 730.94 | -962.66 |
| 11,680 | 1,693.60 | Scaleway Managed Database for PostgreSQL (two copies) | 1,118.33 | -575.27 |
| 23,360 | 3,387.20 | Scaleway Managed Database for PostgreSQL (one copy) | 1,450.74 | -1,936.46 |
| 23,360 | 3,387.20 | Scaleway Managed Database for PostgreSQL (two copies) | 2,219.64 | -1,167.56 |
| 46,720 | 6,774.40 | Scaleway Managed Database for PostgreSQL (one copy) | Unpriced | Unavailable |
| 46,720 | 6,774.40 | Scaleway Managed Database for PostgreSQL (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 PostgreSQL (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| Scaleway Managed Database for PostgreSQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| Scaleway Managed Database for PostgreSQL (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (one copy) | Origin list price · Database reads | 0 | USD/operations |
| Scaleway Managed Database for PostgreSQL (one copy) | Origin list price · Database writes | 0 | USD/operations |
| Scaleway Managed Database for PostgreSQL (one copy) | Target CPU / source CPU | 1 | multiplier |
| Scaleway Managed Database for PostgreSQL (one copy) | Target RAM / source RAM | 1 | multiplier |
| Scaleway Managed Database for PostgreSQL (one copy) | Target disk / source disk | 1 | multiplier |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · read | 0 | USD/read |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · write | 0 | USD/write |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| Scaleway Managed Database for PostgreSQL (one copy) | Target list price · GiB-month | 0.111266 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · network GiB | 0 | USD/network GiB |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Scaleway Managed Database for PostgreSQL (one copy) | Target list price · vCPU-hour | 0.0367275 | USD/vCPU-hour |
| Scaleway Managed Database for PostgreSQL (one copy) | Target list price · GiB-hour | 0.006225 | USD/GiB-hour |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · input token | 0 | USD/input token |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · output token | 0 | USD/output token |
| Scaleway Managed Database for PostgreSQL (one copy) | Target monthly base charge | 0 | USD/month |
| Scaleway Managed Database for PostgreSQL (one copy) | Target service minimum | 89.9762 | USD/month |
| Scaleway Managed Database for PostgreSQL (one copy) | Minimum primary CPU | 2 | vCPU |
| Scaleway Managed Database for PostgreSQL (one copy) | Minimum primary RAM | 8 | GiB |
| Scaleway Managed Database for PostgreSQL (one copy) | Minimum primary disk | 100 | GiB |
| Scaleway Managed Database for PostgreSQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Scaleway Managed Database for PostgreSQL (one copy) | Allocated share of provisioned cost | 1 | fraction |
| Scaleway Managed Database for PostgreSQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Scaleway Managed Database for PostgreSQL (one copy) | Planning peak / mean work | 2 | multiplier |
| Scaleway Managed Database for PostgreSQL (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| Scaleway Managed Database for PostgreSQL (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| Scaleway Managed Database for PostgreSQL (one copy) | Planning disk utilization | 0.8 | fraction |
| Scaleway Managed Database for PostgreSQL (one copy) | Maintenance and log disk reserve | 20 | GiB |
| Scaleway Managed Database for PostgreSQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Scaleway Managed Database for PostgreSQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Scaleway Managed Database for PostgreSQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Scaleway Managed Database for PostgreSQL (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| Scaleway Managed Database for PostgreSQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| Scaleway Managed Database for PostgreSQL (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (two copies) | Origin list price · Database reads | 0 | USD/operations |
| Scaleway Managed Database for PostgreSQL (two copies) | Origin list price · Database writes | 0 | USD/operations |
| Scaleway Managed Database for PostgreSQL (two copies) | Target CPU / source CPU | 1 | multiplier |
| Scaleway Managed Database for PostgreSQL (two copies) | Target RAM / source RAM | 1 | multiplier |
| Scaleway Managed Database for PostgreSQL (two copies) | Target disk / source disk | 1 | multiplier |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · read | 0 | USD/read |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · write | 0 | USD/write |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| Scaleway Managed Database for PostgreSQL (two copies) | Target list price · GiB-month | 0.111266 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · network GiB | 0 | USD/network GiB |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Scaleway Managed Database for PostgreSQL (two copies) | Target list price · vCPU-hour | 0.0367275 | USD/vCPU-hour |
| Scaleway Managed Database for PostgreSQL (two copies) | Target list price · GiB-hour | 0.006225 | USD/GiB-hour |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · input token | 0 | USD/input token |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · output token | 0 | USD/output token |
| Scaleway Managed Database for PostgreSQL (two copies) | Target monthly base charge | 0 | USD/month |
| Scaleway Managed Database for PostgreSQL (two copies) | Target service minimum | 89.9762 | USD/month |
| Scaleway Managed Database for PostgreSQL (two copies) | Minimum primary CPU | 2 | vCPU |
| Scaleway Managed Database for PostgreSQL (two copies) | Minimum primary RAM | 8 | GiB |
| Scaleway Managed Database for PostgreSQL (two copies) | Minimum primary disk | 100 | GiB |
| Scaleway Managed Database for PostgreSQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Scaleway Managed Database for PostgreSQL (two copies) | Allocated share of provisioned cost | 1 | fraction |
| Scaleway Managed Database for PostgreSQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Scaleway Managed Database for PostgreSQL (two copies) | Planning peak / mean work | 2 | multiplier |
| Scaleway Managed Database for PostgreSQL (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| Scaleway Managed Database for PostgreSQL (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| Scaleway Managed Database for PostgreSQL (two copies) | Planning disk utilization | 0.8 | fraction |
| Scaleway Managed Database for PostgreSQL (two copies) | Maintenance and log disk reserve | 20 | GiB |
| Scaleway Managed Database for PostgreSQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Scaleway Managed Database for PostgreSQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Scaleway Managed Database for PostgreSQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* Scaleway Managed Database for PostgreSQL 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-9818fc9ac977d4349d19fe5ce8eb48812af182c2` / `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/).

##### Aurora PostgreSQL · Stored data

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: fr-par; currency: USD.

![Aurora PostgreSQL · 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/7c834fe75eeb9dd9855235a370bd41464ba849c7108582deb8a31f03b388d328-light.svg)

![Aurora PostgreSQL · 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/f3e1c43db7ac9d9c5596fc486dbd01a8f2ce23461fa0eb317c60c88566d53712-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) | Aurora PostgreSQL | Target scenario | Scaleway Managed Database for PostgreSQL | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Scaleway Managed Database for PostgreSQL (one copy) | 101.10 | 101.10 |
| 0 | 0.00 | Scaleway Managed Database for PostgreSQL (two copies) | 154.69 | 154.69 |
| 10 | 1.00 | Scaleway Managed Database for PostgreSQL (one copy) | 101.10 | 100.10 |
| 10 | 1.00 | Scaleway Managed Database for PostgreSQL (two copies) | 154.69 | 153.69 |
| 100 | 10.00 | Scaleway Managed Database for PostgreSQL (one copy) | 106.67 | 96.67 |
| 100 | 10.00 | Scaleway Managed Database for PostgreSQL (two copies) | 163.20 | 153.20 |
| 1,000 | 100.00 | Scaleway Managed Database for PostgreSQL (one copy) | 231.84 | 131.84 |
| 1,000 | 100.00 | Scaleway Managed Database for PostgreSQL (two copies) | 354.71 | 254.71 |
| 10,000 | 1,000.00 | Scaleway Managed Database for PostgreSQL (one copy) | 1,483.58 | 483.58 |
| 10,000 | 1,000.00 | Scaleway Managed Database for PostgreSQL (two copies) | 2,269.87 | 1,269.87 |
| 100,000 | 10,000.00 | Scaleway Managed Database for PostgreSQL (one copy) | Unpriced | Unavailable |
| 100,000 | 10,000.00 | Scaleway Managed Database for PostgreSQL (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 PostgreSQL (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| Scaleway Managed Database for PostgreSQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| Scaleway Managed Database for PostgreSQL (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (one copy) | Origin list price · Database reads | 0 | USD/operations |
| Scaleway Managed Database for PostgreSQL (one copy) | Origin list price · Database writes | 0 | USD/operations |
| Scaleway Managed Database for PostgreSQL (one copy) | Target CPU / source CPU | 1 | multiplier |
| Scaleway Managed Database for PostgreSQL (one copy) | Target RAM / source RAM | 1 | multiplier |
| Scaleway Managed Database for PostgreSQL (one copy) | Target disk / source disk | 1 | multiplier |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · read | 0 | USD/read |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · write | 0 | USD/write |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| Scaleway Managed Database for PostgreSQL (one copy) | Target list price · GiB-month | 0.111266 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · network GiB | 0 | USD/network GiB |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Scaleway Managed Database for PostgreSQL (one copy) | Target list price · vCPU-hour | 0.0367275 | USD/vCPU-hour |
| Scaleway Managed Database for PostgreSQL (one copy) | Target list price · GiB-hour | 0.006225 | USD/GiB-hour |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · input token | 0 | USD/input token |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · output token | 0 | USD/output token |
| Scaleway Managed Database for PostgreSQL (one copy) | Target monthly base charge | 0 | USD/month |
| Scaleway Managed Database for PostgreSQL (one copy) | Target service minimum | 89.9762 | USD/month |
| Scaleway Managed Database for PostgreSQL (one copy) | Minimum primary CPU | 2 | vCPU |
| Scaleway Managed Database for PostgreSQL (one copy) | Minimum primary RAM | 8 | GiB |
| Scaleway Managed Database for PostgreSQL (one copy) | Minimum primary disk | 100 | GiB |
| Scaleway Managed Database for PostgreSQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Scaleway Managed Database for PostgreSQL (one copy) | Allocated share of provisioned cost | 1 | fraction |
| Scaleway Managed Database for PostgreSQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Scaleway Managed Database for PostgreSQL (one copy) | Planning peak / mean work | 2 | multiplier |
| Scaleway Managed Database for PostgreSQL (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| Scaleway Managed Database for PostgreSQL (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| Scaleway Managed Database for PostgreSQL (one copy) | Planning disk utilization | 0.8 | fraction |
| Scaleway Managed Database for PostgreSQL (one copy) | Maintenance and log disk reserve | 20 | GiB |
| Scaleway Managed Database for PostgreSQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Scaleway Managed Database for PostgreSQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Scaleway Managed Database for PostgreSQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Scaleway Managed Database for PostgreSQL (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| Scaleway Managed Database for PostgreSQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| Scaleway Managed Database for PostgreSQL (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (two copies) | Origin list price · Database reads | 0 | USD/operations |
| Scaleway Managed Database for PostgreSQL (two copies) | Origin list price · Database writes | 0 | USD/operations |
| Scaleway Managed Database for PostgreSQL (two copies) | Target CPU / source CPU | 1 | multiplier |
| Scaleway Managed Database for PostgreSQL (two copies) | Target RAM / source RAM | 1 | multiplier |
| Scaleway Managed Database for PostgreSQL (two copies) | Target disk / source disk | 1 | multiplier |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · read | 0 | USD/read |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · write | 0 | USD/write |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| Scaleway Managed Database for PostgreSQL (two copies) | Target list price · GiB-month | 0.111266 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · network GiB | 0 | USD/network GiB |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Scaleway Managed Database for PostgreSQL (two copies) | Target list price · vCPU-hour | 0.0367275 | USD/vCPU-hour |
| Scaleway Managed Database for PostgreSQL (two copies) | Target list price · GiB-hour | 0.006225 | USD/GiB-hour |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · input token | 0 | USD/input token |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · output token | 0 | USD/output token |
| Scaleway Managed Database for PostgreSQL (two copies) | Target monthly base charge | 0 | USD/month |
| Scaleway Managed Database for PostgreSQL (two copies) | Target service minimum | 89.9762 | USD/month |
| Scaleway Managed Database for PostgreSQL (two copies) | Minimum primary CPU | 2 | vCPU |
| Scaleway Managed Database for PostgreSQL (two copies) | Minimum primary RAM | 8 | GiB |
| Scaleway Managed Database for PostgreSQL (two copies) | Minimum primary disk | 100 | GiB |
| Scaleway Managed Database for PostgreSQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Scaleway Managed Database for PostgreSQL (two copies) | Allocated share of provisioned cost | 1 | fraction |
| Scaleway Managed Database for PostgreSQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Scaleway Managed Database for PostgreSQL (two copies) | Planning peak / mean work | 2 | multiplier |
| Scaleway Managed Database for PostgreSQL (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| Scaleway Managed Database for PostgreSQL (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| Scaleway Managed Database for PostgreSQL (two copies) | Planning disk utilization | 0.8 | fraction |
| Scaleway Managed Database for PostgreSQL (two copies) | Maintenance and log disk reserve | 20 | GiB |
| Scaleway Managed Database for PostgreSQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Scaleway Managed Database for PostgreSQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Scaleway Managed Database for PostgreSQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* Scaleway Managed Database for PostgreSQL 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-9818fc9ac977d4349d19fe5ce8eb48812af182c2` / `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/).

##### Aurora PostgreSQL · Database writes

Feature: Aurora PostgreSQL.

Estimated monthly service charges by Database writes. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: fr-par; currency: USD.

![Aurora PostgreSQL · 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/f605cbafc953c69ffb6b45a0e6d776e76ff3702596d5970811998cad95c99b67-light.svg)

![Aurora PostgreSQL · 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/916e281a72940ba3df8d19deaad71787e0e5970d745becdb057b03d3f200b0ad-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) | Aurora PostgreSQL | Target scenario | Scaleway Managed Database for PostgreSQL | Difference |
| -: | -: | - | -: | -: |
| 0 | 0.00 | Scaleway Managed Database for PostgreSQL (one copy) | 101.10 | 101.10 |
| 0 | 0.00 | Scaleway Managed Database for PostgreSQL (two copies) | 154.69 | 154.69 |
| 1 | 0.00 | Scaleway Managed Database for PostgreSQL (one copy) | 101.10 | 101.10 |
| 1 | 0.00 | Scaleway Managed Database for PostgreSQL (two copies) | 154.69 | 154.69 |
| 10 | 0.00 | Scaleway Managed Database for PostgreSQL (one copy) | 101.10 | 101.10 |
| 10 | 0.00 | Scaleway Managed Database for PostgreSQL (two copies) | 154.69 | 154.69 |
| 100 | 0.00 | Scaleway Managed Database for PostgreSQL (one copy) | 101.10 | 101.10 |
| 100 | 0.00 | Scaleway Managed Database for PostgreSQL (two copies) | 154.69 | 154.69 |
| 1,000 | 0.00 | Scaleway Managed Database for PostgreSQL (one copy) | 101.10 | 101.10 |
| 1,000 | 0.00 | Scaleway Managed Database for PostgreSQL (two copies) | 154.69 | 154.69 |
| 10,000 | 0.00 | Scaleway Managed Database for PostgreSQL (one copy) | 101.10 | 101.10 |
| 10,000 | 0.00 | Scaleway Managed Database for PostgreSQL (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 PostgreSQL (one copy) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| Scaleway Managed Database for PostgreSQL (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| Scaleway Managed Database for PostgreSQL (one copy) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (one copy) | Origin list price · Database reads | 0 | USD/operations |
| Scaleway Managed Database for PostgreSQL (one copy) | Origin list price · Database writes | 0 | USD/operations |
| Scaleway Managed Database for PostgreSQL (one copy) | Target CPU / source CPU | 1 | multiplier |
| Scaleway Managed Database for PostgreSQL (one copy) | Target RAM / source RAM | 1 | multiplier |
| Scaleway Managed Database for PostgreSQL (one copy) | Target disk / source disk | 1 | multiplier |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · read | 0 | USD/read |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · write | 0 | USD/write |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · provider operation | 0 | USD/provider operation |
| Scaleway Managed Database for PostgreSQL (one copy) | Target list price · GiB-month | 0.111266 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · published GiB | 0 | USD/published GiB |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · network GiB | 0 | USD/network GiB |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Scaleway Managed Database for PostgreSQL (one copy) | Target list price · vCPU-hour | 0.0367275 | USD/vCPU-hour |
| Scaleway Managed Database for PostgreSQL (one copy) | Target list price · GiB-hour | 0.006225 | USD/GiB-hour |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · resource-month | 0 | USD/resource-month |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · input token | 0 | USD/input token |
| Scaleway Managed Database for PostgreSQL (one copy) | Target price guess · output token | 0 | USD/output token |
| Scaleway Managed Database for PostgreSQL (one copy) | Target monthly base charge | 0 | USD/month |
| Scaleway Managed Database for PostgreSQL (one copy) | Target service minimum | 89.9762 | USD/month |
| Scaleway Managed Database for PostgreSQL (one copy) | Minimum primary CPU | 2 | vCPU |
| Scaleway Managed Database for PostgreSQL (one copy) | Minimum primary RAM | 8 | GiB |
| Scaleway Managed Database for PostgreSQL (one copy) | Minimum primary disk | 100 | GiB |
| Scaleway Managed Database for PostgreSQL (one copy) | Additional full-price standby copy | 0 | 0 or 1 |
| Scaleway Managed Database for PostgreSQL (one copy) | Allocated share of provisioned cost | 1 | fraction |
| Scaleway Managed Database for PostgreSQL (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Scaleway Managed Database for PostgreSQL (one copy) | Planning peak / mean work | 2 | multiplier |
| Scaleway Managed Database for PostgreSQL (one copy) | Planning primary CPU utilization | 0.7 | fraction |
| Scaleway Managed Database for PostgreSQL (one copy) | Resident state reserved in RAM | 0.1 | fraction |
| Scaleway Managed Database for PostgreSQL (one copy) | Planning disk utilization | 0.8 | fraction |
| Scaleway Managed Database for PostgreSQL (one copy) | Maintenance and log disk reserve | 20 | GiB |
| Scaleway Managed Database for PostgreSQL (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Scaleway Managed Database for PostgreSQL (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Scaleway Managed Database for PostgreSQL (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (one copy) | Dependent object sink write price guess | 0.000005 | USD/write |
| Scaleway Managed Database for PostgreSQL (two copies) | Origin list price · Primary compute | 0.145 | USD/vCPU-hours |
| Scaleway Managed Database for PostgreSQL (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours |
| Scaleway Managed Database for PostgreSQL (two copies) | Origin list price · Primary provisioned storage | 0.1 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (two copies) | Origin list price · Database reads | 0 | USD/operations |
| Scaleway Managed Database for PostgreSQL (two copies) | Origin list price · Database writes | 0 | USD/operations |
| Scaleway Managed Database for PostgreSQL (two copies) | Target CPU / source CPU | 1 | multiplier |
| Scaleway Managed Database for PostgreSQL (two copies) | Target RAM / source RAM | 1 | multiplier |
| Scaleway Managed Database for PostgreSQL (two copies) | Target disk / source disk | 1 | multiplier |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · read | 0 | USD/read |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · write | 0 | USD/write |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · provider operation | 0 | USD/provider operation |
| Scaleway Managed Database for PostgreSQL (two copies) | Target list price · GiB-month | 0.111266 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · published GiB | 0 | USD/published GiB |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · network GiB | 0 | USD/network GiB |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month |
| Scaleway Managed Database for PostgreSQL (two copies) | Target list price · vCPU-hour | 0.0367275 | USD/vCPU-hour |
| Scaleway Managed Database for PostgreSQL (two copies) | Target list price · GiB-hour | 0.006225 | USD/GiB-hour |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · resource-month | 0 | USD/resource-month |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · input token | 0 | USD/input token |
| Scaleway Managed Database for PostgreSQL (two copies) | Target price guess · output token | 0 | USD/output token |
| Scaleway Managed Database for PostgreSQL (two copies) | Target monthly base charge | 0 | USD/month |
| Scaleway Managed Database for PostgreSQL (two copies) | Target service minimum | 89.9762 | USD/month |
| Scaleway Managed Database for PostgreSQL (two copies) | Minimum primary CPU | 2 | vCPU |
| Scaleway Managed Database for PostgreSQL (two copies) | Minimum primary RAM | 8 | GiB |
| Scaleway Managed Database for PostgreSQL (two copies) | Minimum primary disk | 100 | GiB |
| Scaleway Managed Database for PostgreSQL (two copies) | Additional full-price standby copy | 1 | 0 or 1 |
| Scaleway Managed Database for PostgreSQL (two copies) | Allocated share of provisioned cost | 1 | fraction |
| Scaleway Managed Database for PostgreSQL (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second |
| Scaleway Managed Database for PostgreSQL (two copies) | Planning peak / mean work | 2 | multiplier |
| Scaleway Managed Database for PostgreSQL (two copies) | Planning primary CPU utilization | 0.7 | fraction |
| Scaleway Managed Database for PostgreSQL (two copies) | Resident state reserved in RAM | 0.1 | fraction |
| Scaleway Managed Database for PostgreSQL (two copies) | Planning disk utilization | 0.8 | fraction |
| Scaleway Managed Database for PostgreSQL (two copies) | Maintenance and log disk reserve | 20 | GiB |
| Scaleway Managed Database for PostgreSQL (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour |
| Scaleway Managed Database for PostgreSQL (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour |
| Scaleway Managed Database for PostgreSQL (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month |
| Scaleway Managed Database for PostgreSQL (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.
* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.
* Scaleway Managed Database for PostgreSQL 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-9818fc9ac977d4349d19fe5ce8eb48812af182c2` / `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/).

**Aurora PostgreSQL → Scaleway Managed Database for PostgreSQL: 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.145 | USD/vCPU-hours |
| Origin list price · Primary memory | 0 | USD/GiB-hours |
| Origin list price · Primary provisioned storage | 0.1 | 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.

* Aurora Standard also bills storage I/O at USD 0.20 per 1M I/Os (buffer-cache misses, not logical operations); no meter prices it, so the origin cost excludes it. I/O-Optimized clusters bill no I/O but 30% more per instance and 0.225 per GB-month storage.

* Scaleway Managed Database for PostgreSQL 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-9818fc9ac977d4349d19fe5ce8eb48812af182c2` / `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 |
| - | - | - | -: | -: | -: | - |
| AlloyDB for PostgreSQL | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 846.80 | 677.53 | -169.27 | Service adapter |
| AlloyDB for PostgreSQL (RDS proxy) | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 846.80 | 677.53 | -169.27 | Service adapter |
| Cloud SQL for PostgreSQL | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 846.80 | 421.71 | -425.09 | Service adapter |
| OCI Database with PostgreSQL | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 846.80 | 340.08 | -506.72 | Service adapter |
| PostgreSQL | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 846.80 | 531.50 | -315.30 | Service adapter |
| PostgreSQL (CloudNativePG) | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 846.80 | 293.58 | -553.22 | Service adapter |
| PostgreSQL Flexible Server | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 846.80 | 531.26 | -315.54 | Service adapter |
| Scaleway Managed Database for PostgreSQL | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 846.80 | 371.03 | -475.77 | 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).

### Aurora PostgreSQL to PostgreSQL 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` | 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`, `CreateDBInstance`, `CreateGlobalCluster`, `DescribeDBClusters`, `FailoverDBCluster`, `FailoverGlobalCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `StartDBCluster`, `StopDBCluster`, `SwitchoverGlobalCluster` | 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. |
| Bounded Data API translation adapter-added latency | +5 ms monthly p99 | `aws::1.0.0::rds-data`: `BatchExecuteStatement`, `BeginTransaction`, `CommitTransaction`, `ExecuteStatement`, `RollbackTransaction` | One SQL statement at most 8 KiB, at most 50 bound parameters and at most 100 rows or 256 KiB response. A batch contains at most 10 parameter sets. SQL execution and database transaction/lock wait are target work; adapter transaction-handle storage remains fabric work. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::rds`: `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `CreateDBClusterSnapshot`, `CreateDBInstance`, `CreateGlobalCluster`, `FailoverDBCluster`, `FailoverGlobalCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `StartDBCluster`, `StopDBCluster`, `SwitchoverGlobalCluster`, `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` `aws::1.0.0::rds-data`: `BatchExecuteStatement`, `BeginTransaction`, `CommitTransaction`, `ExecuteStatement`, `RollbackTransaction` | 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::postgresql::flexible`, these rows apply to the RDS/Aurora API adapter, not to native PostgreSQL or MySQL connections. Application SQL commonly goes directly to the target database and therefore has no adapter translation latency to guarantee. The RDS control runtime retains logical intent, exposes status and reconciles target resources. The selected profile defines which directed operations and request options are covered.

#### How the latency targets were chosen

**Bounded database status responses: +20 ms monthly p99 (adapter-added).** `DescribeDBClusterSnapshots`, `DescribeDBClusters`. The control adapter reads its durable database records and checks native status; reading the adapter's stored request history and current resource records counts as fabric work.

**Database lifecycle request acceptance: +30 ms monthly p99 (adapter-added).** `CreateDBClusterSnapshot`, `CreateDBInstance`, `CreateGlobalCluster`, `DescribeDBClusters`, `FailoverDBCluster`, `FailoverGlobalCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `StartDBCluster`, `StopDBCluster`, `SwitchoverGlobalCluster`. The RDS adapter durably records the requested change before its background workers update target resources. Waiting for those adapter records and coordination still counts as fabric time, not database query time.

**Bounded database parameter requests: +20 ms monthly p99 (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.

**Bounded Data API translation: +5 ms monthly p99 (adapter-added).** `BatchExecuteStatement`, `BeginTransaction`, `CommitTransaction`, `ExecuteStatement`, `RollbackTransaction`. Data API requests require JSON/parameter decoding, native SQL dispatch and result conversion; they are distinct from application connections that speak SQL directly.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### 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.

### Aurora PostgreSQL to PostgreSQL (CloudNativePG)

| 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` | 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`, `CreateDBInstance`, `DescribeDBClusters`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `StartDBCluster`, `StopDBCluster` | 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. |
| Bounded Data API translation adapter-added latency | +5 ms monthly p99 | `aws::1.0.0::rds-data`: `BatchExecuteStatement`, `BeginTransaction`, `CommitTransaction`, `ExecuteStatement`, `RollbackTransaction` | One SQL statement at most 8 KiB, at most 50 bound parameters and at most 100 rows or 256 KiB response. A batch contains at most 10 parameter sets. SQL execution and database transaction/lock wait are target work; adapter transaction-handle storage remains fabric work. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::rds`: `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `CreateDBClusterSnapshot`, `CreateDBInstance`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `StartDBCluster`, `StopDBCluster`, `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` `aws::1.0.0::rds-data`: `BatchExecuteStatement`, `BeginTransaction`, `CommitTransaction`, `ExecuteStatement`, `RollbackTransaction` | 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 `cloudnative::1.0.0::postgresql`, these rows apply to the RDS/Aurora API adapter, not to native PostgreSQL or MySQL connections. Application SQL commonly goes directly to the target database and therefore has no adapter translation latency to guarantee. The RDS control runtime retains logical intent, exposes status and reconciles target resources. The selected profile defines which directed operations and request options are covered.

#### How the latency targets were chosen

**Bounded database status responses: +20 ms monthly p99 (adapter-added).** `DescribeDBClusterSnapshots`, `DescribeDBClusters`. The control adapter reads its durable database records and checks native status; reading the adapter's stored request history and current resource records counts as fabric work.

**Database lifecycle request acceptance: +30 ms monthly p99 (adapter-added).** `CreateDBClusterSnapshot`, `CreateDBInstance`, `DescribeDBClusters`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `StartDBCluster`, `StopDBCluster`. The RDS adapter durably records the requested change before its background workers update target resources. Waiting for those adapter records and coordination still counts as fabric time, not database query time.

**Bounded database parameter requests: +20 ms monthly p99 (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.

**Bounded Data API translation: +5 ms monthly p99 (adapter-added).** `BatchExecuteStatement`, `BeginTransaction`, `CommitTransaction`, `ExecuteStatement`, `RollbackTransaction`. Data API requests require JSON/parameter decoding, native SQL dispatch and result conversion; they are distinct from application connections that speak SQL directly.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### 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.

### Aurora PostgreSQL to PostgreSQL

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Bounded database status responses adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBClusters` | 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`: `CreateDBCluster`, `CreateDBClusterSnapshot`, `CreateDBInstance`, `CreateGlobalCluster`, `DeleteDBCluster`, `DescribeDBClusters`, `FailoverDBCluster`, `FailoverGlobalCluster`, `ModifyDBCluster`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `SwitchoverGlobalCluster` | 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. |
| Bounded Data API translation adapter-added latency | +5 ms monthly p99 | `aws::1.0.0::rds-data`: `BatchExecuteStatement`, `BeginTransaction`, `CommitTransaction`, `ExecuteStatement`, `RollbackTransaction` | One SQL statement at most 8 KiB, at most 50 bound parameters and at most 100 rows or 256 KiB response. A batch contains at most 10 parameter sets. SQL execution and database transaction/lock wait are target work; adapter transaction-handle storage remains fabric work. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::rds`: `DescribeDBClusters`, `CreateDBCluster`, `CreateDBClusterSnapshot`, `CreateDBInstance`, `CreateGlobalCluster`, `DeleteDBCluster`, `FailoverDBCluster`, `FailoverGlobalCluster`, `ModifyDBCluster`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `SwitchoverGlobalCluster`, `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` `aws::1.0.0::rds-data`: `BatchExecuteStatement`, `BeginTransaction`, `CommitTransaction`, `ExecuteStatement`, `RollbackTransaction` | 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::postgresql`, these rows apply to the RDS/Aurora API adapter, not to native PostgreSQL or MySQL connections. Application SQL commonly goes directly to the target database and therefore has no adapter translation latency to guarantee. The RDS control runtime retains logical intent, exposes status and reconciles target resources. The selected profile defines which directed operations and request options are covered.

#### How the latency targets were chosen

**Bounded database status responses: +20 ms monthly p99 (adapter-added).** `DescribeDBClusters`. The control adapter reads its durable database records and checks native status; reading the adapter's stored request history and current resource records counts as fabric work.

**Database lifecycle request acceptance: +30 ms monthly p99 (adapter-added).** `CreateDBCluster`, `CreateDBClusterSnapshot`, `CreateDBInstance`, `CreateGlobalCluster`, `DeleteDBCluster`, `DescribeDBClusters`, `FailoverDBCluster`, `FailoverGlobalCluster`, `ModifyDBCluster`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `SwitchoverGlobalCluster`. The RDS adapter durably records the requested change before its background workers update target resources. Waiting for those adapter records and coordination still counts as fabric time, not database query time.

**Bounded database parameter requests: +20 ms monthly p99 (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.

**Bounded Data API translation: +5 ms monthly p99 (adapter-added).** `BatchExecuteStatement`, `BeginTransaction`, `CommitTransaction`, `ExecuteStatement`, `RollbackTransaction`. Data API requests require JSON/parameter decoding, native SQL dispatch and result conversion; they are distinct from application connections that speak SQL directly.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### 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.

### Aurora PostgreSQL to AlloyDB for PostgreSQL

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Bounded cluster and member status adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBClusters`, `DescribeDBInstances` | One cluster or at most 100 adapter-owned cluster/member records and 256 KiB response; observed target status included, PostgreSQL query time excluded. The Aurora PostgreSQL-to-AlloyDB management backend is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter and operations are deployed and named in a signed agreement. Application PostgreSQL connections use AlloyDB directly and have no adapter SQL-latency target here. |
| Cluster and member lifecycle admission adapter-added latency | +30 ms monthly p99 | `aws::1.0.0::rds`: `CreateDBCluster`, `CreateDBInstance`, `DeleteDBCluster`, `DeleteDBInstance`, `ModifyDBCluster`, `ModifyDBInstance` | One cluster or member and at most 32 KiB supported settings; validation and durable intent included, AlloyDB provisioning, failover and teardown readiness excluded. The Aurora PostgreSQL-to-AlloyDB management backend is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter and operations are deployed and named in a signed agreement. Application PostgreSQL connections use AlloyDB directly and have no adapter SQL-latency target here. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::rds`: `DescribeDBClusters`, `DescribeDBInstances`, `CreateDBCluster`, `CreateDBInstance`, `DeleteDBCluster`, `DeleteDBInstance`, `ModifyDBCluster`, `ModifyDBInstance` | A successful lifecycle call means complete desired state is durable, not that AlloyDB is ready. The adapter preserves the Aurora cluster/member relationship and writer-versus-reader identities, refuses unsupported Aurora settings, and never reports a foreign database as adapter-managed. Status reflects observed target readiness rather than an optimistic synthetic success. |
| 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. The Aurora PostgreSQL-to-AlloyDB management backend is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter and operations are deployed and named in a signed agreement. Application PostgreSQL connections use AlloyDB directly and have no adapter SQL-latency target here. |
| 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.

**Deployment availability.** The Aurora PostgreSQL-to-AlloyDB management backend is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter and operations are deployed and named in a signed agreement. Application PostgreSQL connections use AlloyDB directly and have no adapter SQL-latency target here.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

The Aurora PostgreSQL management adapter validates cluster and member requests, retains AWS-shaped identities and reconciles AlloyDB resources. These estimates describe adapter handling once the declared exact target is deployed. Applications speak PostgreSQL directly to AlloyDB; SQL execution, backup work and native readiness are not hidden within a 20 or 30 ms management-request budget.

#### How the latency targets were chosen

**Bounded cluster and member status: +20 ms monthly p99 (adapter-added).** `DescribeDBClusters`, `DescribeDBInstances`. Includes durable control-state read, native-status lookup and AWS response mapping.

**Cluster and member lifecycle admission: +30 ms monthly p99 (adapter-added).** `CreateDBCluster`, `CreateDBInstance`, `DeleteDBCluster`, `DeleteDBInstance`, `ModifyDBCluster`, `ModifyDBInstance`. Includes bounded Aurora request validation, logical identity allocation, durable commit and reconciliation scheduling.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### 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

Independent clusters reconcile concurrently while writes to one cluster and its members follow generation order. Qualification fixes clusters, members per cluster, returned status records, settings bytes, polling rate and concurrent changes. Native AlloyDB quota and compute capacity are separate from adapter handler capacity.

Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

#### Data and behavior guarantees

A successful lifecycle call means complete desired state is durable, not that AlloyDB is ready. The adapter preserves the Aurora cluster/member relationship and writer-versus-reader identities, refuses unsupported Aurora settings, and never reports a foreign database as adapter-managed. Status reflects observed target readiness rather than an optimistic synthetic success.

#### Example and diagnosis

After this adapter is deployed, CreateDBCluster for one bounded PostgreSQL cluster records an AWS-shaped cluster identity within the 30 ms p99 target. AlloyDB provisioning continues separately. DescribeDBClusters reads the same identity and honest observed status within the 20 ms target; an application's SELECT uses its direct PostgreSQL connection and neither number applies to it.

Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

### Aurora PostgreSQL to AlloyDB for PostgreSQL (RDS proxy)

| SLA | Service level | What is covered | Conditions |
| - | - | - | - |
| Bounded cluster and member status adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBClusters`, `DescribeDBInstances` | One cluster or at most 100 adapter-owned cluster/member records and 256 KiB response; observed target status included, PostgreSQL query time excluded. The Aurora PostgreSQL-to-AlloyDB backend behind the Tensor9 PostgreSQL proxy is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter, its proxy and the operations are deployed and named in a signed agreement. Application PostgreSQL connections pass through the proxy, which has no SQL-latency target here. |
| Cluster and member lifecycle admission adapter-added latency | +30 ms monthly p99 | `aws::1.0.0::rds`: `CreateDBCluster`, `CreateDBInstance`, `DeleteDBCluster`, `DeleteDBInstance`, `ModifyDBCluster`, `ModifyDBInstance` | One cluster or member and at most 32 KiB supported settings; validation and durable intent included, AlloyDB provisioning, failover and teardown readiness excluded. The Aurora PostgreSQL-to-AlloyDB backend behind the Tensor9 PostgreSQL proxy is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter, its proxy and the operations are deployed and named in a signed agreement. Application PostgreSQL connections pass through the proxy, which has no SQL-latency target here. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::rds`: `DescribeDBClusters`, `DescribeDBInstances`, `CreateDBCluster`, `CreateDBInstance`, `DeleteDBCluster`, `DeleteDBInstance`, `ModifyDBCluster`, `ModifyDBInstance` | A successful lifecycle call means complete desired state is durable, not that AlloyDB is ready. The adapter preserves the Aurora cluster/member relationship and writer-versus-reader identities, refuses unsupported Aurora settings, and never reports a foreign database as adapter-managed. Status reflects observed target readiness rather than an optimistic synthetic success. |
| 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. The Aurora PostgreSQL-to-AlloyDB backend behind the Tensor9 PostgreSQL proxy is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter, its proxy and the operations are deployed and named in a signed agreement. Application PostgreSQL connections pass through the proxy, which has no SQL-latency target here. |
| 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.

**Deployment availability.** The Aurora PostgreSQL-to-AlloyDB backend behind the Tensor9 PostgreSQL proxy is declared, not a generally deployed production endpoint. These targets apply only after this exact control-plane adapter, its proxy and the operations are deployed and named in a signed agreement. Application PostgreSQL connections pass through the proxy, which has no SQL-latency target here.

**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.

**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.

**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

#### What this adapter does

The Aurora PostgreSQL management adapter validates cluster and member requests, retains AWS-shaped identities and reconciles AlloyDB resources and the cluster's proxy. These estimates describe adapter handling once the declared exact target is deployed. Applications connect to the Tensor9 PostgreSQL proxy, which authenticates each session and relays it over its own connection to the database; it does not pool or translate SQL. The proxy's SQL path has no latency target, and SQL execution, backup work and native readiness are not hidden within a management-request budget.

#### How the latency targets were chosen

**Bounded cluster and member status: +20 ms monthly p99 (adapter-added).** `DescribeDBClusters`, `DescribeDBInstances`. Includes durable control-state read, native-status lookup and AWS response mapping.

**Cluster and member lifecycle admission: +30 ms monthly p99 (adapter-added).** `CreateDBCluster`, `CreateDBInstance`, `DeleteDBCluster`, `DeleteDBInstance`, `ModifyDBCluster`, `ModifyDBInstance`. Includes bounded Aurora request validation, logical identity allocation, durable commit and reconciliation scheduling.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### 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

Independent clusters reconcile concurrently while writes to one cluster and its members follow generation order. Qualification fixes clusters, members per cluster, returned status records, settings bytes, polling rate and concurrent changes. Native AlloyDB quota and compute capacity are separate from adapter handler capacity.

Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

#### Data and behavior guarantees

A successful lifecycle call means complete desired state is durable, not that AlloyDB is ready. The adapter preserves the Aurora cluster/member relationship and writer-versus-reader identities, refuses unsupported Aurora settings, and never reports a foreign database as adapter-managed. Status reflects observed target readiness rather than an optimistic synthetic success.

#### Example and diagnosis

After this adapter is deployed, CreateDBCluster for one bounded PostgreSQL cluster records an AWS-shaped cluster identity within the 30 ms p99 target. AlloyDB provisioning continues separately. DescribeDBClusters reads the same identity and honest observed status within the 20 ms target; an application's SELECT uses its proxied PostgreSQL connection and neither number applies to it.

Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

### Aurora PostgreSQL to Cloud SQL for PostgreSQL

| 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` | 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`, `CreateDBInstance`, `CreateGlobalCluster`, `DescribeDBClusters`, `FailoverDBCluster`, `FailoverGlobalCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `StartDBCluster`, `StopDBCluster`, `SwitchoverGlobalCluster` | 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. |
| Bounded Data API translation adapter-added latency | +5 ms monthly p99 | `aws::1.0.0::rds-data`: `BatchExecuteStatement`, `BeginTransaction`, `CommitTransaction`, `ExecuteStatement`, `RollbackTransaction` | One SQL statement at most 8 KiB, at most 50 bound parameters and at most 100 rows or 256 KiB response. A batch contains at most 10 parameter sets. SQL execution and database transaction/lock wait are target work; adapter transaction-handle storage remains fabric work. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::rds`: `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `CreateDBClusterSnapshot`, `CreateDBInstance`, `CreateGlobalCluster`, `FailoverDBCluster`, `FailoverGlobalCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `StartDBCluster`, `StopDBCluster`, `SwitchoverGlobalCluster`, `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` `aws::1.0.0::rds-data`: `BatchExecuteStatement`, `BeginTransaction`, `CommitTransaction`, `ExecuteStatement`, `RollbackTransaction` | 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::postgresql`, these rows apply to the RDS/Aurora API adapter, not to native PostgreSQL or MySQL connections. Application SQL commonly goes directly to the target database and therefore has no adapter translation latency to guarantee. The RDS control runtime retains logical intent, exposes status and reconciles target resources. The selected profile defines which directed operations and request options are covered.

#### How the latency targets were chosen

**Bounded database status responses: +20 ms monthly p99 (adapter-added).** `DescribeDBClusterSnapshots`, `DescribeDBClusters`. The control adapter reads its durable database records and checks native status; reading the adapter's stored request history and current resource records counts as fabric work.

**Database lifecycle request acceptance: +30 ms monthly p99 (adapter-added).** `CreateDBClusterSnapshot`, `CreateDBInstance`, `CreateGlobalCluster`, `DescribeDBClusters`, `FailoverDBCluster`, `FailoverGlobalCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `StartDBCluster`, `StopDBCluster`, `SwitchoverGlobalCluster`. The RDS adapter durably records the requested change before its background workers update target resources. Waiting for those adapter records and coordination still counts as fabric time, not database query time.

**Bounded database parameter requests: +20 ms monthly p99 (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.

**Bounded Data API translation: +5 ms monthly p99 (adapter-added).** `BatchExecuteStatement`, `BeginTransaction`, `CommitTransaction`, `ExecuteStatement`, `RollbackTransaction`. Data API requests require JSON/parameter decoding, native SQL dispatch and result conversion; they are distinct from application connections that speak SQL directly.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### 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.

### Aurora PostgreSQL to OCI Database with PostgreSQL

| 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` | 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`, `CreateDBInstance`, `DescribeDBClusters`, `ModifyDBCluster`, `ModifyDBInstance`, `RestoreDBClusterFromSnapshot`, `StartDBCluster`, `StopDBCluster` | 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. |
| Bounded Data API translation adapter-added latency | +5 ms monthly p99 | `aws::1.0.0::rds-data`: `BatchExecuteStatement`, `BeginTransaction`, `CommitTransaction`, `ExecuteStatement`, `RollbackTransaction` | One SQL statement at most 8 KiB, at most 50 bound parameters and at most 100 rows or 256 KiB response. A batch contains at most 10 parameter sets. SQL execution and database transaction/lock wait are target work; adapter transaction-handle storage remains fabric work. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::rds`: `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `CreateDBClusterSnapshot`, `CreateDBInstance`, `ModifyDBCluster`, `ModifyDBInstance`, `RestoreDBClusterFromSnapshot`, `StartDBCluster`, `StopDBCluster`, `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` `aws::1.0.0::rds-data`: `BatchExecuteStatement`, `BeginTransaction`, `CommitTransaction`, `ExecuteStatement`, `RollbackTransaction` | 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::psql`, these rows apply to the RDS/Aurora API adapter, not to native PostgreSQL or MySQL connections. Application SQL commonly goes directly to the target database and therefore has no adapter translation latency to guarantee. The RDS control runtime retains logical intent, exposes status and reconciles target resources. The selected profile defines which directed operations and request options are covered.

#### How the latency targets were chosen

**Bounded database status responses: +20 ms monthly p99 (adapter-added).** `DescribeDBClusterSnapshots`, `DescribeDBClusters`. The control adapter reads its durable database records and checks native status; reading the adapter's stored request history and current resource records counts as fabric work.

**Database lifecycle request acceptance: +30 ms monthly p99 (adapter-added).** `CreateDBClusterSnapshot`, `CreateDBInstance`, `DescribeDBClusters`, `ModifyDBCluster`, `ModifyDBInstance`, `RestoreDBClusterFromSnapshot`, `StartDBCluster`, `StopDBCluster`. The RDS adapter durably records the requested change before its background workers update target resources. Waiting for those adapter records and coordination still counts as fabric time, not database query time.

**Bounded database parameter requests: +20 ms monthly p99 (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.

**Bounded Data API translation: +5 ms monthly p99 (adapter-added).** `BatchExecuteStatement`, `BeginTransaction`, `CommitTransaction`, `ExecuteStatement`, `RollbackTransaction`. Data API requests require JSON/parameter decoding, native SQL dispatch and result conversion; they are distinct from application connections that speak SQL directly.

Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

#### What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.

For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

#### 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.

### Aurora PostgreSQL to Scaleway Managed Database for PostgreSQL

**SLA status:** Not applicable

This mapping provisions a native database. SQL clients connect directly to it; this directed mapping does not expose an RDS management adapter endpoint. Database availability and query latency are covered by the database provider, not a Tensor9 request-processing SLA.

## Install and run

The documentation and SLAs are public. Downloading and running the Cloud Adapter binary requires an entitled customer account. 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::aurora-postgresql
```

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.