> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # RDS PostgreSQL > RDS PostgreSQL APIs with Cloud Adapter. This page describes how RDS 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 RDS 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 | RDS PostgreSQL | Azure | DigitalOcean | Google Cloud · Cloud SQL for PostgreSQL | Google Cloud · Cloud SQL 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 (Protocol and intended management comparison, subject to selected PostgreSQL, extension and CloudNativePG operator versions. Registry version 1.0.0 is not an engine version. Existing deployment selection defaults to PostgreSQL 15 and resolves its image tag; neither that default nor the referenced CNPG 1.28 documentation proves the installed versions. Qualify the exact selected engine/image/operator and Max SIP revision before claiming On-Prem readiness.) | partial | #### Management surface | Capability | RDS PostgreSQL | Azure | DigitalOcean | Google Cloud · Cloud SQL for PostgreSQL | Google Cloud · Cloud SQL 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 | Yes | 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 | No | No | No | | Read replicas · in-region | Yes | Yes | Yes - separate read-only nodes | Yes | Yes | Yes | Yes | Partial - Scaleway offers asynchronous read replicas in the same or another zone; RDS read replicas are not translated into them | | Read replicas · cross-region | Yes | Yes | Partial - read-only node in another region; promotion ends replication from the original | Yes | Yes | 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 - the Tensor9 proxy adds IAM login but keeps one Cloud SQL connection per client session and serves no RDS Proxy APIs | Yes | Yes | No | | Trusted Language Extensions · pg\_tle | Yes | No | - | No | No | No | Yes | No | | Query performance insights · Performance Insights | Yes | Partial - backend-native performance tools; access is controlled by the customer | Partial - backend monitoring differs; customer controls access | Partial - backend-native performance tools; access is controlled by the customer | Partial - backend-native performance tools; access is controlled by the customer | Partial - backend-native performance tools; access is controlled by the customer | Partial - backend-native performance tools; access is controlled by the customer | Partial - metrics and logs in Scaleway Cockpit; the vendor can't access the Cloud Adapter deployment's console | | Data API (HTTP SQL) · rds-data | Yes | - | - | - | - | - | - | No | #### Limits | Capability | RDS PostgreSQL | Azure | DigitalOcean | Google Cloud · Cloud SQL for PostgreSQL | Google Cloud · Cloud SQL for PostgreSQL (RDS proxy) | OCI | Private Kubernetes and Scaleway · PostgreSQL (CloudNativePG) | Scaleway · Scaleway Managed Database for PostgreSQL | | - | - | - | - | - | - | - | - | - | | Maximum storage | 64 TiB | 64 TiB | - | 64 TiB | 64 TiB | 32 TiB | limited by persistent volume capacity | 10,000 GB | | vCPU range · smallest to largest instance | 2-384 | 1-192 | - | 1-128 | 1-128 | 2-128 (64 OCPU) | limited by Kubernetes node resources | 2-8 | | Memory range · smallest to largest instance | 1-4,096 GiB | 2-1,832 GiB | - | 0.6-864 GiB | 0.6-864 GiB | 16-1,024 GiB | limited by Kubernetes node resources | 3-29 GB | | Storage autoscaling | 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 integration SQL: aws\_s3.\*, aws\_lambda.invoke, rds\_tools | SQL functions | Out of scope | Full surface | RDS extension functions with no counterpart on vanilla PostgreSQL; a query calling them fails | | pgwire protocol (application SQL) | Wire protocol | Supported | Common | same PostgreSQL engine; application SQL is unchanged | #### How it works Your application's PostgreSQL driver connects directly to Azure Database for PostgreSQL Flexible Server. These database requests are the **data plane**. The driver and the PostgreSQL wire protocol stay the same, and Tensor9 does not proxy or translate 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 Azure Database for PostgreSQL Flexible Server runs the same PostgreSQL engine as RDS. Your SQL, drivers, object-relational mappers (ORMs), prepared statements, data types and transaction behavior stay the same. Your application connects directly to the server. RDS adds SQL functions for importing and exporting through S3 and for invoking Lambda from a query. These AWS-specific 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 instance, take a snapshot, restore to a point in time, add or promote a read replica, trigger a failover, stop and start, change the instance class or a parameter. 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 in-region and cross-region, manual failover, stop / start, and compute, storage and server-parameter updates. With Max, your tools call `CreateDBInstance` and `DeleteDBInstance` through the RDS adapter to create and remove a database on Azure PostgreSQL Flexible Server. Tensor9 keeps a durable record of each logical database and reconciles the Flexible Server with it: it records each accepted request, then creates or removes the Azure resources in the background. Call `DescribeDBInstances` to follow the status and get the database endpoint. Your application's SQL connection still goes directly to the database. With the Infrastructure-only option, Tensor9 compiles the declared database 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+Cjx0ZXh0IHg9IjEzNCIgeT0iOTkiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5yZXBsaWNhIMK3IGZhaWxvdmVyIMK3IHN0b3AgLyBzdGFydDwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSIxMTYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5pbnN0YW5jZSBjbGFzcyDCtyBwYXJhbWV0ZXJzPC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9IjE0MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGIiPnNhbWUgcmVxdWVzdCAvIHJlc3BvbnNlIHNoYXBlczwvdGV4dD4KPGxpbmUgeDE9IjI1MiIgeTE9Ijc0IiB4Mj0iMzE0IiB5Mj0iNzQiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWF6dXJlLW1hbmFnZW1lbnQtYXBpKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxsaW5lIHgxPSIzMTgiIHkxPSIxMjgiIHgyPSIyNTYiIHkyPSIxMjgiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWF6dXJlLW1hbmFnZW1lbnQtYXBpKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxyZWN0IHg9IjMxOCIgeT0iNTQiIHdpZHRoPSIyMDQiIGhlaWdodD0iODgiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iNDIwIiB5PSI5NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTc7IGZvbnQtc2l6ZToxMnB4Ij5UZW5zb3I5PC90ZXh0PgogIDx0ZXh0IHg9IjQyMCIgeT0iMTEyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij5zZXJ2aWNlIGFkYXB0ZXI8L3RleHQ+CjxsaW5lIHgxPSI1MjIiIHkxPSI3NCIgeDI9IjU4NCIgeTI9Ijc0IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhjLXJkcy1henVyZS1tYW5hZ2VtZW50LWFwaSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8bGluZSB4MT0iNTg4IiB5MT0iMTI4IiB4Mj0iNTI2IiB5Mj0iMTI4IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhjLXJkcy1henVyZS1tYW5hZ2VtZW50LWFwaSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8cmVjdCB4PSI1ODgiIHk9IjM0IiB3aWR0aD0iMjMyIiBoZWlnaHQ9IjEyOCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSI3MDQiIHk9IjYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjEycHgiPkF6dXJlIG1hbmFnZW1lbnQgQVBJPC90ZXh0Pgo8dGV4dCB4PSI3MDQiIHk9Ijk0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+YmFja3VwcyDCtyByZXN0b3JlcyDCtyByZXBsaWNhczwvdGV4dD4KPHRleHQgeD0iNzA0IiB5PSIxMTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5mYWlsb3ZlciDCtyB1cGRhdGVzIMK3IHBhcmFtZXRlcnM8L3RleHQ+Cjwvc3ZnPg==) ![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+Cjx0ZXh0IHg9IjEzNCIgeT0iOTkiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5yZXBsaWNhIMK3IGZhaWxvdmVyIMK3IHN0b3AgLyBzdGFydDwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSIxMTYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5pbnN0YW5jZSBjbGFzcyDCtyBwYXJhbWV0ZXJzPC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9IjE0MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjgiPnNhbWUgcmVxdWVzdCAvIHJlc3BvbnNlIHNoYXBlczwvdGV4dD4KPGxpbmUgeDE9IjI1MiIgeTE9Ijc0IiB4Mj0iMzE0IiB5Mj0iNzQiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWF6dXJlLW1hbmFnZW1lbnQtYXBpKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxsaW5lIHgxPSIzMTgiIHkxPSIxMjgiIHgyPSIyNTYiIHkyPSIxMjgiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWF6dXJlLW1hbmFnZW1lbnQtYXBpKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxyZWN0IHg9IjMxOCIgeT0iNTQiIHdpZHRoPSIyMDQiIGhlaWdodD0iODgiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iNDIwIiB5PSI5NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3Yjc7IGZvbnQtc2l6ZToxMnB4Ij5UZW5zb3I5PC90ZXh0PgogIDx0ZXh0IHg9IjQyMCIgeT0iMTEyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij5zZXJ2aWNlIGFkYXB0ZXI8L3RleHQ+CjxsaW5lIHgxPSI1MjIiIHkxPSI3NCIgeDI9IjU4NCIgeTI9Ijc0IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhjLXJkcy1henVyZS1tYW5hZ2VtZW50LWFwaSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8bGluZSB4MT0iNTg4IiB5MT0iMTI4IiB4Mj0iNTI2IiB5Mj0iMTI4IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhjLXJkcy1henVyZS1tYW5hZ2VtZW50LWFwaSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8cmVjdCB4PSI1ODgiIHk9IjM0IiB3aWR0aD0iMjMyIiBoZWlnaHQ9IjEyOCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSI3MDQiIHk9IjYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjEycHgiPkF6dXJlIG1hbmFnZW1lbnQgQVBJPC90ZXh0Pgo8dGV4dCB4PSI3MDQiIHk9Ijk0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+YmFja3VwcyDCtyByZXN0b3JlcyDCtyByZXBsaWNhczwvdGV4dD4KPHRleHQgeD0iNzA0IiB5PSIxMTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5mYWlsb3ZlciDCtyB1cGRhdGVzIMK3IHBhcmFtZXRlcnM8L3RleHQ+Cjwvc3ZnPg==) Tensor9 translates RDS management requests to the backend API and returns RDS responses. #### Limitations Where RDS and PostgreSQL Flexible Server differ * **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. * **RDS-specific settings are not supported.** The CA certificate, Enhanced Monitoring, processor features and Kerberos / AD domain join have no Flexible Server equivalent. #### Other considerations **Migration.** Move existing data with a logical dump and restore, or use logical replication to shorten the cutover pause. Check the selected PostgreSQL version and the extensions you need, and switch application connections only after you have checked the copied data. **Operations.** The customer owns the Flexible Server in their Azure subscription. Maintenance windows, quotas and pricing are Microsoft's. **Features and capacity.** The comparison table on this page lists 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. ##### RDS PostgreSQL · Primary allocated compute Feature: RDS PostgreSQL. Estimated monthly service charges by Primary allocated compute. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD. ![RDS 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/f3d7760e915e73d9875734c820e09dfdecdc8fc348c92fc808af5317dec616c0-light.svg) ![RDS 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/f898e3eb71e66fb12a5799bc42030ffc660a699f52da2b5beeedac6326a6d1dc-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Primary allocated compute (vCPU-hours/month) | RDS 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 | 129.94 | PostgreSQL Flexible Server (one copy) | 141.44 | 11.50 | | 1,460 | 129.94 | PostgreSQL Flexible Server (two copies) | 282.88 | 152.94 | | 2,920 | 259.88 | PostgreSQL Flexible Server (one copy) | 271.38 | 11.50 | | 2,920 | 259.88 | PostgreSQL Flexible Server (two copies) | 542.76 | 282.88 | | 5,840 | 519.76 | PostgreSQL Flexible Server (one copy) | 531.26 | 11.50 | | 5,840 | 519.76 | PostgreSQL Flexible Server (two copies) | 1,062.52 | 542.76 | | 11,680 | 1,039.52 | PostgreSQL Flexible Server (one copy) | 1,051.02 | 11.50 | | 11,680 | 1,039.52 | PostgreSQL Flexible Server (two copies) | 2,102.04 | 1,062.52 | | 23,360 | 2,079.04 | PostgreSQL Flexible Server (one copy) | 2,090.54 | 11.50 | | 23,360 | 2,079.04 | PostgreSQL Flexible Server (two copies) | 4,181.08 | 2,102.04 | | 46,720 | 4,158.08 | PostgreSQL Flexible Server (one copy) | 4,169.58 | 11.50 | | 46,720 | 4,158.08 | PostgreSQL Flexible Server (two copies) | 8,339.16 | 4,181.08 | 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.089 | 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.115 | 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.089 | 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.115 | 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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-d1ce786dca96f39d19183d1841f6720bd4461047` / `2026-10-22.planning.2`. Curve: `workload-1`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices). ##### RDS PostgreSQL · Stored data Feature: RDS PostgreSQL. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD. ![RDS 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/2e60571f8374ba04259e6d772606e72f10ea1cd41465b26ae5f51c4079bc78b4-light.svg) ![RDS 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/d7a652c22f6d00b79ddf92c90bad54f92fad282a4f0931606777cbac711f3a8b-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Stored data (GiB-month) | RDS 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.15 | PostgreSQL Flexible Server (one copy) | 141.44 | 140.29 | | 10 | 1.15 | PostgreSQL Flexible Server (two copies) | 282.88 | 281.73 | | 100 | 11.50 | PostgreSQL Flexible Server (one copy) | 147.19 | 135.69 | | 100 | 11.50 | PostgreSQL Flexible Server (two copies) | 294.38 | 282.88 | | 1,000 | 115.00 | PostgreSQL Flexible Server (one copy) | 276.57 | 161.57 | | 1,000 | 115.00 | PostgreSQL Flexible Server (two copies) | 553.13 | 438.13 | | 10,000 | 1,150.00 | PostgreSQL Flexible Server (one copy) | 1,570.32 | 420.32 | | 10,000 | 1,150.00 | PostgreSQL Flexible Server (two copies) | 3,140.63 | 1,990.63 | | 100,000 | 11,500.00 | PostgreSQL Flexible Server (one copy) | Unpriced | Unavailable | | 100,000 | 11,500.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.089 | 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.115 | 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.089 | 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.115 | 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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-d1ce786dca96f39d19183d1841f6720bd4461047` / `2026-10-22.planning.2`. Curve: `workload-2`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices). ##### RDS PostgreSQL · Database writes Feature: RDS PostgreSQL. Estimated monthly service charges by Database writes. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD. ![RDS 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/22755d6be8cacf492228dadd19355a4153876366f4659161f344dfe60ce08f74-light.svg) ![RDS 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/9b4e69cd8918428b343bd4683294b3f4ebdd19aa98c5c33afa8f6fd166be4d48-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Database writes (per second) | RDS 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.089 | 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.115 | 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.089 | 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.115 | 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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-d1ce786dca96f39d19183d1841f6720bd4461047` / `2026-10-22.planning.2`. Curve: `workload-3`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Azure Retail Prices API](https://prices.azure.com/api/retail/prices). **RDS 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.089 | USD/vCPU-hours | | Origin list price · Primary memory | 0 | USD/GiB-hours | | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Origin list price · Database reads | 0 | USD/operations | | Origin list price · Database writes | 0 | USD/operations | | Target CPU / source CPU | 1 | multiplier | | Target RAM / source RAM | 1 | multiplier | | Target disk / source disk | 1 | multiplier | | Target price guess · read | 0 | USD/read | | Target price guess · write | 0 | USD/write | | Target price guess · provider operation | 0 | USD/provider operation | | Target list price · GiB-month | 0.115 | USD/GiB-month | | Target price guess · published GiB | 0 | USD/published GiB | | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Target list price · network GiB | 0.087 | USD/network GiB | | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Target list price · vCPU-hour | 0.053 | USD/vCPU-hour | | Target list price · GiB-hour | 0.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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-d1ce786dca96f39d19183d1841f6720bd4461047` / `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. ![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. * **RDS-specific SQL helpers are not supported.** SQL helpers for AWS integrations do not exist on DigitalOcean. Use the selected engine's own SQL functions. #### Other considerations **Moving data.** Copy existing data with the engine's dump and restore tools or a supported online migration workflow. Check the schema, users, required extensions or plugins, and application queries before you switch connection settings. **Who operates what.** DigitalOcean operates the database service. The customer controls the plan, access rules, application cutover and permissions for backend monitoring. #### Example monthly charges This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include. ##### RDS PostgreSQL · Primary allocated compute Feature: RDS PostgreSQL. Estimated monthly service charges by Primary allocated compute. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: nyc; currency: USD. ![RDS 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/55b2600412b31ae36bda51ee8eabde1d7dc349469b87c191f21539daeef433d7-light.svg) ![RDS 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/1fc9818803e51bb1dea8bc830f61457d8a1e5895d06efd4bdcaef681c78f94bf-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Primary allocated compute (vCPU-hours/month) | RDS 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 | 129.94 | PostgreSQL (one copy) | 141.50 | 11.56 | | 1,460 | 129.94 | PostgreSQL (two copies) | 283.00 | 153.06 | | 2,920 | 259.88 | PostgreSQL (one copy) | 271.50 | 11.62 | | 2,920 | 259.88 | PostgreSQL (two copies) | 543.00 | 283.12 | | 5,840 | 519.76 | PostgreSQL (one copy) | 531.50 | 11.74 | | 5,840 | 519.76 | PostgreSQL (two copies) | 1,063.00 | 543.24 | | 11,680 | 1,039.52 | PostgreSQL (one copy) | 1,051.50 | 11.98 | | 11,680 | 1,039.52 | PostgreSQL (two copies) | 2,103.00 | 1,063.48 | | 23,360 | 2,079.04 | PostgreSQL (one copy) | 2,091.50 | 12.46 | | 23,360 | 2,079.04 | PostgreSQL (two copies) | 4,183.00 | 2,103.96 | | 46,720 | 4,158.08 | PostgreSQL (one copy) | Unpriced | Unavailable | | 46,720 | 4,158.08 | 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.089 | 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.115 | 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.089 | 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.115 | 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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-c1326d028d5f400188fe5bff1acd3f0355a2ffff` / `2026-10-22.planning.2`. Curve: `workload-1`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [DigitalOcean Managed Databases pricing](https://www.digitalocean.com/pricing/managed-databases), [DigitalOcean Managed Databases pricing](https://docs.digitalocean.com/products/databases/postgresql/details/pricing/). ##### RDS PostgreSQL · Stored data Feature: RDS PostgreSQL. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: nyc; currency: USD. ![RDS 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/f0914daa83ba79b8498cb5a8914b71d72b9742c651a6fc012c7f4393cbcc892c-light.svg) ![RDS 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/b02ce6514e15d105b7923950efe596fc67b4a9dcdf91a38f0693cc1b2ef4c38d-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Stored data (GiB-month) | RDS 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.15 | PostgreSQL (one copy) | 141.50 | 140.35 | | 10 | 1.15 | PostgreSQL (two copies) | 283.00 | 281.85 | | 100 | 11.50 | PostgreSQL (one copy) | 147.25 | 135.75 | | 100 | 11.50 | PostgreSQL (two copies) | 294.50 | 283.00 | | 1,000 | 115.00 | PostgreSQL (one copy) | 276.63 | 161.63 | | 1,000 | 115.00 | PostgreSQL (two copies) | 553.25 | 438.25 | | 10,000 | 1,150.00 | PostgreSQL (one copy) | 1,570.38 | 420.38 | | 10,000 | 1,150.00 | PostgreSQL (two copies) | 3,140.75 | 1,990.75 | | 100,000 | 11,500.00 | PostgreSQL (one copy) | Unpriced | Unavailable | | 100,000 | 11,500.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.089 | 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.115 | 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.089 | 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.115 | 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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-c1326d028d5f400188fe5bff1acd3f0355a2ffff` / `2026-10-22.planning.2`. Curve: `workload-2`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [DigitalOcean Managed Databases pricing](https://www.digitalocean.com/pricing/managed-databases), [DigitalOcean Managed Databases pricing](https://docs.digitalocean.com/products/databases/postgresql/details/pricing/). ##### RDS PostgreSQL · Database writes Feature: RDS PostgreSQL. Estimated monthly service charges by Database writes. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: nyc; currency: USD. ![RDS 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/6fbda811b9a5f9a9d30bf1c0b06a237eff6f7fa9892f1ddb29b0b4eb7e1a79c9-light.svg) ![RDS 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/66cc834f2c25f061dad794cdbc25021b0152fdf95c8ac042a945b1c18db451c8-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Database writes (per second) | RDS 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.089 | 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.115 | 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.089 | 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.115 | 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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-c1326d028d5f400188fe5bff1acd3f0355a2ffff` / `2026-10-22.planning.2`. Curve: `workload-3`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [DigitalOcean Managed Databases pricing](https://www.digitalocean.com/pricing/managed-databases), [DigitalOcean Managed Databases pricing](https://docs.digitalocean.com/products/databases/postgresql/details/pricing/). **RDS 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.089 | USD/vCPU-hours | | Origin list price · Primary memory | 0 | USD/GiB-hours | | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Origin list price · Database reads | 0 | USD/operations | | Origin list price · Database writes | 0 | USD/operations | | Target CPU / source CPU | 1 | multiplier | | Target RAM / source RAM | 1 | multiplier | | Target disk / source disk | 1 | multiplier | | Target price guess · read | 0 | USD/read | | Target price guess · write | 0 | USD/write | | Target price guess · provider operation | 0 | USD/provider operation | | Target list price · GiB-month | 0.115 | USD/GiB-month | | Target price guess · published GiB | 0 | USD/published GiB | | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Target price guess · network GiB | 0 | USD/network GiB | | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Target list price · vCPU-hour | 0.0547945 | USD/vCPU-hour | | Target list price · GiB-hour | 0.00856164 | USD/GiB-hour | | Target price guess · resource-hour | 0 | USD/resource-hour | | Target price guess · resource-month | 0 | USD/resource-month | | Target price guess · input token | 0 | USD/input token | | Target price guess · output token | 0 | USD/output token | | Target monthly base charge | 0 | USD/month | | Target service minimum | 135.75 | USD/month | | Minimum primary CPU | 2 | vCPU | | Minimum primary RAM | 8 | GiB | | Minimum primary disk | 100 | GiB | | Additional full-price standby copy | 0 | 0 or 1 | | Allocated share of provisioned cost | 1 | fraction | | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Planning peak / mean work | 2 | multiplier | | Planning primary CPU utilization | 0.7 | fraction | | Resident state reserved in RAM | 0.1 | fraction | | Planning disk utilization | 0.8 | fraction | | Maintenance and log disk reserve | 20 | GiB | | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Dependent object sink write price guess | 0.000005 | USD/write | | Primary compute | 0 | vCPU-hours | | Primary memory | 0 | GiB-hours | | Primary provisioned storage | 0 | GiB-month | | Database reads | 0 | operations | | Database writes | 0 | operations | * Translated reads: 0 operations. * Translated writes: 0 operations. * Translated resident physical data: 0 GiB-month. * Native provider operations: 0 operations. * Published payload: 0 GiB. * Delivered payload: 0 GiB. * Allocated execution CPU: 0 vCPU-hour. * Allocated execution RAM: 0 GiB-hour. * Independent resource allocation: 0 resource-hour. * Independent inventory: 0 resource-month. * Input tokens: 0 tokens. * Output tokens: 0 tokens. * Billable network: 0 GiB. * Dependent object sink retained data: 0 GiB-month. * Dependent object sink writes: 0 writes. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * DigitalOcean Managed 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-c1326d028d5f400188fe5bff1acd3f0355a2ffff` / `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 integration SQL: aws\_s3.\*, aws\_lambda.invoke, rds\_tools | SQL functions | Out of scope | Full surface | RDS extension functions with no counterpart on vanilla PostgreSQL; a query calling them fails | | pgwire protocol (application SQL) | Wire protocol | Supported | Common | same PostgreSQL engine; application SQL is unchanged | #### How it works Your application's PostgreSQL driver connects directly to Cloud SQL for PostgreSQL. These database requests are the **data plane**. The driver and the PostgreSQL wire protocol stay the same, and Tensor9 does not proxy or translate 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 RDS for PostgreSQL and Cloud SQL both run PostgreSQL. Your SQL, drivers, object-relational mappers (ORMs), prepared statements, data types and transaction behavior stay the same. Your application connects directly to the database. RDS adds SQL functions for importing and exporting through S3 and for invoking Lambda from a query. These AWS-specific 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 instance, take a snapshot, restore to a point in time, add or promote a read replica, trigger a failover, stop and start, change the instance class or a parameter. 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 in-region and cross-region, manual failover, stop / start, and machine-type, storage and database-flag updates. With Max, your tools call `CreateDBInstance` and `DeleteDBInstance` through the RDS adapter to create and remove a database on Cloud SQL. Tensor9 keeps a durable record of each logical database and reconciles Cloud SQL with it: it records each accepted request, then creates or removes the Cloud SQL resources in the background. Call `DescribeDBInstances` to follow the status and get the database endpoint. Your application's SQL connection still goes directly to the database. With the Infrastructure-only option, Tensor9 compiles the declared database 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+cmVwbGljYSDCtyBmYWlsb3ZlciDCtyBzdG9wIC8gc3RhcnQ8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iMTE2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+aW5zdGFuY2UgY2xhc3MgwrcgcGFyYW1ldGVyczwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSIxNDIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiIj5zYW1lIHJlcXVlc3QgLyByZXNwb25zZSBzaGFwZXM8L3RleHQ+CjxsaW5lIHgxPSIyNTIiIHkxPSI3NCIgeDI9IjMxNCIgeTI9Ijc0IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhjLXJkcy1jbG91ZC1zcWwtYWRtaW4tYXBpKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxsaW5lIHgxPSIzMTgiIHkxPSIxMjgiIHgyPSIyNTYiIHkyPSIxMjgiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWNsb3VkLXNxbC1hZG1pbi1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHJlY3QgeD0iMzE4IiB5PSI1NCIgd2lkdGg9IjIwNCIgaGVpZ2h0PSI4OCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI0MjAiIHk9Ijk0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC1zaXplOjEycHgiPlRlbnNvcjk8L3RleHQ+CiAgPHRleHQgeD0iNDIwIiB5PSIxMTIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPnNlcnZpY2UgYWRhcHRlcjwvdGV4dD4KPGxpbmUgeDE9IjUyMiIgeTE9Ijc0IiB4Mj0iNTg0IiB5Mj0iNzQiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWNsb3VkLXNxbC1hZG1pbi1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPGxpbmUgeDE9IjU4OCIgeTE9IjEyOCIgeDI9IjUyNiIgeTI9IjEyOCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtY2xvdWQtc3FsLWFkbWluLWFwaSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8cmVjdCB4PSI1ODgiIHk9IjM0IiB3aWR0aD0iMjMyIiBoZWlnaHQ9IjEyOCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSI3MDQiIHk9IjYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjEycHgiPkNsb3VkIFNRTCBhZG1pbiBBUEk8L3RleHQ+Cjx0ZXh0IHg9IjcwNCIgeT0iOTQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5iYWNrdXBzIMK3IHJlc3RvcmVzIMK3IHJlcGxpY2FzPC90ZXh0Pgo8dGV4dCB4PSI3MDQiIHk9IjExMSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPmZhaWxvdmVyIMK3IHVwZGF0ZXMgwrcgZmxhZ3M8L3RleHQ+Cjwvc3ZnPg==) ![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+cmVwbGljYSDCtyBmYWlsb3ZlciDCtyBzdG9wIC8gc3RhcnQ8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iMTE2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+aW5zdGFuY2UgY2xhc3MgwrcgcGFyYW1ldGVyczwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSIxNDIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4Ij5zYW1lIHJlcXVlc3QgLyByZXNwb25zZSBzaGFwZXM8L3RleHQ+CjxsaW5lIHgxPSIyNTIiIHkxPSI3NCIgeDI9IjMxNCIgeTI9Ijc0IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhjLXJkcy1jbG91ZC1zcWwtYWRtaW4tYXBpKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxsaW5lIHgxPSIzMTgiIHkxPSIxMjgiIHgyPSIyNTYiIHkyPSIxMjgiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWNsb3VkLXNxbC1hZG1pbi1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHJlY3QgeD0iMzE4IiB5PSI1NCIgd2lkdGg9IjIwNCIgaGVpZ2h0PSI4OCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSI0MjAiIHk9Ijk0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC1zaXplOjEycHgiPlRlbnNvcjk8L3RleHQ+CiAgPHRleHQgeD0iNDIwIiB5PSIxMTIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPnNlcnZpY2UgYWRhcHRlcjwvdGV4dD4KPGxpbmUgeDE9IjUyMiIgeTE9Ijc0IiB4Mj0iNTg0IiB5Mj0iNzQiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWNsb3VkLXNxbC1hZG1pbi1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPGxpbmUgeDE9IjU4OCIgeTE9IjEyOCIgeDI9IjUyNiIgeTI9IjEyOCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtY2xvdWQtc3FsLWFkbWluLWFwaSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8cmVjdCB4PSI1ODgiIHk9IjM0IiB3aWR0aD0iMjMyIiBoZWlnaHQ9IjEyOCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSI3MDQiIHk9IjYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjEycHgiPkNsb3VkIFNRTCBhZG1pbiBBUEk8L3RleHQ+Cjx0ZXh0IHg9IjcwNCIgeT0iOTQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5iYWNrdXBzIMK3IHJlc3RvcmVzIMK3IHJlcGxpY2FzPC90ZXh0Pgo8dGV4dCB4PSI3MDQiIHk9IjExMSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPmZhaWxvdmVyIMK3IHVwZGF0ZXMgwrcgZmxhZ3M8L3RleHQ+Cjwvc3ZnPg==) Tensor9 translates RDS management requests to the backend API and returns RDS responses. #### Limitations Where RDS and Cloud SQL differ * **Deleting a database behaves differently: it is asynchronous and keeps no final snapshot.** `DeleteDBInstance` requires `SkipFinalSnapshot=true` and does not keep automated backups. Deletion protection must be off. The database stays in the deleting state until its Cloud SQL resources are gone; if teardown fails, the status reports the failure, not a successful removal. * **DB subnet groups behave differently: they choose where the private endpoint goes.** An explicit DB subnet group keeps its subnets from one VPC across at least two availability zones. Tensor9 always picks the same subnet from it and places the private connection endpoint there; Google runs the database compute in its own service network. That subnet must match the configured Google Cloud project, region, network and IPv4 range. Without an explicit group, the configured network is used; Tensor9 does not create an AWS default subnet group. * **You must set up private services access and client access yourself.** The database is ready only once its private connection is accepted and, for public access, its public address exists. Public access with an explicit subnet group also needs private services access already set up on that VPC, and the configured client allowlist. Tensor9 does not create shared private services access, translate AWS security groups or provide AWS split-horizon DNS. * **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. Default groups are read-only. Changes marked pending-reboot wait for `RebootDBInstance`; immediate changes that need a restart are rejected. A group that is attached cannot be deleted or replaced, and source formulas are not supported. * **RDS-specific settings are not supported.** The CA certificate, Enhanced Monitoring, processor features and Kerberos / AD domain join have no Cloud SQL equivalent. #### Other considerations **Migration.** Move existing data with a logical dump and restore, or use logical replication to shorten the cutover pause. Check the selected PostgreSQL version and the extensions you need, and switch application connections only after you have checked the copied data. **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. ##### Monthly database allocation cost · RDS Single-AZ Reference monthly service charges by Primary vCPUs. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. ![Monthly database allocation cost · RDS Single-AZ: monthly service charges by Primary vCPUs. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/143d01995d26d441153004089517ad5df804f9299d481c341af4119915e30447-light.svg) ![Monthly database allocation cost · RDS Single-AZ: monthly service charges by Primary vCPUs. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/7404d12ae0452ec9d32ec8fcb67353fa600ea8c4c2c03a81022104c4f6b4d979-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 vCPUs (vCPU) | RDS PostgreSQL | Target scenario | Cloud SQL for PostgreSQL | Difference | | -: | -: | - | -: | -: | | 2 | 141.44 | Cloud SQL for PostgreSQL (zonal) | 118.18 | -23.26 | | 2 | 141.44 | Cloud SQL for PostgreSQL (HA) | 236.36 | 94.92 | | 4 | 271.38 | Cloud SQL for PostgreSQL (zonal) | 219.36 | -52.02 | | 4 | 271.38 | Cloud SQL for PostgreSQL (HA) | 438.71 | 167.33 | | 8 | 531.26 | Cloud SQL for PostgreSQL (zonal) | 421.71 | -109.55 | | 8 | 531.26 | Cloud SQL for PostgreSQL (HA) | 843.42 | 312.16 | | 16 | 1,051.02 | Cloud SQL for PostgreSQL (zonal) | 826.42 | -224.60 | | 16 | 1,051.02 | Cloud SQL for PostgreSQL (HA) | 1,652.85 | 601.83 | | 32 | 2,090.54 | Cloud SQL for PostgreSQL (zonal) | 1,635.85 | -454.69 | | 32 | 2,090.54 | Cloud SQL for PostgreSQL (HA) | 3,271.70 | 1,181.16 | **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | Cloud SQL for PostgreSQL (zonal) | RDS one-standby Multi-AZ | 0 | 0 = Single-AZ, 1 = Multi-AZ | | Cloud SQL for PostgreSQL (zonal) | Cloud SQL vCPUs | 2 | vCPU | | Cloud SQL for PostgreSQL (zonal) | Cloud SQL memory | 8 | GiB | | Cloud SQL for PostgreSQL (zonal) | Provisioned Cloud SQL SSD | 100 | GiB | | Cloud SQL for PostgreSQL (zonal) | Cloud SQL high availability | 0 | 0 = zonal, 1 = HA | | Cloud SQL for PostgreSQL (zonal) | Share of database cost allocated here | 1 | fraction | | Cloud SQL for PostgreSQL (HA) | RDS one-standby Multi-AZ | 0 | 0 = Single-AZ, 1 = Multi-AZ | | Cloud SQL for PostgreSQL (HA) | Cloud SQL vCPUs | 2 | vCPU | | Cloud SQL for PostgreSQL (HA) | Cloud SQL memory | 8 | GiB | | Cloud SQL for PostgreSQL (HA) | Provisioned Cloud SQL SSD | 100 | GiB | | Cloud SQL for PostgreSQL (HA) | Cloud SQL high availability | 1 | 0 = zonal, 1 = HA | | Cloud SQL for PostgreSQL (HA) | Share of database cost allocated here | 1 | fraction | * RDS PostgreSQL db.m6i family in us-east-1, Single-AZ; Cloud SQL Enterprise PostgreSQL in us-central1. 4 GiB memory per primary vCPU, 100 GiB provisioned storage and 730 running hours on both sides. Equal resource counts are a configuration comparison, not evidence of equal throughput or availability. * Monthly AWS source usage in us-east-1, priced at the 2026-10-18 reference list rates before free allowances, discounts, credits and tax; not the uploaded invoice total. Rates as of 2026-10-18: 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. * Cloud SQL configuration pricing only: throughput, peak load, latency and storage suitability are unqualified. No capacity benchmark is implied. * 730 running hours per modeled month. Dedicated database compute and disk cost money even with zero origin traffic. * Shared database allocation is a caller assumption. Do not sum a full database charge for every adapter sharing that database. * Source configurations are continuously running PostgreSQL db.m6i instances with 2, 4, 8, 16 or 32 primary vCPUs and 4 GiB RAM per vCPU. Architecture and resource counts do not prove equal performance. * Application traffic uses native PostgreSQL pgwire directly; no adapter proxy compute is required in that data path. Optional hosting and Tensor9 allocations still require an explicit selection. * Source primary vCPU-hours and storage exclude the standby; rdsHa adds one copy. Legacy source dollar inputs include the selected standby charge. * Source usage is priced at reference rates; source lines are not actual invoice charges. Free or discounted usage still consumes target resources. * RDS PostgreSQL pricing: [https://aws.amazon.com/rds/postgresql/pricing/](https://aws.amazon.com/rds/postgresql/pricing/) * AWS RDS us-east-1 reference price list: [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 Enterprise PostgreSQL pricing: [https://cloud.google.com/sql/pricing/](https://cloud.google.com/sql/pricing/) Cost scope: Modeled monthly service usage and selected database allocation; adapter hosting and Tensor9 fees only when explicitly supplied. Excluded costs and workload features: * Free allowances, negotiated discounts, credits, tax and one-time migration charges. * Charges not listed in the breakdown, including additional network transfer, backups and encryption/KMS. * Application compute changes, operational labor and portfolio-wide sharing or deduplication of infrastructure. * Aurora, other database engines or instance families, RDS Proxy, extra gp3 IOPS/throughput, replicas and Extended Support. Rate snapshot: 2026-10-18. Model: `rds-postgresql-cloudsql` / `2026-10-18.4`. Curve: `vcpu-rds-ha-0`. Sources: [RDS PostgreSQL pricing](https://aws.amazon.com/rds/postgresql/pricing/), [AWS RDS us-east-1 reference price list](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Cloud SQL Enterprise PostgreSQL pricing](https://cloud.google.com/sql/pricing/). ##### Monthly storage allocation cost · RDS Single-AZ Reference monthly service charges by Primary provisioned storage. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. ![Monthly storage allocation cost · RDS Single-AZ: monthly service charges by Primary provisioned storage. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/ba3a3997d30d62d8829cee92a9792edec11e2580b75b97d09fe13b23ea2b6c10-light.svg) ![Monthly storage allocation cost · RDS Single-AZ: monthly service charges by Primary provisioned storage. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/dd143e70d861583e30da54100ad1be4ca455f93f59c678cacdba33af4d026cbf-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 provisioned storage (GiB) | RDS PostgreSQL | Target scenario | Cloud SQL for PostgreSQL | Difference | | -: | -: | - | -: | -: | | 20 | 132.24 | Cloud SQL for PostgreSQL (zonal) | 104.58 | -27.66 | | 20 | 132.24 | Cloud SQL for PostgreSQL (HA) | 209.16 | 76.92 | | 100 | 141.44 | Cloud SQL for PostgreSQL (zonal) | 118.18 | -23.26 | | 100 | 141.44 | Cloud SQL for PostgreSQL (HA) | 236.36 | 94.92 | | 1,000 | 244.94 | Cloud SQL for PostgreSQL (zonal) | 271.18 | 26.24 | | 1,000 | 244.94 | Cloud SQL for PostgreSQL (HA) | 542.36 | 297.42 | | 10,000 | 1,279.94 | Cloud SQL for PostgreSQL (zonal) | 1,801.18 | 521.24 | | 10,000 | 1,279.94 | Cloud SQL for PostgreSQL (HA) | 3,602.36 | 2,322.42 | | 65,536 | 7,666.58 | Cloud SQL for PostgreSQL (zonal) | 11,242.30 | 3,575.72 | | 65,536 | 7,666.58 | Cloud SQL for PostgreSQL (HA) | 22,484.60 | 14,818.02 | **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | Cloud SQL for PostgreSQL (zonal) | RDS one-standby Multi-AZ | 0 | 0 = Single-AZ, 1 = Multi-AZ | | Cloud SQL for PostgreSQL (zonal) | Cloud SQL vCPUs | 2 | vCPU | | Cloud SQL for PostgreSQL (zonal) | Cloud SQL memory | 8 | GiB | | Cloud SQL for PostgreSQL (zonal) | Provisioned Cloud SQL SSD | 20 | GiB | | Cloud SQL for PostgreSQL (zonal) | Cloud SQL high availability | 0 | 0 = zonal, 1 = HA | | Cloud SQL for PostgreSQL (zonal) | Share of database cost allocated here | 1 | fraction | | Cloud SQL for PostgreSQL (HA) | RDS one-standby Multi-AZ | 0 | 0 = Single-AZ, 1 = Multi-AZ | | Cloud SQL for PostgreSQL (HA) | Cloud SQL vCPUs | 2 | vCPU | | Cloud SQL for PostgreSQL (HA) | Cloud SQL memory | 8 | GiB | | Cloud SQL for PostgreSQL (HA) | Provisioned Cloud SQL SSD | 20 | GiB | | Cloud SQL for PostgreSQL (HA) | Cloud SQL high availability | 1 | 0 = zonal, 1 = HA | | Cloud SQL for PostgreSQL (HA) | Share of database cost allocated here | 1 | fraction | * Two primary vCPUs and 8 GiB memory, with 730 running hours; RDS Single-AZ versus Cloud SQL zonal and HA. RDS uses baseline gp3 and Cloud SQL uses SSD. IOPS, throughput and backup requirements remain unqualified and are excluded. * Monthly AWS source usage in us-east-1, priced at the 2026-10-18 reference list rates before free allowances, discounts, credits and tax; not the uploaded invoice total. Rates as of 2026-10-18: 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. * Cloud SQL configuration pricing only: throughput, peak load, latency and storage suitability are unqualified. No capacity benchmark is implied. * 730 running hours per modeled month. Dedicated database compute and disk cost money even with zero origin traffic. * Shared database allocation is a caller assumption. Do not sum a full database charge for every adapter sharing that database. * Source configurations are continuously running PostgreSQL db.m6i instances with 2, 4, 8, 16 or 32 primary vCPUs and 4 GiB RAM per vCPU. Architecture and resource counts do not prove equal performance. * Application traffic uses native PostgreSQL pgwire directly; no adapter proxy compute is required in that data path. Optional hosting and Tensor9 allocations still require an explicit selection. * Source primary vCPU-hours and storage exclude the standby; rdsHa adds one copy. Legacy source dollar inputs include the selected standby charge. * Source usage is priced at reference rates; source lines are not actual invoice charges. Free or discounted usage still consumes target resources. * RDS PostgreSQL pricing: [https://aws.amazon.com/rds/postgresql/pricing/](https://aws.amazon.com/rds/postgresql/pricing/) * AWS RDS us-east-1 reference price list: [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 Enterprise PostgreSQL pricing: [https://cloud.google.com/sql/pricing/](https://cloud.google.com/sql/pricing/) Cost scope: Modeled monthly service usage and selected database allocation; adapter hosting and Tensor9 fees only when explicitly supplied. Excluded costs and workload features: * Free allowances, negotiated discounts, credits, tax and one-time migration charges. * Charges not listed in the breakdown, including additional network transfer, backups and encryption/KMS. * Application compute changes, operational labor and portfolio-wide sharing or deduplication of infrastructure. * Aurora, other database engines or instance families, RDS Proxy, extra gp3 IOPS/throughput, replicas and Extended Support. Rate snapshot: 2026-10-18. Model: `rds-postgresql-cloudsql` / `2026-10-18.4`. Curve: `storage-rds-ha-0`. Sources: [RDS PostgreSQL pricing](https://aws.amazon.com/rds/postgresql/pricing/), [AWS RDS us-east-1 reference price list](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Cloud SQL Enterprise PostgreSQL pricing](https://cloud.google.com/sql/pricing/). ##### Monthly database allocation cost · RDS Multi-AZ, one standby Reference monthly service charges by Primary vCPUs. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. ![Monthly database allocation cost · RDS Multi-AZ, one standby: monthly service charges by Primary vCPUs. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/4370fa386ba1c44c92693f806782812fe64fa6f1c7dc313c05861aac139435e6-light.svg) ![Monthly database allocation cost · RDS Multi-AZ, one standby: monthly service charges by Primary vCPUs. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/6905d4fd3b9facccc69b60d0f235d380d6b2f486723e0ebc9dc9c576f46b3bd8-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 vCPUs (vCPU) | RDS PostgreSQL | Target scenario | Cloud SQL for PostgreSQL | Difference | | -: | -: | - | -: | -: | | 2 | 282.88 | Cloud SQL for PostgreSQL (zonal) | 118.18 | -164.70 | | 2 | 282.88 | Cloud SQL for PostgreSQL (HA) | 236.36 | -46.52 | | 4 | 542.76 | Cloud SQL for PostgreSQL (zonal) | 219.36 | -323.40 | | 4 | 542.76 | Cloud SQL for PostgreSQL (HA) | 438.71 | -104.05 | | 8 | 1,062.52 | Cloud SQL for PostgreSQL (zonal) | 421.71 | -640.81 | | 8 | 1,062.52 | Cloud SQL for PostgreSQL (HA) | 843.42 | -219.10 | | 16 | 2,102.04 | Cloud SQL for PostgreSQL (zonal) | 826.42 | -1,275.62 | | 16 | 2,102.04 | Cloud SQL for PostgreSQL (HA) | 1,652.85 | -449.19 | | 32 | 4,181.08 | Cloud SQL for PostgreSQL (zonal) | 1,635.85 | -2,545.23 | | 32 | 4,181.08 | Cloud SQL for PostgreSQL (HA) | 3,271.70 | -909.38 | **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | Cloud SQL for PostgreSQL (zonal) | RDS one-standby Multi-AZ | 1 | 0 = Single-AZ, 1 = Multi-AZ | | Cloud SQL for PostgreSQL (zonal) | Cloud SQL vCPUs | 2 | vCPU | | Cloud SQL for PostgreSQL (zonal) | Cloud SQL memory | 8 | GiB | | Cloud SQL for PostgreSQL (zonal) | Provisioned Cloud SQL SSD | 100 | GiB | | Cloud SQL for PostgreSQL (zonal) | Cloud SQL high availability | 0 | 0 = zonal, 1 = HA | | Cloud SQL for PostgreSQL (zonal) | Share of database cost allocated here | 1 | fraction | | Cloud SQL for PostgreSQL (HA) | RDS one-standby Multi-AZ | 1 | 0 = Single-AZ, 1 = Multi-AZ | | Cloud SQL for PostgreSQL (HA) | Cloud SQL vCPUs | 2 | vCPU | | Cloud SQL for PostgreSQL (HA) | Cloud SQL memory | 8 | GiB | | Cloud SQL for PostgreSQL (HA) | Provisioned Cloud SQL SSD | 100 | GiB | | Cloud SQL for PostgreSQL (HA) | Cloud SQL high availability | 1 | 0 = zonal, 1 = HA | | Cloud SQL for PostgreSQL (HA) | Share of database cost allocated here | 1 | fraction | * RDS PostgreSQL db.m6i family in us-east-1, Multi-AZ, one standby; Cloud SQL Enterprise PostgreSQL in us-central1. 4 GiB memory per primary vCPU, 100 GiB provisioned storage and 730 running hours on both sides. Equal resource counts are a configuration comparison, not evidence of equal throughput or availability. * Monthly AWS source usage in us-east-1, priced at the 2026-10-18 reference list rates before free allowances, discounts, credits and tax; not the uploaded invoice total. Rates as of 2026-10-18: 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. * Cloud SQL configuration pricing only: throughput, peak load, latency and storage suitability are unqualified. No capacity benchmark is implied. * 730 running hours per modeled month. Dedicated database compute and disk cost money even with zero origin traffic. * Shared database allocation is a caller assumption. Do not sum a full database charge for every adapter sharing that database. * Source configurations are continuously running PostgreSQL db.m6i instances with 2, 4, 8, 16 or 32 primary vCPUs and 4 GiB RAM per vCPU. Architecture and resource counts do not prove equal performance. * Application traffic uses native PostgreSQL pgwire directly; no adapter proxy compute is required in that data path. Optional hosting and Tensor9 allocations still require an explicit selection. * Source primary vCPU-hours and storage exclude the standby; rdsHa adds one copy. Legacy source dollar inputs include the selected standby charge. * Source usage is priced at reference rates; source lines are not actual invoice charges. Free or discounted usage still consumes target resources. * RDS PostgreSQL pricing: [https://aws.amazon.com/rds/postgresql/pricing/](https://aws.amazon.com/rds/postgresql/pricing/) * AWS RDS us-east-1 reference price list: [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 Enterprise PostgreSQL pricing: [https://cloud.google.com/sql/pricing/](https://cloud.google.com/sql/pricing/) Cost scope: Modeled monthly service usage and selected database allocation; adapter hosting and Tensor9 fees only when explicitly supplied. Excluded costs and workload features: * Free allowances, negotiated discounts, credits, tax and one-time migration charges. * Charges not listed in the breakdown, including additional network transfer, backups and encryption/KMS. * Application compute changes, operational labor and portfolio-wide sharing or deduplication of infrastructure. * Aurora, other database engines or instance families, RDS Proxy, extra gp3 IOPS/throughput, replicas and Extended Support. Rate snapshot: 2026-10-18. Model: `rds-postgresql-cloudsql` / `2026-10-18.4`. Curve: `vcpu-rds-ha-1`. Sources: [RDS PostgreSQL pricing](https://aws.amazon.com/rds/postgresql/pricing/), [AWS RDS us-east-1 reference price list](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Cloud SQL Enterprise PostgreSQL pricing](https://cloud.google.com/sql/pricing/). ##### Monthly storage allocation cost · RDS Multi-AZ, one standby Reference monthly service charges by Primary provisioned storage. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. ![Monthly storage allocation cost · RDS Multi-AZ, one standby: monthly service charges by Primary provisioned storage. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/ba452590aebb29c3d35344a96da104b4c9414806de8549338dcc467060babb39-light.svg) ![Monthly storage allocation cost · RDS Multi-AZ, one standby: monthly service charges by Primary provisioned storage. Exact values are in the following table.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/82024ed07daea26d6e8d045ae3023994059929fee617d6539de9720294223c07-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 provisioned storage (GiB) | RDS PostgreSQL | Target scenario | Cloud SQL for PostgreSQL | Difference | | -: | -: | - | -: | -: | | 20 | 264.48 | Cloud SQL for PostgreSQL (zonal) | 104.58 | -159.90 | | 20 | 264.48 | Cloud SQL for PostgreSQL (HA) | 209.16 | -55.32 | | 100 | 282.88 | Cloud SQL for PostgreSQL (zonal) | 118.18 | -164.70 | | 100 | 282.88 | Cloud SQL for PostgreSQL (HA) | 236.36 | -46.52 | | 1,000 | 489.88 | Cloud SQL for PostgreSQL (zonal) | 271.18 | -218.70 | | 1,000 | 489.88 | Cloud SQL for PostgreSQL (HA) | 542.36 | 52.48 | | 10,000 | 2,559.88 | Cloud SQL for PostgreSQL (zonal) | 1,801.18 | -758.70 | | 10,000 | 2,559.88 | Cloud SQL for PostgreSQL (HA) | 3,602.36 | 1,042.48 | | 65,536 | 15,333.16 | Cloud SQL for PostgreSQL (zonal) | 11,242.30 | -4,090.86 | | 65,536 | 15,333.16 | Cloud SQL for PostgreSQL (HA) | 22,484.60 | 7,151.44 | **Curve assumptions** | Target scenario | Assumption | Value | Unit | | - | - | -: | - | | Cloud SQL for PostgreSQL (zonal) | RDS one-standby Multi-AZ | 1 | 0 = Single-AZ, 1 = Multi-AZ | | Cloud SQL for PostgreSQL (zonal) | Cloud SQL vCPUs | 2 | vCPU | | Cloud SQL for PostgreSQL (zonal) | Cloud SQL memory | 8 | GiB | | Cloud SQL for PostgreSQL (zonal) | Provisioned Cloud SQL SSD | 20 | GiB | | Cloud SQL for PostgreSQL (zonal) | Cloud SQL high availability | 0 | 0 = zonal, 1 = HA | | Cloud SQL for PostgreSQL (zonal) | Share of database cost allocated here | 1 | fraction | | Cloud SQL for PostgreSQL (HA) | RDS one-standby Multi-AZ | 1 | 0 = Single-AZ, 1 = Multi-AZ | | Cloud SQL for PostgreSQL (HA) | Cloud SQL vCPUs | 2 | vCPU | | Cloud SQL for PostgreSQL (HA) | Cloud SQL memory | 8 | GiB | | Cloud SQL for PostgreSQL (HA) | Provisioned Cloud SQL SSD | 20 | GiB | | Cloud SQL for PostgreSQL (HA) | Cloud SQL high availability | 1 | 0 = zonal, 1 = HA | | Cloud SQL for PostgreSQL (HA) | Share of database cost allocated here | 1 | fraction | * Two primary vCPUs and 8 GiB memory, with 730 running hours; RDS Multi-AZ, one standby versus Cloud SQL zonal and HA. RDS uses baseline gp3 and Cloud SQL uses SSD. IOPS, throughput and backup requirements remain unqualified and are excluded. * Monthly AWS source usage in us-east-1, priced at the 2026-10-18 reference list rates before free allowances, discounts, credits and tax; not the uploaded invoice total. Rates as of 2026-10-18: 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. * Cloud SQL configuration pricing only: throughput, peak load, latency and storage suitability are unqualified. No capacity benchmark is implied. * 730 running hours per modeled month. Dedicated database compute and disk cost money even with zero origin traffic. * Shared database allocation is a caller assumption. Do not sum a full database charge for every adapter sharing that database. * Source configurations are continuously running PostgreSQL db.m6i instances with 2, 4, 8, 16 or 32 primary vCPUs and 4 GiB RAM per vCPU. Architecture and resource counts do not prove equal performance. * Application traffic uses native PostgreSQL pgwire directly; no adapter proxy compute is required in that data path. Optional hosting and Tensor9 allocations still require an explicit selection. * Source primary vCPU-hours and storage exclude the standby; rdsHa adds one copy. Legacy source dollar inputs include the selected standby charge. * Source usage is priced at reference rates; source lines are not actual invoice charges. Free or discounted usage still consumes target resources. * RDS PostgreSQL pricing: [https://aws.amazon.com/rds/postgresql/pricing/](https://aws.amazon.com/rds/postgresql/pricing/) * AWS RDS us-east-1 reference price list: [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 Enterprise PostgreSQL pricing: [https://cloud.google.com/sql/pricing/](https://cloud.google.com/sql/pricing/) Cost scope: Modeled monthly service usage and selected database allocation; adapter hosting and Tensor9 fees only when explicitly supplied. Excluded costs and workload features: * Free allowances, negotiated discounts, credits, tax and one-time migration charges. * Charges not listed in the breakdown, including additional network transfer, backups and encryption/KMS. * Application compute changes, operational labor and portfolio-wide sharing or deduplication of infrastructure. * Aurora, other database engines or instance families, RDS Proxy, extra gp3 IOPS/throughput, replicas and Extended Support. Rate snapshot: 2026-10-18. Model: `rds-postgresql-cloudsql` / `2026-10-18.4`. Curve: `storage-rds-ha-1`. Sources: [RDS PostgreSQL pricing](https://aws.amazon.com/rds/postgresql/pricing/), [AWS RDS us-east-1 reference price list](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Cloud SQL Enterprise PostgreSQL pricing](https://cloud.google.com/sql/pricing/). **RDS PostgreSQL → Cloud SQL for PostgreSQL: Reference monthly workload.** Monthly AWS usage charges at the 2026-10-18 reference list rates in us-east-1, before free allowances, discounts, credits and tax. Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD. | Monthly component | USD | | - | -: | | Origin: RDS PostgreSQL db.m6i primary compute | 259.88 | | Origin: RDS PostgreSQL gp3 primary storage | 23.00 | | Target: Allocated Cloud SQL Enterprise CPU | 120.60 | | Target: Allocated Cloud SQL Enterprise memory | 81.76 | | Target: Allocated Cloud SQL SSD | 34.00 | | **Origin service subtotal** | **282.88** | | **Target service subtotal** | **236.36** | Unestimated components: Allocated adapter hosting, Allocated Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled monthly service usage and selected database allocation; adapter hosting and Tensor9 fees only when explicitly supplied. Excluded costs and workload features: * Free allowances, negotiated discounts, credits, tax and one-time migration charges. * Charges not listed in the breakdown, including additional network transfer, backups and encryption/KMS. * Application compute changes, operational labor and portfolio-wide sharing or deduplication of infrastructure. * Aurora, other database engines or instance families, RDS Proxy, extra gp3 IOPS/throughput, replicas and Extended Support. **Scenario assumptions** | Input | Value | Unit | | - | -: | - | | RDS db.m6i PostgreSQL compute | 259.88 | USD/month | | RDS gp3 provisioned storage | 23 | USD/month | | RDS one-standby Multi-AZ | 1 | 0 = Single-AZ, 1 = Multi-AZ | | Cloud SQL vCPUs | 2 | vCPU | | Cloud SQL memory | 8 | GiB | | Provisioned Cloud SQL SSD | 100 | GiB | | Cloud SQL high availability | 1 | 0 = zonal, 1 = HA | | Share of database cost allocated here | 1 | fraction | * RDS primary allocated vCPUs: 2 vCPU. * RDS primary allocated memory: 8 GiB. * RDS primary provisioned storage: 100 GiB-month. * Cloud SQL configuration pricing only: throughput, peak load, latency and storage suitability are unqualified. No capacity benchmark is implied. * 730 running hours per modeled month. Dedicated database compute and disk cost money even with zero origin traffic. * Shared database allocation is a caller assumption. Do not sum a full database charge for every adapter sharing that database. * Source configurations are continuously running PostgreSQL db.m6i instances with 2, 4, 8, 16 or 32 primary vCPUs and 4 GiB RAM per vCPU. Architecture and resource counts do not prove equal performance. * Application traffic uses native PostgreSQL pgwire directly; no adapter proxy compute is required in that data path. Optional hosting and Tensor9 allocations still require an explicit selection. * Source primary vCPU-hours and storage exclude the standby; rdsHa adds one copy. Legacy source dollar inputs include the selected standby charge. Rate snapshot: 2026-10-18. Model: `rds-postgresql-cloudsql` / `2026-10-18.4`. Scenario: `rds-postgresql-cloudsql-reference`. Sources: [RDS PostgreSQL pricing](https://aws.amazon.com/rds/postgresql/pricing/), [AWS RDS us-east-1 reference price list](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Cloud SQL Enterprise PostgreSQL pricing](https://cloud.google.com/sql/pricing/). ### Cloud SQL 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 DB resource ID and user, then logs in as that role | | AWS integration SQL: aws\_s3.\*, aws\_lambda.invoke, rds\_tools | SQL functions | Out of scope | Full surface | RDS extension functions with no counterpart on vanilla PostgreSQL; a query calling them fails | | pgwire protocol through the Tensor9 PostgreSQL proxy (application SQL) | Wire protocol | Supported | Common | same PostgreSQL engine; the proxy relays each session unchanged over its own Cloud SQL 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 Cloud SQL 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 Cloud SQL for PostgreSQL's management API, exactly as for the backend without the proxy. Creating the database on this backend, rather than on plain Cloud SQL, gives you what the proxy adds: IAM database authentication with RDS tokens, which Cloud SQL's own login cannot verify. This backend is available only where Tensor9 runs as a Docker composition with a database proxy configured; Kubernetes installations reject it. ![Database requests (SQL over pgwire) go through the Tensor9 PostgreSQL proxy to Cloud SQL. The Tensor9 service adapter translates RDS API management calls to Cloud SQL admin API.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgcGd3aXJlKSBnbyB0aHJvdWdoIHRoZSBUZW5zb3I5IFBvc3RncmVTUUwgcHJveHkgdG8gQ2xvdWQgU1FMLiBUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgdHJhbnNsYXRlcyBSRFMgQVBJIG1hbmFnZW1lbnQgY2FsbHMgdG8gQ2xvdWQgU1FMIGFkbWluIEFQSS4iPjxzdHlsZT50ZXh0e2ZvbnQtZmFtaWx5OkludGVyLC1hcHBsZS1zeXN0ZW0sQmxpbmtNYWNTeXN0ZW1Gb250LCdTZWdvZSBVSScsUm9ib3RvLCdIZWx2ZXRpY2EgTmV1ZScsQXJpYWwsc2Fucy1zZXJpZjtmaWxsOiMzMzQxNTV9PC9zdHlsZT4KPGRlZnM+PG1hcmtlciBpZD0iYWhwLWNsb3VkLXNxbCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNyIgbWFya2VySGVpZ2h0PSI3IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+PHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBzdHlsZT0iZmlsbDojOTRhM2I4Ii8+PC9tYXJrZXI+PC9kZWZzPgo8cmVjdCB4PSI4IiB5PSIzNCIgd2lkdGg9IjgyMCIgaGVpZ2h0PSIyMDYiIHJ4PSIxNiIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0cm9rZS1kYXNoYXJyYXk9IjUgNSIgc3R5bGU9ImZpbGw6I2Y4ZmFmYztzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSIyNiIgeT0iNTQiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4OyBmaWxsOiMwNDc4NTciPk9OIEdPT0dMRSBDTE9VRDwvdGV4dD4KPHN2ZyB4PSI3OTIiIHk9IjM2IiB3aWR0aD0iMTYiIGhlaWdodD0iMTYiIHZpZXdCb3g9IjAgLTI1IDI1NiAyNTYiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiPjxnPiA8cGF0aCBkPSJNMTcwLjI1MTcsNTYuODE4NiBMMTkyLjUwNDcsMzQuNTY1NiBMMTkzLjk4NzcsMjUuMTk1NiBDMTUzLjQzNjcsLTExLjY3NzQgODguOTc1NywtNy40OTY0IDUyLjQyMDcsMzMuOTE5NiBDNDIuMjY2Nyw0NS40MjI2IDM0LjczMzcsNTkuNzYzNiAzMC43MTY3LDc0LjU3MjYgTDM4LjY4NjcsNzMuNDQ5NiBMODMuMTkxNyw2Ni4xMTA2IEw4Ni42Mjc3LDYyLjU5NjYgQzEwNi40MjQ3LDQwLjg1NDYgMTM5Ljg5NzcsMzcuOTI5NiAxNjIuNzU1Nyw1Ni40Mjg2IEwxNzAuMjUxNyw1Ni44MTg2IFoiIGZpbGw9IiNFQTQzMzUiPiA8L3BhdGg+IDxwYXRoIGQ9Ik0yMjQuMjA0OCw3My45MTgyIEMyMTkuMDg5OCw1NS4wODIyIDIwOC41ODg4LDM4LjE0OTIgMTkzLjk4NzgsMjUuMTk2MiBMMTYyLjc1NTgsNTYuNDI4MiBDMTc1Ljk0MzgsNjcuMjA0MiAxODMuNDU2OCw4My40MzgyIDE4My4xMzQ4LDEwMC40NjUyIEwxODMuMTM0OCwxMDYuMDA5MiBDMTk4LjQ4NTgsMTA2LjAwOTIgMjEwLjkzMTgsMTE4LjQ1NDIgMjEwLjkzMTgsMTMzLjgwNTIgQzIxMC45MzE4LDE0OS4xNTcyIDE5OC40ODU4LDE2MS4yOTAyIDE4My4xMzQ4LDE2MS4yOTAyIEwxMjcuNDYzOCwxNjEuMjkwMiBMMTIxLjk5NzgsMTY3LjIyNDIgTDEyMS45OTc4LDIwMC41NjQyIEwxMjcuNDYzOCwyMDUuNzk1MiBMMTgzLjEzNDgsMjA1Ljc5NTIgQzIyMy4wNjQ4LDIwNi4xMDYyIDI1NS42ODY4LDE3NC4zMDEyIDI1NS45OTc4LDEzNC4zNzEyIEMyNTYuMTg1OCwxMTAuMTY4MiAyNDQuMjUyOCw4Ny40NzgyIDIyNC4yMDQ4LDczLjkxODIiIGZpbGw9IiM0Mjg1RjQiPiA8L3BhdGg+IDxwYXRoIGQ9Ik03MS44NzA0LDIwNS43OTU3IEwxMjcuNDYzNCwyMDUuNzk1NyBMMTI3LjQ2MzQsMTYxLjI4OTcgTDcxLjg3MDQsMTYxLjI4OTcgQzY3LjkwOTQsMTYxLjI4ODcgNjQuMDczNCwxNjAuNDM3NyA2MC40NzE0LDE1OC43OTE3IEw1Mi41ODQ0LDE2MS4yMTE3IEwzMC4xNzU0LDE4My40NjQ3IEwyOC4yMjM0LDE5MS4wMzg3IEM0MC43OTA0LDIwMC41Mjc3IDU2LjEyMzQsMjA1Ljg2MzcgNzEuODcwNCwyMDUuNzk1NyIgZmlsbD0iIzM0QTg1MyI+IDwvcGF0aD4gPHBhdGggZD0iTTcxLjg3MDQsNjEuNDI1NSBDMzEuOTM5NCw2MS42NjM1IC0wLjIzNjYsOTQuMjI3NSAwLjAwMTQsMTM0LjE1NzUgQzAuMTM0NCwxNTYuNDU1NSAxMC41NDg0LDE3Ny40NDU1IDI4LjIyMzQsMTkxLjAzODUgTDYwLjQ3MTQsMTU4Ljc5MTUgQzQ2LjQ4MDQsMTUyLjQ3MDUgNDAuMjYzNCwxMzYuMDA1NSA0Ni41ODQ0LDEyMi4wMTU1IEM1Mi45MDQ0LDEwOC4wMjU1IDY5LjM3MDQsMTAxLjgwODUgODMuMzU5NCwxMDguMTI4NSBDODkuNTI0NCwxMTAuOTEzNSA5NC40NjE0LDExNS44NTE1IDk3LjI0NjQsMTIyLjAxNTUgTDEyOS40OTQ0LDg5Ljc2ODUgQzExNS43NzM0LDcxLjgzMTUgOTQuNDUzNCw2MS4zNDQ1IDcxLjg3MDQsNjEuNDI1NSIgZmlsbD0iI0ZCQkMwNSI+IDwvcGF0aD4gPC9nPjwvc3ZnPgo8cmVjdCB4PSIyNiIgeT0iODgiIHdpZHRoPSIxMjgiIGhlaWdodD0iMTEyIiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjkwIiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTNweCI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIxNDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5Qb3N0Z3JlU1FMIGRyaXZlcjwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjE2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij51bmNoYW5nZWQ8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iNjYiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4OyBmaWxsOiMwNDc4NTciPkRBVEFCQVNFIFJFUVVFU1RTIMK3IFZJQSBURU5TT1I5IFBST1hZPC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTA4IiB4Mj0iMzAwIiB5Mj0iMTA4IiBzdHJva2Utd2lkdGg9IjIuMiIgbWFya2VyLWVuZD0idXJsKCNhaHAtY2xvdWQtc3FsKSIgc3R5bGU9InN0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9IjIyNyIgeT0iMTAwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YjsgZmlsbDojMDQ3ODU3Ij5TUUwgb3ZlciBwZ3dpcmU8L3RleHQ+CjxyZWN0IHg9IjMwNCIgeT0iNzYiIHdpZHRoPSIxODAiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iMzk0IiB5PSI5OCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTc7IGZvbnQtc2l6ZToxMnB4Ij5UZW5zb3I5IFNRTCBwcm94eTwvdGV4dD4KPHRleHQgeD0iMzk0IiB5PSIxMTUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPklBTSBsb2dpbiDCtyByZWxheXMgc2Vzc2lvbnM8L3RleHQ+Cjx0ZXh0IHg9IjM5NCIgeT0iMTMwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij5vbmUgYmFja2VuZCBzZXNzaW9uIGVhY2g8L3RleHQ+CjxsaW5lIHgxPSI0ODQiIHkxPSIxMDgiIHgyPSI2MTAiIHkyPSIxMDgiIHN0cm9rZS13aWR0aD0iMi4yIiBtYXJrZXItZW5kPSJ1cmwoI2FocC1jbG91ZC1zcWwpIiBzdHlsZT0ic3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iNTQ3IiB5PSIxMDAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiMwNDc4NTciPm93biBzZXNzaW9uPC90ZXh0Pgo8dGV4dCB4PSIzOTQiIHk9IjE1NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPm9uZSBwcm94eSBjb250YWluZXIgcGVyIGRhdGFiYXNlPC90ZXh0Pgo8cmVjdCB4PSI2MTQiIHk9Ijc2IiB3aWR0aD0iMTk2IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+CjxzdmcgeD0iNzg2IiB5PSI1NiIgd2lkdGg9IjIwIiBoZWlnaHQ9IjIwIiB2aWV3Qm94PSIwIDAgNDMyLjA3MSA0NDUuMzgzIiBwcmVzZXJ2ZUFzcGVjdFJhdGlvPSJ4TWlkWU1pZCBtZWV0Ij48ZyBzdHlsZT0iZmlsbC1ydWxlOm5vbnplcm87Y2xpcC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLW1pdGVybGltaXQ6NCI+IDwvZz4gPGcgc3R5bGU9ImZpbGwtcnVsZTpub256ZXJvO2NsaXAtcnVsZTpub256ZXJvO2ZpbGw6bm9uZTtzdHJva2U6I0ZGRkZGRjtzdHJva2Utd2lkdGg6MTIuNDY1MTtzdHJva2UtbGluZWNhcDpyb3VuZDtzdHJva2UtbGluZWpvaW46cm91bmQ7c3Ryb2tlLW1pdGVybGltaXQ6NCI+IDxwYXRoIGQ9Ik0zMjMuMjA1LDMyNC4yMjdjMi44MzMtMjMuNjAxLDEuOTg0LTI3LjA2MiwxOS41NjMtMjMuMjM5bDQuNDYzLDAuMzkyYzEzLjUxNywwLjYxNSwzMS4xOTktMi4xNzQsNDEuNTg3LTdjMjIuMzYyLTEwLjM3NiwzNS42MjItMjcuNywxMy41NzItMjMuMTQ4Yy01MC4yOTcsMTAuMzc2LTUzLjc1NS02LjY1NS01My43NTUtNi42NTVjNTMuMTExLTc4LjgwMyw3NS4zMTMtMTc4LjgzNiw1Ni4xNDktMjAzLjMyMiBDMzUyLjUxNC01LjUzNCwyNjIuMDM2LDI2LjA0OSwyNjAuNTIyLDI2Ljg2OWwtMC40ODIsMC4wODljLTkuOTM4LTIuMDYyLTIxLjA2LTMuMjk0LTMzLjU1NC0zLjQ5NmMtMjIuNzYxLTAuMzc0LTQwLjAzMiw1Ljk2Ny01My4xMzMsMTUuOTA0YzAsMC0xNjEuNDA4LTY2LjQ5OC0xNTMuODk5LDgzLjYyOGMxLjU5NywzMS45MzYsNDUuNzc3LDI0MS42NTUsOTguNDcsMTc4LjMxIGMxOS4yNTktMjMuMTYzLDM3Ljg3MS00Mi43NDgsMzcuODcxLTQyLjc0OGM5LjI0Miw2LjE0LDIwLjMwNyw5LjI3MiwzMS45MTIsOC4xNDdsMC44OTctMC43NjVjLTAuMjgxLDIuODc2LTAuMTU3LDUuNjg5LDAuMzU5LDkuMDE5Yy0xMy41NzIsMTUuMTY3LTkuNTg0LDE3LjgzLTM2LjcyMywyMy40MTZjLTI3LjQ1Nyw1LjY1OS0xMS4zMjYsMTUuNzM0LTAuNzk3LDE4LjM2N2MxMi43NjgsMy4xOTMsNDIuMzA1LDcuNzE2LDYyLjI2OC0yMC4yMjQgbC0wLjc5NSwzLjE4OGM1LjMyNSw0LjI2LDQuOTY1LDMwLjYxOSw1LjcyLDQ5LjQ1MmMwLjc1NiwxOC44MzQsMi4wMTcsMzYuNDA5LDUuODU2LDQ2Ljc3MWMzLjgzOSwxMC4zNiw4LjM2OSwzNy4wNSw0NC4wMzYsMjkuNDA2YzI5LjgwOS02LjM4OCw1Mi42LTE1LjU4Miw1NC42NzctMTAxLjEwNyIgc3R5bGU9ImZpbGw6IzAwMDAwMDtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MzcuMzk1MztzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNNDAyLjM5NSwyNzEuMjNjLTUwLjMwMiwxMC4zNzYtNTMuNzYtNi42NTUtNTMuNzYtNi42NTVjNTMuMTExLTc4LjgwOCw3NS4zMTMtMTc4Ljg0Myw1Ni4xNTMtMjAzLjMyNmMtNTIuMjctNjYuNzg1LTE0Mi43NTItMzUuMi0xNDQuMjYyLTM0LjM4bC0wLjQ4NiwwLjA4N2MtOS45MzgtMi4wNjMtMjEuMDYtMy4yOTItMzMuNTYtMy40OTZjLTIyLjc2MS0wLjM3My00MC4wMjYsNS45NjctNTMuMTI3LDE1LjkwMiBjMCwwLTE2MS40MTEtNjYuNDk1LTE1My45MDQsODMuNjNjMS41OTcsMzEuOTM4LDQ1Ljc3NiwyNDEuNjU3LDk4LjQ3MSwxNzguMzEyYzE5LjI2LTIzLjE2MywzNy44NjktNDIuNzQ4LDM3Ljg2OS00Mi43NDhjOS4yNDMsNi4xNCwyMC4zMDgsOS4yNzIsMzEuOTA4LDguMTQ3bDAuOTAxLTAuNzY1Yy0wLjI4LDIuODc2LTAuMTUyLDUuNjg5LDAuMzYxLDkuMDE5Yy0xMy41NzUsMTUuMTY3LTkuNTg2LDE3LjgzLTM2LjcyMywyMy40MTYgYy0yNy40NTksNS42NTktMTEuMzI4LDE1LjczNC0wLjc5NiwxOC4zNjdjMTIuNzY4LDMuMTkzLDQyLjMwNyw3LjcxNiw2Mi4yNjYtMjAuMjI0bC0wLjc5NiwzLjE4OGM1LjMxOSw0LjI2LDkuMDU0LDI3LjcxMSw4LjQyOCw0OC45NjljLTAuNjI2LDIxLjI1OS0xLjA0NCwzNS44NTQsMy4xNDcsNDcuMjU0YzQuMTkxLDExLjQsOC4zNjgsMzcuMDUsNDQuMDQyLDI5LjQwNmMyOS44MDktNi4zODgsNDUuMjU2LTIyLjk0Miw0Ny40MDUtNTAuNTU1IGMxLjUyNS0xOS42MzEsNC45NzYtMTYuNzI5LDUuMTk0LTM0LjI4bDIuNzY4LTguMzA5YzMuMTkyLTI2LjYxMSwwLjUwNy0zNS4xOTYsMTguODcyLTMxLjIwM2w0LjQ2MywwLjM5MmMxMy41MTcsMC42MTUsMzEuMjA4LTIuMTc0LDQxLjU5MS03YzIyLjM1OC0xMC4zNzYsMzUuNjE4LTI3LjcsMTMuNTczLTIzLjE0OHoiIHN0eWxlPSJmaWxsOiMzMzY3OTE7c3Ryb2tlOm5vbmUiLz4gPHBhdGggZD0iTTIxNS44NjYsMjg2LjQ4NGMtMS4zODUsNDkuNTE2LDAuMzQ4LDk5LjM3Nyw1LjE5MywxMTEuNDk1YzQuODQ4LDEyLjExOCwxNS4yMjMsMzUuNjg4LDUwLjksMjguMDQ1YzI5LjgwNi02LjM5LDQwLjY1MS0xOC43NTYsNDUuMzU3LTQ2LjA1MWMzLjQ2Ni0yMC4wODIsMTAuMTQ4LTc1Ljg1NCwxMS4wMDUtODcuMjgxIi8+IDxwYXRoIGQ9Ik0xNzMuMTA0LDM4LjI1NmMwLDAtMTYxLjUyMS02Ni4wMTYtMTU0LjAxMiw4NC4xMDljMS41OTcsMzEuOTM4LDQ1Ljc3OSwyNDEuNjY0LDk4LjQ3MywxNzguMzE2YzE5LjI1Ni0yMy4xNjYsMzYuNjcxLTQxLjMzNSwzNi42NzEtNDEuMzM1Ii8+IDxwYXRoIGQ9Ik0yNjAuMzQ5LDI2LjIwN2MtNS41OTEsMS43NTMsODkuODQ4LTM0Ljg4OSwxNDQuMDg3LDM0LjQxN2MxOS4xNTksMjQuNDg0LTMuMDQzLDEyNC41MTktNTYuMTUzLDIwMy4zMjkiLz4gPHBhdGggZD0iTTM0OC4yODIsMjYzLjk1M2MwLDAsMy40NjEsMTcuMDM2LDUzLjc2NCw2LjY1M2MyMi4wNC00LjU1Miw4Ljc3NiwxMi43NzQtMTMuNTc3LDIzLjE1NWMtMTguMzQ1LDguNTE0LTU5LjQ3NCwxMC42OTYtNjAuMTQ2LTEuMDY5Yy0xLjcyOS0zMC4zNTUsMjEuNjQ3LTIxLjEzMywxOS45Ni0yOC43MzljLTEuNTI1LTYuODUtMTEuOTc5LTEzLjU3My0xOC44OTQtMzAuMzM4IGMtNi4wMzctMTQuNjMzLTgyLjc5Ni0xMjYuODQ5LDIxLjI4Ny0xMTAuMTgzYzMuODEzLTAuNzg5LTI3LjE0Ni05OS4wMDItMTI0LjU1My0xMDAuNTk5Yy05Ny4zODUtMS41OTctOTQuMTksMTE5Ljc2Mi05NC4xOSwxMTkuNzYyIiBzdHlsZT0ic3Ryb2tlLWxpbmVqb2luOmJldmVsIi8+IDxwYXRoIGQ9Ik0xODguNjA0LDI3NC4zMzRjLTEzLjU3NywxNS4xNjYtOS41ODQsMTcuODI5LTM2LjcyMywyMy40MTdjLTI3LjQ1OSw1LjY2LTExLjMyNiwxNS43MzMtMC43OTcsMTguMzY1YzEyLjc2OCwzLjE5NSw0Mi4zMDcsNy43MTgsNjIuMjY2LTIwLjIyOWM2LjA3OC04LjUwOS0wLjAzNi0yMi4wODYtOC4zODUtMjUuNTQ3Yy00LjAzNC0xLjY3MS05LjQyOC0zLjc2NS0xNi4zNjEsMy45OTR6Ii8+IDxwYXRoIGQ9Ik0xODcuNzE1LDI3NC4wNjljLTEuMzY4LTguOTE3LDIuOTMtMTkuNTI4LDcuNTM2LTMxLjk0MmM2LjkyMi0xOC42MjYsMjIuODkzLTM3LjI1NSwxMC4xMTctOTYuMzM5Yy05LjUyMy00NC4wMjktNzMuMzk2LTkuMTYzLTczLjQzNi0zLjE5M2MtMC4wMzksNS45NjgsMi44ODksMzAuMjYtMS4wNjcsNTguNTQ4Yy01LjE2MiwzNi45MTMsMjMuNDg4LDY4LjEzMiw1Ni40NzksNjQuOTM4Ii8+IDxwYXRoIGQ9Ik0xNzIuNTE3LDE0MS43Yy0wLjI4OCwyLjAzOSwzLjczMyw3LjQ4LDguOTc2LDguMjA3YzUuMjM0LDAuNzMsOS43MTQtMy41MjIsOS45OTgtNS41NTljMC4yODQtMi4wMzktMy43MzItNC4yODUtOC45NzctNS4wMTVjLTUuMjM3LTAuNzMxLTkuNzE5LDAuMzMzLTkuOTk2LDIuMzY3eiIgc3R5bGU9ImZpbGw6I0ZGRkZGRjtzdHJva2Utd2lkdGg6NC4xNTU7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTMzMS45NDEsMTM3LjU0M2MwLjI4NCwyLjAzOS0zLjczMiw3LjQ4LTguOTc2LDguMjA3Yy01LjIzOCwwLjczLTkuNzE4LTMuNTIyLTEwLjAwNS01LjU1OWMtMC4yNzctMi4wMzksMy43NC00LjI4NSw4Ljk3OS01LjAxNWM1LjIzOS0wLjczLDkuNzE4LDAuMzMzLDEwLjAwMiwyLjM2OHoiIHN0eWxlPSJmaWxsOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjIuMDc3NTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNMzUwLjY3NiwxMjMuNDMyYzAuODYzLDE1Ljk5NC0zLjQ0NSwyNi44ODgtMy45ODgsNDMuOTE0Yy0wLjgwNCwyNC43NDgsMTEuNzk5LDUzLjA3NC03LjE5MSw4MS40MzUiLz4gPHBhdGggZD0iTTAsNjAuMjMyIiBzdHlsZT0ic3Ryb2tlLXdpZHRoOjMiLz4gPC9nPjwvc3ZnPgo8dGV4dCB4PSI3MTIiIHk9IjEwMyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMnB4Ij5DbG91ZCBTUUw8L3RleHQ+Cjx0ZXh0IHg9IjcxMiIgeT0iMTIyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+UG9zdGdyZVNRTCBlbmdpbmU8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iMTc2IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzk0YTNiOCI+TUFOQUdFTUVOVCBSRVFVRVNUUyDCtyBWSUEgVEVOU09SOTwvdGV4dD4KPGxpbmUgeDE9IjE1NCIgeTE9IjIwNiIgeDI9IjMwMCIgeTI9IjIwNiIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FocC1jbG91ZC1zcWwpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iMjI3IiB5PSIxOTgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiIj5SRFMgQVBJPC90ZXh0Pgo8cmVjdCB4PSIzMDQiIHk9IjE4MiIgd2lkdGg9IjE4MCIgaGVpZ2h0PSI1MCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSIzOTQiIHk9IjIwMyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTc7IGZvbnQtc2l6ZToxMnB4Ij5UZW5zb3I5PC90ZXh0Pgo8dGV4dCB4PSIzOTQiIHk9IjIyMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+c2VydmljZSBhZGFwdGVyPC90ZXh0Pgo8bGluZSB4MT0iNDg0IiB5MT0iMjA2IiB4Mj0iNjEwIiB5Mj0iMjA2IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhwLWNsb3VkLXNxbCkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8cmVjdCB4PSI2MTQiIHk9IjE4MiIgd2lkdGg9IjE5NiIgaGVpZ2h0PSI1MCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSI3MTIiIHk9IjIwMyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwZjE3MmE7IGZvbnQtc2l6ZToxMS41cHgiPkNsb3VkIFNRTCBhZG1pbiBBUEk8L3RleHQ+Cjx0ZXh0IHg9IjcxMiIgeT0iMjIwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+dGhlIGJhY2tlbmQncyBtYW5hZ2VtZW50IEFQSTwvdGV4dD4KPC9zdmc+) ![Database requests (SQL over pgwire) go through the Tensor9 PostgreSQL proxy to Cloud SQL. The Tensor9 service adapter translates RDS API management calls to Cloud SQL admin API.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgcGd3aXJlKSBnbyB0aHJvdWdoIHRoZSBUZW5zb3I5IFBvc3RncmVTUUwgcHJveHkgdG8gQ2xvdWQgU1FMLiBUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgdHJhbnNsYXRlcyBSRFMgQVBJIG1hbmFnZW1lbnQgY2FsbHMgdG8gQ2xvdWQgU1FMIGFkbWluIEFQSS4iPjxzdHlsZT50ZXh0e2ZvbnQtZmFtaWx5OkludGVyLC1hcHBsZS1zeXN0ZW0sQmxpbmtNYWNTeXN0ZW1Gb250LCdTZWdvZSBVSScsUm9ib3RvLCdIZWx2ZXRpY2EgTmV1ZScsQXJpYWwsc2Fucy1zZXJpZjtmaWxsOiNjYmQ1ZTF9PC9zdHlsZT4KPGRlZnM+PG1hcmtlciBpZD0iYWhwLWNsb3VkLXNxbCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI4IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNyIgbWFya2VySGVpZ2h0PSI3IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+PHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBzdHlsZT0iZmlsbDojNjQ3NDhiIi8+PC9tYXJrZXI+PC9kZWZzPgo8cmVjdCB4PSI4IiB5PSIzNCIgd2lkdGg9IjgyMCIgaGVpZ2h0PSIyMDYiIHJ4PSIxNiIgc3Ryb2tlLXdpZHRoPSIxLjQiIHN0cm9rZS1kYXNoYXJyYXk9IjUgNSIgc3R5bGU9ImZpbGw6IzBmMTcyYTtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSIyNiIgeT0iNTQiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiM2ZWU3YjciPk9OIEdPT0dMRSBDTE9VRDwvdGV4dD4KPHN2ZyB4PSI3OTIiIHk9IjM2IiB3aWR0aD0iMTYiIGhlaWdodD0iMTYiIHZpZXdCb3g9IjAgLTI1IDI1NiAyNTYiIHByZXNlcnZlQXNwZWN0UmF0aW89InhNaWRZTWlkIG1lZXQiPjxnPiA8cGF0aCBkPSJNMTcwLjI1MTcsNTYuODE4NiBMMTkyLjUwNDcsMzQuNTY1NiBMMTkzLjk4NzcsMjUuMTk1NiBDMTUzLjQzNjcsLTExLjY3NzQgODguOTc1NywtNy40OTY0IDUyLjQyMDcsMzMuOTE5NiBDNDIuMjY2Nyw0NS40MjI2IDM0LjczMzcsNTkuNzYzNiAzMC43MTY3LDc0LjU3MjYgTDM4LjY4NjcsNzMuNDQ5NiBMODMuMTkxNyw2Ni4xMTA2IEw4Ni42Mjc3LDYyLjU5NjYgQzEwNi40MjQ3LDQwLjg1NDYgMTM5Ljg5NzcsMzcuOTI5NiAxNjIuNzU1Nyw1Ni40Mjg2IEwxNzAuMjUxNyw1Ni44MTg2IFoiIGZpbGw9IiNFQTQzMzUiPiA8L3BhdGg+IDxwYXRoIGQ9Ik0yMjQuMjA0OCw3My45MTgyIEMyMTkuMDg5OCw1NS4wODIyIDIwOC41ODg4LDM4LjE0OTIgMTkzLjk4NzgsMjUuMTk2MiBMMTYyLjc1NTgsNTYuNDI4MiBDMTc1Ljk0MzgsNjcuMjA0MiAxODMuNDU2OCw4My40MzgyIDE4My4xMzQ4LDEwMC40NjUyIEwxODMuMTM0OCwxMDYuMDA5MiBDMTk4LjQ4NTgsMTA2LjAwOTIgMjEwLjkzMTgsMTE4LjQ1NDIgMjEwLjkzMTgsMTMzLjgwNTIgQzIxMC45MzE4LDE0OS4xNTcyIDE5OC40ODU4LDE2MS4yOTAyIDE4My4xMzQ4LDE2MS4yOTAyIEwxMjcuNDYzOCwxNjEuMjkwMiBMMTIxLjk5NzgsMTY3LjIyNDIgTDEyMS45OTc4LDIwMC41NjQyIEwxMjcuNDYzOCwyMDUuNzk1MiBMMTgzLjEzNDgsMjA1Ljc5NTIgQzIyMy4wNjQ4LDIwNi4xMDYyIDI1NS42ODY4LDE3NC4zMDEyIDI1NS45OTc4LDEzNC4zNzEyIEMyNTYuMTg1OCwxMTAuMTY4MiAyNDQuMjUyOCw4Ny40NzgyIDIyNC4yMDQ4LDczLjkxODIiIGZpbGw9IiM0Mjg1RjQiPiA8L3BhdGg+IDxwYXRoIGQ9Ik03MS44NzA0LDIwNS43OTU3IEwxMjcuNDYzNCwyMDUuNzk1NyBMMTI3LjQ2MzQsMTYxLjI4OTcgTDcxLjg3MDQsMTYxLjI4OTcgQzY3LjkwOTQsMTYxLjI4ODcgNjQuMDczNCwxNjAuNDM3NyA2MC40NzE0LDE1OC43OTE3IEw1Mi41ODQ0LDE2MS4yMTE3IEwzMC4xNzU0LDE4My40NjQ3IEwyOC4yMjM0LDE5MS4wMzg3IEM0MC43OTA0LDIwMC41Mjc3IDU2LjEyMzQsMjA1Ljg2MzcgNzEuODcwNCwyMDUuNzk1NyIgZmlsbD0iIzM0QTg1MyI+IDwvcGF0aD4gPHBhdGggZD0iTTcxLjg3MDQsNjEuNDI1NSBDMzEuOTM5NCw2MS42NjM1IC0wLjIzNjYsOTQuMjI3NSAwLjAwMTQsMTM0LjE1NzUgQzAuMTM0NCwxNTYuNDU1NSAxMC41NDg0LDE3Ny40NDU1IDI4LjIyMzQsMTkxLjAzODUgTDYwLjQ3MTQsMTU4Ljc5MTUgQzQ2LjQ4MDQsMTUyLjQ3MDUgNDAuMjYzNCwxMzYuMDA1NSA0Ni41ODQ0LDEyMi4wMTU1IEM1Mi45MDQ0LDEwOC4wMjU1IDY5LjM3MDQsMTAxLjgwODUgODMuMzU5NCwxMDguMTI4NSBDODkuNTI0NCwxMTAuOTEzNSA5NC40NjE0LDExNS44NTE1IDk3LjI0NjQsMTIyLjAxNTUgTDEyOS40OTQ0LDg5Ljc2ODUgQzExNS43NzM0LDcxLjgzMTUgOTQuNDUzNCw2MS4zNDQ1IDcxLjg3MDQsNjEuNDI1NSIgZmlsbD0iI0ZCQkMwNSI+IDwvcGF0aD4gPC9nPjwvc3ZnPgo8cmVjdCB4PSIyNiIgeT0iODgiIHdpZHRoPSIxMjgiIGhlaWdodD0iMTEyIiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjkwIiB5PSIxMjYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTNweCI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIxNDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5Qb3N0Z3JlU1FMIGRyaXZlcjwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjE2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij51bmNoYW5nZWQ8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iNjYiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiM2ZWU3YjciPkRBVEFCQVNFIFJFUVVFU1RTIMK3IFZJQSBURU5TT1I5IFBST1hZPC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTA4IiB4Mj0iMzAwIiB5Mj0iMTA4IiBzdHJva2Utd2lkdGg9IjIuMiIgbWFya2VyLWVuZD0idXJsKCNhaHAtY2xvdWQtc3FsKSIgc3R5bGU9InN0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9IjIyNyIgeT0iMTAwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiODsgZmlsbDojNmVlN2I3Ij5TUUwgb3ZlciBwZ3dpcmU8L3RleHQ+CjxyZWN0IHg9IjMwNCIgeT0iNzYiIHdpZHRoPSIxODAiIGhlaWdodD0iNjQiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iMzk0IiB5PSI5OCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3Yjc7IGZvbnQtc2l6ZToxMnB4Ij5UZW5zb3I5IFNRTCBwcm94eTwvdGV4dD4KPHRleHQgeD0iMzk0IiB5PSIxMTUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPklBTSBsb2dpbiDCtyByZWxheXMgc2Vzc2lvbnM8L3RleHQ+Cjx0ZXh0IHg9IjM5NCIgeT0iMTMwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij5vbmUgYmFja2VuZCBzZXNzaW9uIGVhY2g8L3RleHQ+CjxsaW5lIHgxPSI0ODQiIHkxPSIxMDgiIHgyPSI2MTAiIHkyPSIxMDgiIHN0cm9rZS13aWR0aD0iMi4yIiBtYXJrZXItZW5kPSJ1cmwoI2FocC1jbG91ZC1zcWwpIiBzdHlsZT0ic3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iNTQ3IiB5PSIxMDAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiM2ZWU3YjciPm93biBzZXNzaW9uPC90ZXh0Pgo8dGV4dCB4PSIzOTQiIHk9IjE1NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPm9uZSBwcm94eSBjb250YWluZXIgcGVyIGRhdGFiYXNlPC90ZXh0Pgo8cmVjdCB4PSI2MTQiIHk9Ijc2IiB3aWR0aD0iMTk2IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+CjxzdmcgeD0iNzg2IiB5PSI1NiIgd2lkdGg9IjIwIiBoZWlnaHQ9IjIwIiB2aWV3Qm94PSIwIDAgNDMyLjA3MSA0NDUuMzgzIiBwcmVzZXJ2ZUFzcGVjdFJhdGlvPSJ4TWlkWU1pZCBtZWV0Ij48ZyBzdHlsZT0iZmlsbC1ydWxlOm5vbnplcm87Y2xpcC1ydWxlOm5vbnplcm87c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLW1pdGVybGltaXQ6NCI+IDwvZz4gPGcgc3R5bGU9ImZpbGwtcnVsZTpub256ZXJvO2NsaXAtcnVsZTpub256ZXJvO2ZpbGw6bm9uZTtzdHJva2U6I0ZGRkZGRjtzdHJva2Utd2lkdGg6MTIuNDY1MTtzdHJva2UtbGluZWNhcDpyb3VuZDtzdHJva2UtbGluZWpvaW46cm91bmQ7c3Ryb2tlLW1pdGVybGltaXQ6NCI+IDxwYXRoIGQ9Ik0zMjMuMjA1LDMyNC4yMjdjMi44MzMtMjMuNjAxLDEuOTg0LTI3LjA2MiwxOS41NjMtMjMuMjM5bDQuNDYzLDAuMzkyYzEzLjUxNywwLjYxNSwzMS4xOTktMi4xNzQsNDEuNTg3LTdjMjIuMzYyLTEwLjM3NiwzNS42MjItMjcuNywxMy41NzItMjMuMTQ4Yy01MC4yOTcsMTAuMzc2LTUzLjc1NS02LjY1NS01My43NTUtNi42NTVjNTMuMTExLTc4LjgwMyw3NS4zMTMtMTc4LjgzNiw1Ni4xNDktMjAzLjMyMiBDMzUyLjUxNC01LjUzNCwyNjIuMDM2LDI2LjA0OSwyNjAuNTIyLDI2Ljg2OWwtMC40ODIsMC4wODljLTkuOTM4LTIuMDYyLTIxLjA2LTMuMjk0LTMzLjU1NC0zLjQ5NmMtMjIuNzYxLTAuMzc0LTQwLjAzMiw1Ljk2Ny01My4xMzMsMTUuOTA0YzAsMC0xNjEuNDA4LTY2LjQ5OC0xNTMuODk5LDgzLjYyOGMxLjU5NywzMS45MzYsNDUuNzc3LDI0MS42NTUsOTguNDcsMTc4LjMxIGMxOS4yNTktMjMuMTYzLDM3Ljg3MS00Mi43NDgsMzcuODcxLTQyLjc0OGM5LjI0Miw2LjE0LDIwLjMwNyw5LjI3MiwzMS45MTIsOC4xNDdsMC44OTctMC43NjVjLTAuMjgxLDIuODc2LTAuMTU3LDUuNjg5LDAuMzU5LDkuMDE5Yy0xMy41NzIsMTUuMTY3LTkuNTg0LDE3LjgzLTM2LjcyMywyMy40MTZjLTI3LjQ1Nyw1LjY1OS0xMS4zMjYsMTUuNzM0LTAuNzk3LDE4LjM2N2MxMi43NjgsMy4xOTMsNDIuMzA1LDcuNzE2LDYyLjI2OC0yMC4yMjQgbC0wLjc5NSwzLjE4OGM1LjMyNSw0LjI2LDQuOTY1LDMwLjYxOSw1LjcyLDQ5LjQ1MmMwLjc1NiwxOC44MzQsMi4wMTcsMzYuNDA5LDUuODU2LDQ2Ljc3MWMzLjgzOSwxMC4zNiw4LjM2OSwzNy4wNSw0NC4wMzYsMjkuNDA2YzI5LjgwOS02LjM4OCw1Mi42LTE1LjU4Miw1NC42NzctMTAxLjEwNyIgc3R5bGU9ImZpbGw6IzAwMDAwMDtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MzcuMzk1MztzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNNDAyLjM5NSwyNzEuMjNjLTUwLjMwMiwxMC4zNzYtNTMuNzYtNi42NTUtNTMuNzYtNi42NTVjNTMuMTExLTc4LjgwOCw3NS4zMTMtMTc4Ljg0Myw1Ni4xNTMtMjAzLjMyNmMtNTIuMjctNjYuNzg1LTE0Mi43NTItMzUuMi0xNDQuMjYyLTM0LjM4bC0wLjQ4NiwwLjA4N2MtOS45MzgtMi4wNjMtMjEuMDYtMy4yOTItMzMuNTYtMy40OTZjLTIyLjc2MS0wLjM3My00MC4wMjYsNS45NjctNTMuMTI3LDE1LjkwMiBjMCwwLTE2MS40MTEtNjYuNDk1LTE1My45MDQsODMuNjNjMS41OTcsMzEuOTM4LDQ1Ljc3NiwyNDEuNjU3LDk4LjQ3MSwxNzguMzEyYzE5LjI2LTIzLjE2MywzNy44NjktNDIuNzQ4LDM3Ljg2OS00Mi43NDhjOS4yNDMsNi4xNCwyMC4zMDgsOS4yNzIsMzEuOTA4LDguMTQ3bDAuOTAxLTAuNzY1Yy0wLjI4LDIuODc2LTAuMTUyLDUuNjg5LDAuMzYxLDkuMDE5Yy0xMy41NzUsMTUuMTY3LTkuNTg2LDE3LjgzLTM2LjcyMywyMy40MTYgYy0yNy40NTksNS42NTktMTEuMzI4LDE1LjczNC0wLjc5NiwxOC4zNjdjMTIuNzY4LDMuMTkzLDQyLjMwNyw3LjcxNiw2Mi4yNjYtMjAuMjI0bC0wLjc5NiwzLjE4OGM1LjMxOSw0LjI2LDkuMDU0LDI3LjcxMSw4LjQyOCw0OC45NjljLTAuNjI2LDIxLjI1OS0xLjA0NCwzNS44NTQsMy4xNDcsNDcuMjU0YzQuMTkxLDExLjQsOC4zNjgsMzcuMDUsNDQuMDQyLDI5LjQwNmMyOS44MDktNi4zODgsNDUuMjU2LTIyLjk0Miw0Ny40MDUtNTAuNTU1IGMxLjUyNS0xOS42MzEsNC45NzYtMTYuNzI5LDUuMTk0LTM0LjI4bDIuNzY4LTguMzA5YzMuMTkyLTI2LjYxMSwwLjUwNy0zNS4xOTYsMTguODcyLTMxLjIwM2w0LjQ2MywwLjM5MmMxMy41MTcsMC42MTUsMzEuMjA4LTIuMTc0LDQxLjU5MS03YzIyLjM1OC0xMC4zNzYsMzUuNjE4LTI3LjcsMTMuNTczLTIzLjE0OHoiIHN0eWxlPSJmaWxsOiMzMzY3OTE7c3Ryb2tlOm5vbmUiLz4gPHBhdGggZD0iTTIxNS44NjYsMjg2LjQ4NGMtMS4zODUsNDkuNTE2LDAuMzQ4LDk5LjM3Nyw1LjE5MywxMTEuNDk1YzQuODQ4LDEyLjExOCwxNS4yMjMsMzUuNjg4LDUwLjksMjguMDQ1YzI5LjgwNi02LjM5LDQwLjY1MS0xOC43NTYsNDUuMzU3LTQ2LjA1MWMzLjQ2Ni0yMC4wODIsMTAuMTQ4LTc1Ljg1NCwxMS4wMDUtODcuMjgxIi8+IDxwYXRoIGQ9Ik0xNzMuMTA0LDM4LjI1NmMwLDAtMTYxLjUyMS02Ni4wMTYtMTU0LjAxMiw4NC4xMDljMS41OTcsMzEuOTM4LDQ1Ljc3OSwyNDEuNjY0LDk4LjQ3MywxNzguMzE2YzE5LjI1Ni0yMy4xNjYsMzYuNjcxLTQxLjMzNSwzNi42NzEtNDEuMzM1Ii8+IDxwYXRoIGQ9Ik0yNjAuMzQ5LDI2LjIwN2MtNS41OTEsMS43NTMsODkuODQ4LTM0Ljg4OSwxNDQuMDg3LDM0LjQxN2MxOS4xNTksMjQuNDg0LTMuMDQzLDEyNC41MTktNTYuMTUzLDIwMy4zMjkiLz4gPHBhdGggZD0iTTM0OC4yODIsMjYzLjk1M2MwLDAsMy40NjEsMTcuMDM2LDUzLjc2NCw2LjY1M2MyMi4wNC00LjU1Miw4Ljc3NiwxMi43NzQtMTMuNTc3LDIzLjE1NWMtMTguMzQ1LDguNTE0LTU5LjQ3NCwxMC42OTYtNjAuMTQ2LTEuMDY5Yy0xLjcyOS0zMC4zNTUsMjEuNjQ3LTIxLjEzMywxOS45Ni0yOC43MzljLTEuNTI1LTYuODUtMTEuOTc5LTEzLjU3My0xOC44OTQtMzAuMzM4IGMtNi4wMzctMTQuNjMzLTgyLjc5Ni0xMjYuODQ5LDIxLjI4Ny0xMTAuMTgzYzMuODEzLTAuNzg5LTI3LjE0Ni05OS4wMDItMTI0LjU1My0xMDAuNTk5Yy05Ny4zODUtMS41OTctOTQuMTksMTE5Ljc2Mi05NC4xOSwxMTkuNzYyIiBzdHlsZT0ic3Ryb2tlLWxpbmVqb2luOmJldmVsIi8+IDxwYXRoIGQ9Ik0xODguNjA0LDI3NC4zMzRjLTEzLjU3NywxNS4xNjYtOS41ODQsMTcuODI5LTM2LjcyMywyMy40MTdjLTI3LjQ1OSw1LjY2LTExLjMyNiwxNS43MzMtMC43OTcsMTguMzY1YzEyLjc2OCwzLjE5NSw0Mi4zMDcsNy43MTgsNjIuMjY2LTIwLjIyOWM2LjA3OC04LjUwOS0wLjAzNi0yMi4wODYtOC4zODUtMjUuNTQ3Yy00LjAzNC0xLjY3MS05LjQyOC0zLjc2NS0xNi4zNjEsMy45OTR6Ii8+IDxwYXRoIGQ9Ik0xODcuNzE1LDI3NC4wNjljLTEuMzY4LTguOTE3LDIuOTMtMTkuNTI4LDcuNTM2LTMxLjk0MmM2LjkyMi0xOC42MjYsMjIuODkzLTM3LjI1NSwxMC4xMTctOTYuMzM5Yy05LjUyMy00NC4wMjktNzMuMzk2LTkuMTYzLTczLjQzNi0zLjE5M2MtMC4wMzksNS45NjgsMi44ODksMzAuMjYtMS4wNjcsNTguNTQ4Yy01LjE2MiwzNi45MTMsMjMuNDg4LDY4LjEzMiw1Ni40NzksNjQuOTM4Ii8+IDxwYXRoIGQ9Ik0xNzIuNTE3LDE0MS43Yy0wLjI4OCwyLjAzOSwzLjczMyw3LjQ4LDguOTc2LDguMjA3YzUuMjM0LDAuNzMsOS43MTQtMy41MjIsOS45OTgtNS41NTljMC4yODQtMi4wMzktMy43MzItNC4yODUtOC45NzctNS4wMTVjLTUuMjM3LTAuNzMxLTkuNzE5LDAuMzMzLTkuOTk2LDIuMzY3eiIgc3R5bGU9ImZpbGw6I0ZGRkZGRjtzdHJva2Utd2lkdGg6NC4xNTU7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTMzMS45NDEsMTM3LjU0M2MwLjI4NCwyLjAzOS0zLjczMiw3LjQ4LTguOTc2LDguMjA3Yy01LjIzOCwwLjczLTkuNzE4LTMuNTIyLTEwLjAwNS01LjU1OWMtMC4yNzctMi4wMzksMy43NC00LjI4NSw4Ljk3OS01LjAxNWM1LjIzOS0wLjczLDkuNzE4LDAuMzMzLDEwLjAwMiwyLjM2OHoiIHN0eWxlPSJmaWxsOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjIuMDc3NTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlciIvPiA8cGF0aCBkPSJNMzUwLjY3NiwxMjMuNDMyYzAuODYzLDE1Ljk5NC0zLjQ0NSwyNi44ODgtMy45ODgsNDMuOTE0Yy0wLjgwNCwyNC43NDgsMTEuNzk5LDUzLjA3NC03LjE5MSw4MS40MzUiLz4gPHBhdGggZD0iTTAsNjAuMjMyIiBzdHlsZT0ic3Ryb2tlLXdpZHRoOjMiLz4gPC9nPjwvc3ZnPgo8dGV4dCB4PSI3MTIiIHk9IjEwMyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMnB4Ij5DbG91ZCBTUUw8L3RleHQ+Cjx0ZXh0IHg9IjcxMiIgeT0iMTIyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+UG9zdGdyZVNRTCBlbmdpbmU8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iMTc2IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzY0NzQ4YiI+TUFOQUdFTUVOVCBSRVFVRVNUUyDCtyBWSUEgVEVOU09SOTwvdGV4dD4KPGxpbmUgeDE9IjE1NCIgeTE9IjIwNiIgeDI9IjMwMCIgeTI9IjIwNiIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FocC1jbG91ZC1zcWwpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iMjI3IiB5PSIxOTgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4Ij5SRFMgQVBJPC90ZXh0Pgo8cmVjdCB4PSIzMDQiIHk9IjE4MiIgd2lkdGg9IjE4MCIgaGVpZ2h0PSI1MCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSIzOTQiIHk9IjIwMyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3Yjc7IGZvbnQtc2l6ZToxMnB4Ij5UZW5zb3I5PC90ZXh0Pgo8dGV4dCB4PSIzOTQiIHk9IjIyMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+c2VydmljZSBhZGFwdGVyPC90ZXh0Pgo8bGluZSB4MT0iNDg0IiB5MT0iMjA2IiB4Mj0iNjEwIiB5Mj0iMjA2IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhwLWNsb3VkLXNxbCkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8cmVjdCB4PSI2MTQiIHk9IjE4MiIgd2lkdGg9IjE5NiIgaGVpZ2h0PSI1MCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSI3MTIiIHk9IjIwMyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMS41cHgiPkNsb3VkIFNRTCBhZG1pbiBBUEk8L3RleHQ+Cjx0ZXh0IHg9IjcxMiIgeT0iMjIwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+dGhlIGJhY2tlbmQncyBtYW5hZ2VtZW50IEFQSTwvdGV4dD4KPC9zdmc+) Queries pass through the Tensor9 proxy, which authenticates and routes them; management calls are translated. #### Database connections The database gets one endpoint, the proxy's address for it. `DescribeDBInstances` returns it once the running proxy has confirmed the database's configuration. The Docker composition publishes that endpoint on loopback addresses of the host that runs Tensor9, so applications connect from that host. Describe never returns Cloud SQL's own address, even while the proxy restarts. IAM database authentication works the way it does on RDS. 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:/`, then logs in to Cloud SQL 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 certificate configured for the proxy, not Cloud SQL's, and should verify the hostname they connect to. The proxy encrypts its own connection to Cloud SQL. RDS's S3, Lambda and `rds_tools` SQL functions return an error. RDS PostgreSQL's SQL, drivers, object-relational mappers (ORMs), prepared statements, COPY and cancellation work unchanged through the proxy, because Cloud SQL for PostgreSQL runs PostgreSQL. #### Database management At runtime your tools keep making the same RDS calls: describe the instance, take a snapshot, restore to a point in time, add or promote a read replica, trigger a failover, stop and start, change the instance class or a parameter. For each supported operation, the adapter accepts the RDS request, returns the RDS response format, and performs the operation on Cloud SQL, as on the direct Cloud SQL backend. On this backend it also keeps the proxy up to date, applying each database and IAM change to the proxy before Describe reports the endpoint. `CreateDBInstance` with the backend tag `t9:backend=google::1.0.0::cloudsql::postgresql::proxied` places a database here, or the deployment can name this backend as its default. Tensor9 records the request, creates the Cloud SQL instance and its proxy container in the background, and reports `creating` until both are ready. `DeleteDBInstance` removes the instance and its proxy route. ![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+cmVwbGljYSDCtyBmYWlsb3ZlcjwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSIxMTYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5wYXJhbWV0ZXJzIMK3IHJlYm9vdDwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSIxNDIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiIj5zYW1lIHJlcXVlc3QgLyByZXNwb25zZSBzaGFwZXM8L3RleHQ+CjxsaW5lIHgxPSIyNTIiIHkxPSI3NCIgeDI9IjMxNCIgeTI9Ijc0IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhjLXJkcy1jbG91ZC1zcWwtYWRtaW4tYXBpKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxsaW5lIHgxPSIzMTgiIHkxPSIxMjgiIHgyPSIyNTYiIHkyPSIxMjgiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWNsb3VkLXNxbC1hZG1pbi1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHJlY3QgeD0iMzE4IiB5PSI1NCIgd2lkdGg9IjIwNCIgaGVpZ2h0PSI4OCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6I2VjZmRmNTtzdHJva2U6IzA0Nzg1NyIvPgo8dGV4dCB4PSI0MjAiIHk9Ijk0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NzsgZm9udC1zaXplOjEycHgiPlRlbnNvcjk8L3RleHQ+CiAgPHRleHQgeD0iNDIwIiB5PSIxMTIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTciPnNlcnZpY2UgYWRhcHRlcjwvdGV4dD4KPGxpbmUgeDE9IjUyMiIgeTE9Ijc0IiB4Mj0iNTg0IiB5Mj0iNzQiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWNsb3VkLXNxbC1hZG1pbi1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPGxpbmUgeDE9IjU4OCIgeTE9IjEyOCIgeDI9IjUyNiIgeTI9IjEyOCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtY2xvdWQtc3FsLWFkbWluLWFwaSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8cmVjdCB4PSI1ODgiIHk9IjM0IiB3aWR0aD0iMjMyIiBoZWlnaHQ9IjEyOCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSI3MDQiIHk9IjYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjEycHgiPkNsb3VkIFNRTCBhZG1pbiBBUEk8L3RleHQ+Cjx0ZXh0IHg9IjcwNCIgeT0iOTQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5iYWNrdXBzIMK3IHJlc3RvcmVzIMK3IHJlcGxpY2FzPC90ZXh0Pgo8dGV4dCB4PSI3MDQiIHk9IjExMSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPmZhaWxvdmVyIMK3IHVwZGF0ZXMgwrcgZmxhZ3M8L3RleHQ+Cjwvc3ZnPg==) ![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+cmVwbGljYSDCtyBmYWlsb3ZlcjwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSIxMTYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5wYXJhbWV0ZXJzIMK3IHJlYm9vdDwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSIxNDIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4Ij5zYW1lIHJlcXVlc3QgLyByZXNwb25zZSBzaGFwZXM8L3RleHQ+CjxsaW5lIHgxPSIyNTIiIHkxPSI3NCIgeDI9IjMxNCIgeTI9Ijc0IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhjLXJkcy1jbG91ZC1zcWwtYWRtaW4tYXBpKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxsaW5lIHgxPSIzMTgiIHkxPSIxMjgiIHgyPSIyNTYiIHkyPSIxMjgiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWNsb3VkLXNxbC1hZG1pbi1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHJlY3QgeD0iMzE4IiB5PSI1NCIgd2lkdGg9IjIwNCIgaGVpZ2h0PSI4OCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNyIgc3R5bGU9ImZpbGw6IzA2NGUzYjtzdHJva2U6IzZlZTdiNyIvPgo8dGV4dCB4PSI0MjAiIHk9Ijk0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNzAwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNzsgZm9udC1zaXplOjEycHgiPlRlbnNvcjk8L3RleHQ+CiAgPHRleHQgeD0iNDIwIiB5PSIxMTIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMC41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3YjciPnNlcnZpY2UgYWRhcHRlcjwvdGV4dD4KPGxpbmUgeDE9IjUyMiIgeTE9Ijc0IiB4Mj0iNTg0IiB5Mj0iNzQiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWNsb3VkLXNxbC1hZG1pbi1hcGkpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPGxpbmUgeDE9IjU4OCIgeTE9IjEyOCIgeDI9IjUyNiIgeTI9IjEyOCIgc3Ryb2tlLXdpZHRoPSIyIiBtYXJrZXItZW5kPSJ1cmwoI2FoYy1yZHMtY2xvdWQtc3FsLWFkbWluLWFwaSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8cmVjdCB4PSI1ODgiIHk9IjM0IiB3aWR0aD0iMjMyIiBoZWlnaHQ9IjEyOCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSI3MDQiIHk9IjYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjEycHgiPkNsb3VkIFNRTCBhZG1pbiBBUEk8L3RleHQ+Cjx0ZXh0IHg9IjcwNCIgeT0iOTQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5iYWNrdXBzIMK3IHJlc3RvcmVzIMK3IHJlcGxpY2FzPC90ZXh0Pgo8dGV4dCB4PSI3MDQiIHk9IjExMSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPmZhaWxvdmVyIMK3IHVwZGF0ZXMgwrcgZmxhZ3M8L3RleHQ+Cjwvc3ZnPg==) Tensor9 translates RDS management requests to the backend API and returns RDS responses. #### Limitations Where RDS PostgreSQL and Cloud SQL behind the proxy differ * **Connection pooling is not supported.** Each client session keeps its own Cloud SQL connection as the same SQL user, and the RDS Proxy APIs are not supported. * **Interrupted sessions are not replayed.** When the proxy restarts or loses its backend, sessions disconnect; clients reconnect to the same endpoint. Open transactions are not recovered. * **Kubernetes installations are not supported.** Only a Docker composition can use this backend. It runs one fixed proxy container per database, with one CPU and 256 MiB of memory, published on the host's loopback addresses. * **Deleting a database behaves differently: it keeps no final snapshot.** `DeleteDBInstance` requires `SkipFinalSnapshot=true` and does not keep automated backups. * **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, and RDS-specific parameters are rejected. * **Event subscriptions are not supported.** RDS event notifications publish to SNS. Cloud Monitoring works differently and has no direct equivalent. #### Other considerations **Hosting the proxy.** The proxy runs as one container per database beside Tensor9 on the Docker host, with a single fixed replica. Tensor9 tracks which running container confirmed each configuration, so if the container restarts without Tensor9 restarting it, the proxy reloads its configuration before its endpoint is reported again. **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 Cloud SQL instance in their Google Cloud project. Maintenance windows, quotas and pricing are Google's. Tensor9 runs the proxy container on its Docker host. **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. ##### RDS PostgreSQL · Primary allocated compute Feature: RDS 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. ![RDS 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/551d3c6bb1757cb21b492152f7f7c8ff952e1cf697c10fb0c2057a64332c317f-light.svg) ![RDS 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/9ea3b2e23cff075660cdb91432e534fabb14b8f28597de27603e255c9c84f130-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Primary allocated compute (vCPU-hours/month) | RDS PostgreSQL | Target scenario | Cloud SQL for PostgreSQL (RDS proxy) | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | 118.18 | 118.18 | | 0 | 0.00 | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | 236.36 | 236.36 | | 1,460 | 129.94 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | 118.18 | -11.76 | | 1,460 | 129.94 | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | 236.36 | 106.42 | | 2,920 | 259.88 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | 219.36 | -40.52 | | 2,920 | 259.88 | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | 438.71 | 178.83 | | 5,840 | 519.76 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | 421.71 | -98.05 | | 5,840 | 519.76 | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | 843.42 | 323.66 | | 11,680 | 1,039.52 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | 826.42 | -213.10 | | 11,680 | 1,039.52 | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | 1,652.85 | 613.33 | | 23,360 | 2,079.04 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | 1,635.85 | -443.19 | | 23,360 | 2,079.04 | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | 3,271.70 | 1,192.66 | | 46,720 | 4,158.08 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | 3,254.70 | -903.38 | | 46,720 | 4,158.08 | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | 6,509.39 | 2,351.31 | 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 (RDS proxy) (one copy) | Origin list price · Primary compute | 0.089 | USD/vCPU-hours | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Origin list price · Database reads | 0 | USD/operations | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Origin list price · Database writes | 0 | USD/operations | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target CPU / source CPU | 1 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target RAM / source RAM | 1 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target disk / source disk | 1 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · read | 0 | USD/read | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · write | 0 | USD/write | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target list price · GiB-month | 0.17 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target list price · network GiB | 0.19 | USD/network GiB | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target list price · GiB-hour | 0.007 | USD/GiB-hour | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · input token | 0 | USD/input token | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · output token | 0 | USD/output token | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target monthly base charge | 0 | USD/month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target service minimum | 9.365 | USD/month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Minimum primary CPU | 2 | vCPU | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Minimum primary RAM | 8 | GiB | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Minimum primary disk | 100 | GiB | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Allocated share of provisioned cost | 1 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Planning peak / mean work | 2 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Planning primary CPU utilization | 0.7 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Resident state reserved in RAM | 0.1 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Planning disk utilization | 0.8 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Maintenance and log disk reserve | 20 | GiB | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Origin list price · Primary compute | 0.089 | USD/vCPU-hours | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Origin list price · Database reads | 0 | USD/operations | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Origin list price · Database writes | 0 | USD/operations | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target CPU / source CPU | 1 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target RAM / source RAM | 1 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target disk / source disk | 1 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · read | 0 | USD/read | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · write | 0 | USD/write | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target list price · GiB-month | 0.17 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target list price · network GiB | 0.19 | USD/network GiB | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target list price · GiB-hour | 0.007 | USD/GiB-hour | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · input token | 0 | USD/input token | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · output token | 0 | USD/output token | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target monthly base charge | 0 | USD/month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target service minimum | 9.365 | USD/month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Minimum primary CPU | 2 | vCPU | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Minimum primary RAM | 8 | GiB | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Minimum primary disk | 100 | GiB | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Allocated share of provisioned cost | 1 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Planning peak / mean work | 2 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Planning primary CPU utilization | 0.7 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Resident state reserved in RAM | 0.1 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Planning disk utilization | 0.8 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Maintenance and log disk reserve | 20 | GiB | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Cloud SQL 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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-1dbf7e73343e44effdc50f2b5f5a2420ba0465c3` / `2026-10-22.planning.2`. Curve: `workload-1`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Cloud SQL pricing](https://cloud.google.com/sql/pricing). ##### RDS PostgreSQL · Stored data Feature: RDS PostgreSQL. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. ![RDS 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/80c2e772fbc47bc9e1b36acf2bb99b149a668218127560d68aae7e4343b8c25a-light.svg) ![RDS 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/83c155b6ab7a7d529e27f5caba972c788cf1fa7d65781798a78a9c0bde23432c-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Stored data (GiB-month) | RDS PostgreSQL | Target scenario | Cloud SQL for PostgreSQL (RDS proxy) | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | 118.18 | 118.18 | | 0 | 0.00 | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | 236.36 | 236.36 | | 10 | 1.15 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | 118.18 | 117.03 | | 10 | 1.15 | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | 236.36 | 235.21 | | 100 | 11.50 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | 126.68 | 115.18 | | 100 | 11.50 | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | 253.36 | 241.86 | | 1,000 | 115.00 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | 317.93 | 202.93 | | 1,000 | 115.00 | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | 635.86 | 520.86 | | 10,000 | 1,150.00 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | 2,230.43 | 1,080.43 | | 10,000 | 1,150.00 | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | 4,460.86 | 3,310.86 | | 100,000 | 11,500.00 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Unpriced | Unavailable | | 100,000 | 11,500.00 | Cloud SQL for PostgreSQL (RDS proxy) (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 (RDS proxy) (one copy) | Origin list price · Primary compute | 0.089 | USD/vCPU-hours | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Origin list price · Database reads | 0 | USD/operations | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Origin list price · Database writes | 0 | USD/operations | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target CPU / source CPU | 1 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target RAM / source RAM | 1 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target disk / source disk | 1 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · read | 0 | USD/read | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · write | 0 | USD/write | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target list price · GiB-month | 0.17 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target list price · network GiB | 0.19 | USD/network GiB | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target list price · GiB-hour | 0.007 | USD/GiB-hour | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · input token | 0 | USD/input token | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · output token | 0 | USD/output token | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target monthly base charge | 0 | USD/month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target service minimum | 9.365 | USD/month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Minimum primary CPU | 2 | vCPU | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Minimum primary RAM | 8 | GiB | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Minimum primary disk | 100 | GiB | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Allocated share of provisioned cost | 1 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Planning peak / mean work | 2 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Planning primary CPU utilization | 0.7 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Resident state reserved in RAM | 0.1 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Planning disk utilization | 0.8 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Maintenance and log disk reserve | 20 | GiB | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Origin list price · Primary compute | 0.089 | USD/vCPU-hours | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Origin list price · Database reads | 0 | USD/operations | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Origin list price · Database writes | 0 | USD/operations | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target CPU / source CPU | 1 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target RAM / source RAM | 1 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target disk / source disk | 1 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · read | 0 | USD/read | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · write | 0 | USD/write | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target list price · GiB-month | 0.17 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target list price · network GiB | 0.19 | USD/network GiB | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target list price · GiB-hour | 0.007 | USD/GiB-hour | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · input token | 0 | USD/input token | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · output token | 0 | USD/output token | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target monthly base charge | 0 | USD/month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target service minimum | 9.365 | USD/month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Minimum primary CPU | 2 | vCPU | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Minimum primary RAM | 8 | GiB | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Minimum primary disk | 100 | GiB | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Allocated share of provisioned cost | 1 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Planning peak / mean work | 2 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Planning primary CPU utilization | 0.7 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Resident state reserved in RAM | 0.1 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Planning disk utilization | 0.8 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Maintenance and log disk reserve | 20 | GiB | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Cloud SQL 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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-1dbf7e73343e44effdc50f2b5f5a2420ba0465c3` / `2026-10-22.planning.2`. Curve: `workload-2`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Cloud SQL pricing](https://cloud.google.com/sql/pricing). ##### RDS PostgreSQL · Database writes Feature: RDS PostgreSQL. Estimated monthly service charges by Database writes. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. ![RDS 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/4f9c504352a89c041e2f3dbb47da3f230db4cbeede12e5f2586ac0475e1904e9-light.svg) ![RDS 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/f4ec902373e04d283c2167175d9a0304cd3744fc56f3cc34d4963120e8234f1d-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Database writes (per second) | RDS PostgreSQL | Target scenario | Cloud SQL for PostgreSQL (RDS proxy) | Difference | | -: | -: | - | -: | -: | | 0 | 0.00 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | 118.18 | 118.18 | | 0 | 0.00 | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | 236.36 | 236.36 | | 1 | 0.00 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | 118.18 | 118.18 | | 1 | 0.00 | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | 236.36 | 236.36 | | 10 | 0.00 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | 118.18 | 118.18 | | 10 | 0.00 | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | 236.36 | 236.36 | | 100 | 0.00 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | 118.18 | 118.18 | | 100 | 0.00 | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | 236.36 | 236.36 | | 1,000 | 0.00 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | 118.18 | 118.18 | | 1,000 | 0.00 | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | 236.36 | 236.36 | | 10,000 | 0.00 | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | 118.18 | 118.18 | | 10,000 | 0.00 | Cloud SQL for PostgreSQL (RDS proxy) (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 (RDS proxy) (one copy) | Origin list price · Primary compute | 0.089 | USD/vCPU-hours | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Origin list price · Database reads | 0 | USD/operations | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Origin list price · Database writes | 0 | USD/operations | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target CPU / source CPU | 1 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target RAM / source RAM | 1 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target disk / source disk | 1 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · read | 0 | USD/read | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · write | 0 | USD/write | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · provider operation | 0 | USD/provider operation | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target list price · GiB-month | 0.17 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · published GiB | 0 | USD/published GiB | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target list price · network GiB | 0.19 | USD/network GiB | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target list price · GiB-hour | 0.007 | USD/GiB-hour | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · resource-hour | 0 | USD/resource-hour | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · resource-month | 0 | USD/resource-month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · input token | 0 | USD/input token | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target price guess · output token | 0 | USD/output token | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target monthly base charge | 0 | USD/month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Target service minimum | 9.365 | USD/month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Minimum primary CPU | 2 | vCPU | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Minimum primary RAM | 8 | GiB | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Minimum primary disk | 100 | GiB | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Additional full-price standby copy | 0 | 0 or 1 | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Allocated share of provisioned cost | 1 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Planning peak / mean work | 2 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Planning primary CPU utilization | 0.7 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Resident state reserved in RAM | 0.1 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Planning disk utilization | 0.8 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Maintenance and log disk reserve | 20 | GiB | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (one copy) | Dependent object sink write price guess | 0.000005 | USD/write | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Origin list price · Primary compute | 0.089 | USD/vCPU-hours | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Origin list price · Primary memory | 0 | USD/GiB-hours | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Origin list price · Database reads | 0 | USD/operations | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Origin list price · Database writes | 0 | USD/operations | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target CPU / source CPU | 1 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target RAM / source RAM | 1 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target disk / source disk | 1 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · read | 0 | USD/read | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · write | 0 | USD/write | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · provider operation | 0 | USD/provider operation | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target list price · GiB-month | 0.17 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · published GiB | 0 | USD/published GiB | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target list price · network GiB | 0.19 | USD/network GiB | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target list price · GiB-hour | 0.007 | USD/GiB-hour | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · resource-hour | 0 | USD/resource-hour | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · resource-month | 0 | USD/resource-month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · input token | 0 | USD/input token | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target price guess · output token | 0 | USD/output token | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target monthly base charge | 0 | USD/month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Target service minimum | 9.365 | USD/month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Minimum primary CPU | 2 | vCPU | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Minimum primary RAM | 8 | GiB | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Minimum primary disk | 100 | GiB | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Additional full-price standby copy | 1 | 0 or 1 | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Allocated share of provisioned cost | 1 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Planning peak / mean work | 2 | multiplier | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Planning primary CPU utilization | 0.7 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Resident state reserved in RAM | 0.1 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Planning disk utilization | 0.8 | fraction | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Maintenance and log disk reserve | 20 | GiB | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Cloud SQL for PostgreSQL (RDS proxy) (two copies) | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Cloud SQL 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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-1dbf7e73343e44effdc50f2b5f5a2420ba0465c3` / `2026-10-22.planning.2`. Curve: `workload-3`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Cloud SQL pricing](https://cloud.google.com/sql/pricing). **RDS PostgreSQL → Cloud SQL 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 | 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.089 | USD/vCPU-hours | | Origin list price · Primary memory | 0 | USD/GiB-hours | | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Origin list price · Database reads | 0 | USD/operations | | Origin list price · Database writes | 0 | USD/operations | | Target CPU / source CPU | 1 | multiplier | | Target RAM / source RAM | 1 | multiplier | | Target disk / source disk | 1 | multiplier | | Target price guess · read | 0 | USD/read | | Target price guess · write | 0 | USD/write | | Target price guess · provider operation | 0 | USD/provider operation | | Target list price · GiB-month | 0.17 | USD/GiB-month | | Target price guess · published GiB | 0 | USD/published GiB | | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Target list price · network GiB | 0.19 | USD/network GiB | | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Target list price · vCPU-hour | 0.0413 | USD/vCPU-hour | | Target list price · GiB-hour | 0.007 | USD/GiB-hour | | Target price guess · resource-hour | 0 | USD/resource-hour | | Target price guess · resource-month | 0 | USD/resource-month | | Target price guess · input token | 0 | USD/input token | | Target price guess · output token | 0 | USD/output token | | Target monthly base charge | 0 | USD/month | | Target service minimum | 9.365 | USD/month | | Minimum primary CPU | 2 | vCPU | | Minimum primary RAM | 8 | GiB | | Minimum primary disk | 100 | GiB | | Additional full-price standby copy | 0 | 0 or 1 | | Allocated share of provisioned cost | 1 | fraction | | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Planning peak / mean work | 2 | multiplier | | Planning primary CPU utilization | 0.7 | fraction | | Resident state reserved in RAM | 0.1 | fraction | | Planning disk utilization | 0.8 | fraction | | Maintenance and log disk reserve | 20 | GiB | | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Dependent object sink write price guess | 0.000005 | USD/write | | Primary compute | 0 | vCPU-hours | | Primary memory | 0 | GiB-hours | | Primary provisioned storage | 0 | GiB-month | | Database reads | 0 | operations | | Database writes | 0 | operations | * Translated reads: 0 operations. * Translated writes: 0 operations. * Translated resident physical data: 0 GiB-month. * Native provider operations: 0 operations. * Published payload: 0 GiB. * Delivered payload: 0 GiB. * Allocated execution CPU: 0 vCPU-hour. * Allocated execution RAM: 0 GiB-hour. * Independent resource allocation: 0 resource-hour. * Independent inventory: 0 resource-month. * Input tokens: 0 tokens. * Output tokens: 0 tokens. * Billable network: 0 GiB. * Dependent object sink retained data: 0 GiB-month. * Dependent object sink writes: 0 writes. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Cloud SQL Enterprise edition (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-1dbf7e73343e44effdc50f2b5f5a2420ba0465c3` / `2026-10-22.planning.2`. Scenario: `planning-example`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Cloud SQL pricing](https://cloud.google.com/sql/pricing). ## On OCI ### OCI Database with PostgreSQL | Operation | Area | Support | Depth | Notes | | - | - | - | - | - | | AWS integration SQL: aws\_s3.\*, aws\_lambda.invoke, rds\_tools | SQL functions | Out of scope | Full surface | RDS extension functions with no counterpart on vanilla PostgreSQL; a query calling them fails | | pgwire protocol (application SQL) | Wire protocol | Supported | Common | same PostgreSQL engine; application SQL is unchanged | #### How it works Your application's PostgreSQL driver connects directly to OCI Database with PostgreSQL. These database requests are the **data plane**. The driver and the PostgreSQL wire protocol stay the same, and Tensor9 does not proxy or translate 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 OCI Database with PostgreSQL runs the same engine as RDS for PostgreSQL. Your SQL, drivers, object-relational mappers (ORMs), prepared statements, data types and transaction behavior stay the same. Your application connects directly to the database. RDS adds SQL functions for importing and exporting through S3 and for invoking Lambda from a query. These AWS-specific 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 read replicas, stop / start, and compute, storage and configuration updates. The adapter does not translate every native OCI feature into RDS behavior; the limitations below list the differences. An unsupported operation returns an error. With Max, your tools call `CreateDBInstance` and `DeleteDBInstance` through the RDS adapter to create and remove a database on OCI PostgreSQL. Tensor9 keeps a durable record of each logical database and reconciles OCI with it: it records each accepted request, then creates or removes the OCI resources in the background. Call `DescribeDBInstances` to follow the status and get the database endpoint. Your application's SQL connection still goes directly to the database. With the Infrastructure-only option, Tensor9 compiles the declared database 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+UkRTIG1hbmFnZW1lbnQgY2FsbDwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSI4MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPnNuYXBzaG90IMK3IHBvaW50LWluLXRpbWUgcmVzdG9yZTwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSI5OSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPnJlcGxpY2EgwrcgZmFpbG92ZXIgwrcgc3RvcCAvIHN0YXJ0PC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9IjExNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPmluc3RhbmNlIGNsYXNzIMK3IHBhcmFtZXRlcnM8L3RleHQ+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+UkRTIG1hbmFnZW1lbnQgY2FsbDwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSI4MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPnNuYXBzaG90IMK3IHBvaW50LWluLXRpbWUgcmVzdG9yZTwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSI5OSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPnJlcGxpY2EgwrcgZmFpbG92ZXIgwrcgc3RvcCAvIHN0YXJ0PC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9IjExNiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPmluc3RhbmNlIGNsYXNzIMK3IHBhcmFtZXRlcnM8L3RleHQ+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 RDS 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. * **RDS cross-region read replicas 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 AWS cross-region replica semantics. * **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. * **Event subscriptions and RDS-specific settings are not supported.** Event subscriptions, `rds.*` parameters and RDS-specific settings (the CA certificate, Enhanced Monitoring, Kerberos / AD) have no equivalent, as on every backend. #### Other considerations **Migration.** Move existing data with a logical dump and restore, or use logical replication to shorten the cutover pause. Check the selected PostgreSQL version and the extensions you need, and switch application connections only after you have checked the copied data. **Operations.** The customer owns the database service in their OCI tenancy. Maintenance windows, quotas and pricing are Oracle's. **Features and capacity.** The comparison table on this page lists 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. ##### RDS PostgreSQL · Primary allocated compute Feature: RDS 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. ![RDS 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/a4ea0c4e913ab88dc77d394a303d672b28fc01b60bd85e04024a3e74dfefcf47-light.svg) ![RDS 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/fe1033a292217962e109cb9632daf72b7913b0edaf24d5f8cb94c55be8ab1cd5-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Primary allocated compute (vCPU-hours/month) | RDS 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 | 129.94 | OCI Database with PostgreSQL (one copy) | 94.90 | -35.04 | | 1,460 | 129.94 | OCI Database with PostgreSQL (two copies) | 173.64 | 43.70 | | 2,920 | 259.88 | OCI Database with PostgreSQL (one copy) | 173.64 | -86.24 | | 2,920 | 259.88 | OCI Database with PostgreSQL (two copies) | 340.08 | 80.20 | | 5,840 | 519.76 | OCI Database with PostgreSQL (one copy) | 340.08 | -179.68 | | 5,840 | 519.76 | OCI Database with PostgreSQL (two copies) | 672.96 | 153.20 | | 11,680 | 1,039.52 | OCI Database with PostgreSQL (one copy) | 672.96 | -366.56 | | 11,680 | 1,039.52 | OCI Database with PostgreSQL (two copies) | 1,338.72 | 299.20 | | 23,360 | 2,079.04 | OCI Database with PostgreSQL (one copy) | 1,338.72 | -740.32 | | 23,360 | 2,079.04 | OCI Database with PostgreSQL (two copies) | 2,670.24 | 591.20 | | 46,720 | 4,158.08 | OCI Database with PostgreSQL (one copy) | 2,670.24 | -1,487.84 | | 46,720 | 4,158.08 | OCI Database with PostgreSQL (two copies) | 5,333.28 | 1,175.20 | 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.089 | 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.115 | 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.089 | 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.115 | 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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-d81a7cca1998e220a08619ab9bb758089ead10f3` / `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/). ##### RDS PostgreSQL · Stored data Feature: RDS 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. ![RDS 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/ef3c1c82d179cb5ebb184cb5ed4db70a288eb81876f54c82c6842768e6a4253b-light.svg) ![RDS 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/ca71425844901a8da0655566b538da4543300b07280487174b83a8178782833c-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Stored data (GiB-month) | RDS 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.15 | OCI Database with PostgreSQL (one copy) | 94.90 | 93.75 | | 10 | 1.15 | OCI Database with PostgreSQL (two copies) | 173.64 | 172.49 | | 100 | 11.50 | OCI Database with PostgreSQL (one copy) | 94.90 | 83.40 | | 100 | 11.50 | OCI Database with PostgreSQL (two copies) | 177.24 | 165.74 | | 1,000 | 115.00 | OCI Database with PostgreSQL (one copy) | 175.02 | 60.02 | | 1,000 | 115.00 | OCI Database with PostgreSQL (two copies) | 258.24 | 143.24 | | 10,000 | 1,150.00 | OCI Database with PostgreSQL (one copy) | 985.02 | -164.98 | | 10,000 | 1,150.00 | OCI Database with PostgreSQL (two copies) | 1,068.24 | -81.76 | | 100,000 | 11,500.00 | OCI Database with PostgreSQL (one copy) | Unpriced | Unavailable | | 100,000 | 11,500.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.089 | 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.115 | 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.089 | 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.115 | 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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-d81a7cca1998e220a08619ab9bb758089ead10f3` / `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/). ##### RDS PostgreSQL · Database writes Feature: RDS 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. ![RDS 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/463c37767cd6412a9fbad58cfc39fbf9220f59730e0d280e778139b6b0c8a4f8-light.svg) ![RDS 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/c5d2d6e414a96f9f967093635585992ef9c46561e0c1cbfcbde5fe8f23ab4561-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Database writes (per second) | RDS 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.089 | 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.115 | 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.089 | 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.115 | 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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-d81a7cca1998e220a08619ab9bb758089ead10f3` / `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/). **RDS 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.089 | USD/vCPU-hours | | Origin list price · Primary memory | 0 | USD/GiB-hours | | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Origin list price · Database reads | 0 | USD/operations | | Origin list price · Database writes | 0 | USD/operations | | Target CPU / source CPU | 1 | multiplier | | Target RAM / source RAM | 1 | multiplier | | Target disk / source disk | 1 | multiplier | | Target price guess · read | 0 | USD/read | | Target price guess · write | 0 | USD/write | | Target price guess · provider operation | 0 | USD/provider operation | | Target list price · GiB-month | 0.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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-d81a7cca1998e220a08619ab9bb758089ead10f3` / `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 integration SQL: aws\_s3.\*, aws\_lambda.invoke, rds\_tools | SQL functions | Out of scope | Full surface | RDS extension functions with no counterpart on vanilla PostgreSQL; a query calling them fails | | pgwire protocol (application SQL) | Wire protocol | Supported | Common | same PostgreSQL engine; application SQL is unchanged | #### How it works Your application's PostgreSQL driver connects directly to CloudNativePG. These database requests are the **data plane**. The driver and the PostgreSQL wire protocol stay the same, and Tensor9 does not proxy or translate 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 CloudNativePG runs PostgreSQL as a replicated cluster on Kubernetes. Your SQL, drivers, object-relational mappers (ORMs), prepared statements, data types and transaction behavior stay the same. Your application connects directly to the cluster. RDS adds SQL functions for importing and exporting through S3 and for invoking Lambda from a query. These AWS-specific 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. Read replicas change the cluster's instance count, and manual failover promotes a replica. Stop / start means hibernating and resuming the cluster while retaining its storage. Parameter changes update the cluster's PostgreSQL configuration. CloudNativePG's built-in pooler takes the place of RDS Proxy for managed connection pooling. When your product is deployed into the target environment, Tensor9 compiles the database 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+Cjx0ZXh0IHg9IjEzNCIgeT0iOTkiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5yZXBsaWNhIMK3IGZhaWxvdmVyIMK3IHN0b3AgLyBzdGFydDwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSIxMTYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5pbnN0YW5jZSBjbGFzcyDCtyBwYXJhbWV0ZXJzPC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9IjE0MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGIiPnNhbWUgcmVxdWVzdCAvIHJlc3BvbnNlIHNoYXBlczwvdGV4dD4KPGxpbmUgeDE9IjI1MiIgeTE9Ijc0IiB4Mj0iMzE0IiB5Mj0iNzQiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWNsb3VkbmF0aXZlcGctcmVzb3VyY2VzKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxsaW5lIHgxPSIzMTgiIHkxPSIxMjgiIHgyPSIyNTYiIHkyPSIxMjgiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWNsb3VkbmF0aXZlcGctcmVzb3VyY2VzKSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+CjxyZWN0IHg9IjMxOCIgeT0iNTQiIHdpZHRoPSIyMDQiIGhlaWdodD0iODgiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iNDIwIiB5PSI5NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICMwNDc4NTc7IGZvbnQtc2l6ZToxMnB4Ij5UZW5zb3I5PC90ZXh0PgogIDx0ZXh0IHg9IjQyMCIgeT0iMTEyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij5zZXJ2aWNlIGFkYXB0ZXI8L3RleHQ+CjxsaW5lIHgxPSI1MjIiIHkxPSI3NCIgeDI9IjU4NCIgeTI9Ijc0IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhjLXJkcy1jbG91ZG5hdGl2ZXBnLXJlc291cmNlcykiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8bGluZSB4MT0iNTg4IiB5MT0iMTI4IiB4Mj0iNTI2IiB5Mj0iMTI4IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhjLXJkcy1jbG91ZG5hdGl2ZXBnLXJlc291cmNlcykiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8cmVjdCB4PSI1ODgiIHk9IjM0IiB3aWR0aD0iMjMyIiBoZWlnaHQ9IjEyOCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSI3MDQiIHk9IjYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzBmMTcyYTsgZm9udC1zaXplOjEycHgiPkNsb3VkTmF0aXZlUEcgcmVzb3VyY2VzPC90ZXh0Pgo8dGV4dCB4PSI3MDQiIHk9Ijk0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+YmFja3VwcyDCtyByZWNvdmVyeSDCtyByZXBsaWNhczwvdGV4dD4KPHRleHQgeD0iNzA0IiB5PSIxMTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5wcm9tb3Rpb24gwrcgY29uZmlndXJhdGlvbjwvdGV4dD4KPC9zdmc+) ![The Tensor9 service adapter handles RDS management requests using CloudNativePG resources and returns RDS responses.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMTk2IiB2aWV3Qm94PSIwIDAgODM2IDE5NiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJUaGUgVGVuc29yOSBzZXJ2aWNlIGFkYXB0ZXIgaGFuZGxlcyBSRFMgbWFuYWdlbWVudCByZXF1ZXN0cyB1c2luZyBDbG91ZE5hdGl2ZVBHIHJlc291cmNlcyBhbmQgcmV0dXJucyBSRFMgcmVzcG9uc2VzLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaGMtcmRzLWNsb3VkbmF0aXZlcGctcmVzb3VyY2VzIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM2NDc0OGIiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjE2IiB5PSIzNCIgd2lkdGg9IjIzNiIgaGVpZ2h0PSIxMjgiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iMTM0IiB5PSI2MCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDY1MCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICNmMWY1Zjk7IGZvbnQtc2l6ZToxMi41cHgiPlJEUyBtYW5hZ2VtZW50IGNhbGw8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iODIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5zbmFwc2hvdCDCtyBwb2ludC1pbi10aW1lIHJlc3RvcmU8L3RleHQ+Cjx0ZXh0IHg9IjEzNCIgeT0iOTkiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5yZXBsaWNhIMK3IGZhaWxvdmVyIMK3IHN0b3AgLyBzdGFydDwvdGV4dD4KPHRleHQgeD0iMTM0IiB5PSIxMTYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5pbnN0YW5jZSBjbGFzcyDCtyBwYXJhbWV0ZXJzPC90ZXh0Pgo8dGV4dCB4PSIxMzQiIHk9IjE0MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjgiPnNhbWUgcmVxdWVzdCAvIHJlc3BvbnNlIHNoYXBlczwvdGV4dD4KPGxpbmUgeDE9IjI1MiIgeTE9Ijc0IiB4Mj0iMzE0IiB5Mj0iNzQiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWNsb3VkbmF0aXZlcGctcmVzb3VyY2VzKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxsaW5lIHgxPSIzMTgiIHkxPSIxMjgiIHgyPSIyNTYiIHkyPSIxMjgiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGMtcmRzLWNsb3VkbmF0aXZlcGctcmVzb3VyY2VzKSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+CjxyZWN0IHg9IjMxOCIgeT0iNTQiIHdpZHRoPSIyMDQiIGhlaWdodD0iODgiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iNDIwIiB5PSI5NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDcwMCAxMy41cHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2ZWU3Yjc7IGZvbnQtc2l6ZToxMnB4Ij5UZW5zb3I5PC90ZXh0PgogIDx0ZXh0IHg9IjQyMCIgeT0iMTEyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTAuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij5zZXJ2aWNlIGFkYXB0ZXI8L3RleHQ+CjxsaW5lIHgxPSI1MjIiIHkxPSI3NCIgeDI9IjU4NCIgeTI9Ijc0IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhjLXJkcy1jbG91ZG5hdGl2ZXBnLXJlc291cmNlcykiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8bGluZSB4MT0iNTg4IiB5MT0iMTI4IiB4Mj0iNTI2IiB5Mj0iMTI4IiBzdHJva2Utd2lkdGg9IjIiIG1hcmtlci1lbmQ9InVybCgjYWhjLXJkcy1jbG91ZG5hdGl2ZXBnLXJlc291cmNlcykiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8cmVjdCB4PSI1ODgiIHk9IjM0IiB3aWR0aD0iMjMyIiBoZWlnaHQ9IjEyOCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSI3MDQiIHk9IjYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogNjUwIDEzLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogI2YxZjVmOTsgZm9udC1zaXplOjEycHgiPkNsb3VkTmF0aXZlUEcgcmVzb3VyY2VzPC90ZXh0Pgo8dGV4dCB4PSI3MDQiIHk9Ijk0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+YmFja3VwcyDCtyByZWNvdmVyeSDCtyByZXBsaWNhczwvdGV4dD4KPHRleHQgeD0iNzA0IiB5PSIxMTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5wcm9tb3Rpb24gwrcgY29uZmlndXJhdGlvbjwvdGV4dD4KPC9zdmc+) Tensor9 translates RDS management requests to the backend API and returns RDS responses. #### Limitations Where RDS and CloudNativePG differ * **Cross-region read replicas are not supported.** The Cloud Adapter deployment runs a single CloudNativePG cluster; a second region would need a second Cloud Adapter deployment. * **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 and `rds.*` parameters are not supported on the backend. * **RDS-specific settings are not supported.** The CA certificate, Enhanced Monitoring, processor features and Kerberos / AD domain join have no CloudNativePG equivalent. #### Other considerations **Migration.** Move existing data with a logical dump and restore, or use logical replication to shorten the cutover pause. Check the selected PostgreSQL version and the extensions you need, and switch application connections only after you have checked the copied data. **Operations.** CloudNativePG is self-operated: after cutover the customer's team runs the cluster (backups, upgrades, failover drills), with no cloud database vendor behind it. **Features and capacity.** The comparison table on this page lists 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. ##### RDS PostgreSQL · Primary allocated compute Feature: RDS 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. ![RDS 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/9a71066363df5197a6f64a4c86e1b07e73bce217016db61c3ff10485c6777e9c-light.svg) ![RDS 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/75ddfb694b2cb2445183c47318080f4ddabff6263cd3ace45ebb765d809c26f2-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Primary allocated compute (vCPU-hours/month) | RDS 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 | 129.94 | PostgreSQL (CloudNativePG) (one copy) | 80.90 | -49.04 | | 1,460 | 129.94 | PostgreSQL (CloudNativePG) (two copies) | 161.79 | 31.85 | | 2,920 | 259.88 | PostgreSQL (CloudNativePG) (one copy) | 151.79 | -108.09 | | 2,920 | 259.88 | PostgreSQL (CloudNativePG) (two copies) | 303.58 | 43.70 | | 5,840 | 519.76 | PostgreSQL (CloudNativePG) (one copy) | 293.58 | -226.18 | | 5,840 | 519.76 | PostgreSQL (CloudNativePG) (two copies) | 587.17 | 67.41 | | 11,680 | 1,039.52 | PostgreSQL (CloudNativePG) (one copy) | 577.17 | -462.35 | | 11,680 | 1,039.52 | PostgreSQL (CloudNativePG) (two copies) | 1,154.34 | 114.82 | | 23,360 | 2,079.04 | PostgreSQL (CloudNativePG) (one copy) | 1,144.34 | -934.70 | | 23,360 | 2,079.04 | PostgreSQL (CloudNativePG) (two copies) | 2,288.68 | 209.64 | | 46,720 | 4,158.08 | PostgreSQL (CloudNativePG) (one copy) | 2,278.68 | -1,879.40 | | 46,720 | 4,158.08 | PostgreSQL (CloudNativePG) (two copies) | 4,557.35 | 399.27 | 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.089 | 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.115 | 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.089 | 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.115 | 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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-e86e5324ae76bdb19c4a0e6a1eed4450d01c44e5` / `2026-10-22.planning.2`. Curve: `workload-1`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Compute Engine general-purpose machine pricing](https://cloud.google.com/products/compute/pricing/general-purpose), [Disk and image pricing](https://cloud.google.com/compute/disks-image-pricing), [Network pricing](https://cloud.google.com/vpc/network-pricing). ##### RDS PostgreSQL · Stored data Feature: RDS PostgreSQL. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. ![RDS 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/e4bd8a9583e4d39a42904c15db432e1f70e48edda87017f5707e5bae7aa53668-light.svg) ![RDS 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/5f7479ebc5ede2576c98375bab4b22e3bd19db76e916a0dcd141f3fce3e509ab-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Stored data (GiB-month) | RDS 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.15 | PostgreSQL (CloudNativePG) (one copy) | 80.90 | 79.75 | | 10 | 1.15 | PostgreSQL (CloudNativePG) (two copies) | 161.79 | 160.64 | | 100 | 11.50 | PostgreSQL (CloudNativePG) (one copy) | 85.90 | 74.40 | | 100 | 11.50 | PostgreSQL (CloudNativePG) (two copies) | 171.79 | 160.29 | | 1,000 | 115.00 | PostgreSQL (CloudNativePG) (one copy) | 198.40 | 83.40 | | 1,000 | 115.00 | PostgreSQL (CloudNativePG) (two copies) | 396.79 | 281.79 | | 10,000 | 1,150.00 | PostgreSQL (CloudNativePG) (one copy) | 1,323.40 | 173.40 | | 10,000 | 1,150.00 | PostgreSQL (CloudNativePG) (two copies) | 2,646.79 | 1,496.79 | | 100,000 | 11,500.00 | PostgreSQL (CloudNativePG) (one copy) | Unpriced | Unavailable | | 100,000 | 11,500.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.089 | 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.115 | 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.089 | 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.115 | 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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-e86e5324ae76bdb19c4a0e6a1eed4450d01c44e5` / `2026-10-22.planning.2`. Curve: `workload-2`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Compute Engine general-purpose machine pricing](https://cloud.google.com/products/compute/pricing/general-purpose), [Disk and image pricing](https://cloud.google.com/compute/disks-image-pricing), [Network pricing](https://cloud.google.com/vpc/network-pricing). ##### RDS PostgreSQL · Database writes Feature: RDS PostgreSQL. Estimated monthly service charges by Database writes. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. ![RDS 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/0299f66dcab210e2a91ed77fd99306ebe81174ef482931a3245835e6026dd442-light.svg) ![RDS 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/0912c37b5b5af19b254072bed9ff268a80443e0a1787fa1af3cb30857656a099-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Database writes (per second) | RDS 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.089 | 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.115 | 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.089 | 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.115 | 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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-e86e5324ae76bdb19c4a0e6a1eed4450d01c44e5` / `2026-10-22.planning.2`. Curve: `workload-3`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Compute Engine general-purpose machine pricing](https://cloud.google.com/products/compute/pricing/general-purpose), [Disk and image pricing](https://cloud.google.com/compute/disks-image-pricing), [Network pricing](https://cloud.google.com/vpc/network-pricing). **RDS 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.089 | USD/vCPU-hours | | Origin list price · Primary memory | 0 | USD/GiB-hours | | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Origin list price · Database reads | 0 | USD/operations | | Origin list price · Database writes | 0 | USD/operations | | Target CPU / source CPU | 1 | multiplier | | Target RAM / source RAM | 1 | multiplier | | Target disk / source disk | 1 | multiplier | | Target price guess · read | 0 | USD/read | | Target price guess · write | 0 | USD/write | | Target price guess · provider operation | 0 | USD/provider operation | | Target list price · GiB-month | 0.1 | USD/GiB-month | | Target price guess · published GiB | 0 | USD/published GiB | | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Target list price · network GiB | 0.12 | USD/network GiB | | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Target list price · vCPU-hour | 0.031611 | USD/vCPU-hour | | Target list price · GiB-hour | 0.004237 | USD/GiB-hour | | Target price guess · resource-hour | 0 | USD/resource-hour | | Target price guess · resource-month | 0 | USD/resource-month | | Target price guess · input token | 0 | USD/input token | | Target price guess · output token | 0 | USD/output token | | Target monthly base charge | 0 | USD/month | | Approximate target service minimum | 0 | USD/month | | Minimum primary CPU | 2 | vCPU | | Minimum primary RAM | 8 | GiB | | Minimum primary disk | 100 | GiB | | Additional full-price standby copy | 0 | 0 or 1 | | Allocated share of provisioned cost | 1 | fraction | | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Planning peak / mean work | 2 | multiplier | | Planning primary CPU utilization | 0.7 | fraction | | Resident state reserved in RAM | 0.1 | fraction | | Planning disk utilization | 0.8 | fraction | | Maintenance and log disk reserve | 20 | GiB | | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Dependent object sink write price guess | 0.000005 | USD/write | | Primary compute | 0 | vCPU-hours | | Primary memory | 0 | GiB-hours | | Primary provisioned storage | 0 | GiB-month | | Database reads | 0 | operations | | Database writes | 0 | operations | * Translated reads: 0 operations. * Translated writes: 0 operations. * Translated resident physical data: 0 GiB-month. * Native provider operations: 0 operations. * Published payload: 0 GiB. * Delivered payload: 0 GiB. * Allocated execution CPU: 0 vCPU-hour. * Allocated execution RAM: 0 GiB-hour. * Independent resource allocation: 0 resource-hour. * Independent inventory: 0 resource-month. * Input tokens: 0 tokens. * Output tokens: 0 tokens. * Billable network: 0 GiB. * Dependent object sink retained data: 0 GiB-month. * Dependent object sink writes: 0 writes. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Self-hosted target: 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-e86e5324ae76bdb19c4a0e6a1eed4450d01c44e5` / `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. | | 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 RDS PostgreSQL database instance 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. A Multi-AZ instance 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 RDS PostgreSQL database instance into Scaleway Managed DB at deployment; there is no management API at runtime.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgcGd3aXJlKSBjb25uZWN0IGRpcmVjdGx5IHRvIFNjYWxld2F5IE1hbmFnZWQgREIuIFRlbnNvcjkgY29tcGlsZXMgdGhlIFJEUyBQb3N0Z3JlU1FMIGRhdGFiYXNlIGluc3RhbmNlIGludG8gU2NhbGV3YXkgTWFuYWdlZCBEQiBhdCBkZXBsb3ltZW50OyB0aGVyZSBpcyBubyBtYW5hZ2VtZW50IEFQSSBhdCBydW50aW1lLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6IzMzNDE1NX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaGQtZGVwbG95LXNjYWxld2F5LW1hbmFnZWQtZGIiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjciIG1hcmtlckhlaWdodD0iNyIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6Izk0YTNiOCIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iOCIgeT0iMzQiIHdpZHRoPSI4MjAiIGhlaWdodD0iMjA2IiByeD0iMTYiIHN0cm9rZS13aWR0aD0iMS40IiBzdHJva2UtZGFzaGFycmF5PSI1IDUiIHN0eWxlPSJmaWxsOiNmOGZhZmM7c3Ryb2tlOiNjYmQ1ZTEiLz4KPHRleHQgeD0iMjYiIHk9IjU0IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzk0YTNiODsgZmlsbDojMDQ3ODU3Ij5PTiBTQ0FMRVdBWTwvdGV4dD4KPHN2ZyB4PSI3OTIiIHk9IjM2IiB3aWR0aD0iMTYiIGhlaWdodD0iMTYiIHZpZXdCb3g9IjAgMCAxNiAxNiIgcHJlc2VydmVBc3BlY3RSYXRpbz0ieE1pZFlNaWQgbWVldCIgZmlsbD0ibm9uZSI+PHBhdGggZD0iTTguMzcgMy42NjZINS43MzZBMS4xODIgMS4xODIgMCAwIDAgNC42OSA0Ljc5djMuODFjMCAuMjU3LjEuNDguMjY3LjY0Ny4xNjYuMTY3LjM4OS4yNjcuNjQ0LjI2Ny41IDAgLjkxMi0uNDEyLjkxMi0uOTEzVjYuMTg0YzAtLjM3OS4zMTEtLjY5MS42OS0uNjkxaDEuMTg5Yy4yNTUgMCAuNDc4LS4xLjY0NC0uMjY3YS45MjcuOTI3IDAgMCAwIC4yNjctLjY1OGMwLS41MDEtLjQzMy0uOTAyLS45MzQtLjkwMlpNNy4xODEgMTIuMzU3aDIuNjM1YTEuMTgxIDEuMTgxIDAgMCAwIDEuMDQ1LTEuMTI2di0zLjgxYS45LjkgMCAwIDAtLjI2Ny0uNjQ3Ljg5Ny44OTcgMCAwIDAtLjY0NS0uMjY3Yy0uNSAwLS45MTIuNDEyLS45MTIuOTE0djIuNDE3YzAgLjM4LS4zMS42OTEtLjY4OS42OTFoLTEuMTljLS4yNTUgMC0uNDc3LjEtLjY0NC4yNjhhLjkyNy45MjcgMCAwIDAtLjI2Ny42NTcuOTM0LjkzNCAwIDAgMCAuOTM0LjkwMloiIGZpbGw9IiNCRjk1RjkiLz4gPHBhdGggZmlsbC1ydWxlPSJldmVub2RkIiBjbGlwLXJ1bGU9ImV2ZW5vZGQiIGQ9Ik00LjAyNCAwaDQuNzkxYTUuNjgzIDUuNjgzIDAgMCAxIDUuNjkyIDUuNzE2djcuNTg4QTMuMDI3IDMuMDI3IDAgMCAxIDExLjc1IDE2SDYuNzAzQzMuNTU3IDE2IDEgMTMuNDM3IDEgMTAuMjg0VjMuMDMxQTMuMDMgMy4wMyAwIDAgMSA0LjAyNCAwWm04LjY3IDUuNzE2YzAtMi4xNC0xLjc0NC0zLjg4OS0zLjg3OS0zLjg4OWgtNC43OGMtLjY2NyAwLTEuMi41MzUtMS4yIDEuMjA0djcuMjUzYTMuODggMy44OCAwIDAgMCAzLjg4IDMuODg5aDQuOTU3YTEuMTkzIDEuMTkzIDAgMCAwIDEuMDIzLS45OFY1LjcxNVoiIGZpbGw9IiNCRjk1RjkiLz48L3N2Zz4KPHJlY3QgeD0iMjYiIHk9Ijc2IiB3aWR0aD0iMTI4IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjkwIiB5PSIxMDAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTNweCI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIxMTciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5Qb3N0Z3JlU1FMIGRyaXZlcjwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjEzMiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3Ij51bmNoYW5nZWQ8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iODIiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4OyBmaWxsOiMwNDc4NTciPkRBVEFCQVNFIFJFUVVFU1RTIMK3IERJUkVDVCBDT05ORUNUSU9OPC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTA4IiB4Mj0iNjEwIiB5Mj0iMTA4IiBzdHJva2Utd2lkdGg9IjIuMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtZGVwbG95LXNjYWxld2F5LW1hbmFnZWQtZGIpIiBzdHlsZT0ic3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iMzgyIiB5PSIxMDAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiMwNDc4NTciPlNRTCBvdmVyIHBnd2lyZTwvdGV4dD4KPHJlY3QgeD0iNjE0IiB5PSI3NiIgd2lkdGg9IjE5NiIgaGVpZ2h0PSI2NCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2NiZDVlMSIvPgo8c3ZnIHg9Ijc4NiIgeT0iNTYiIHdpZHRoPSIyMCIgaGVpZ2h0PSIyMCIgdmlld0JveD0iMCAwIDQzMi4wNzEgNDQ1LjM4MyIgcHJlc2VydmVBc3BlY3RSYXRpbz0ieE1pZFlNaWQgbWVldCI+PGcgc3R5bGU9ImZpbGwtcnVsZTpub256ZXJvO2NsaXAtcnVsZTpub256ZXJvO3N0cm9rZTojMDAwMDAwO3N0cm9rZS1taXRlcmxpbWl0OjQiPiA8L2c+IDxnIHN0eWxlPSJmaWxsLXJ1bGU6bm9uemVybztjbGlwLXJ1bGU6bm9uemVybztmaWxsOm5vbmU7c3Ryb2tlOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjEyLjQ2NTE7c3Ryb2tlLWxpbmVjYXA6cm91bmQ7c3Ryb2tlLWxpbmVqb2luOnJvdW5kO3N0cm9rZS1taXRlcmxpbWl0OjQiPiA8cGF0aCBkPSJNMzIzLjIwNSwzMjQuMjI3YzIuODMzLTIzLjYwMSwxLjk4NC0yNy4wNjIsMTkuNTYzLTIzLjIzOWw0LjQ2MywwLjM5MmMxMy41MTcsMC42MTUsMzEuMTk5LTIuMTc0LDQxLjU4Ny03YzIyLjM2Mi0xMC4zNzYsMzUuNjIyLTI3LjcsMTMuNTcyLTIzLjE0OGMtNTAuMjk3LDEwLjM3Ni01My43NTUtNi42NTUtNTMuNzU1LTYuNjU1YzUzLjExMS03OC44MDMsNzUuMzEzLTE3OC44MzYsNTYuMTQ5LTIwMy4zMjIgQzM1Mi41MTQtNS41MzQsMjYyLjAzNiwyNi4wNDksMjYwLjUyMiwyNi44NjlsLTAuNDgyLDAuMDg5Yy05LjkzOC0yLjA2Mi0yMS4wNi0zLjI5NC0zMy41NTQtMy40OTZjLTIyLjc2MS0wLjM3NC00MC4wMzIsNS45NjctNTMuMTMzLDE1LjkwNGMwLDAtMTYxLjQwOC02Ni40OTgtMTUzLjg5OSw4My42MjhjMS41OTcsMzEuOTM2LDQ1Ljc3NywyNDEuNjU1LDk4LjQ3LDE3OC4zMSBjMTkuMjU5LTIzLjE2MywzNy44NzEtNDIuNzQ4LDM3Ljg3MS00Mi43NDhjOS4yNDIsNi4xNCwyMC4zMDcsOS4yNzIsMzEuOTEyLDguMTQ3bDAuODk3LTAuNzY1Yy0wLjI4MSwyLjg3Ni0wLjE1Nyw1LjY4OSwwLjM1OSw5LjAxOWMtMTMuNTcyLDE1LjE2Ny05LjU4NCwxNy44My0zNi43MjMsMjMuNDE2Yy0yNy40NTcsNS42NTktMTEuMzI2LDE1LjczNC0wLjc5NywxOC4zNjdjMTIuNzY4LDMuMTkzLDQyLjMwNSw3LjcxNiw2Mi4yNjgtMjAuMjI0IGwtMC43OTUsMy4xODhjNS4zMjUsNC4yNiw0Ljk2NSwzMC42MTksNS43Miw0OS40NTJjMC43NTYsMTguODM0LDIuMDE3LDM2LjQwOSw1Ljg1Niw0Ni43NzFjMy44MzksMTAuMzYsOC4zNjksMzcuMDUsNDQuMDM2LDI5LjQwNmMyOS44MDktNi4zODgsNTIuNi0xNS41ODIsNTQuNjc3LTEwMS4xMDciIHN0eWxlPSJmaWxsOiMwMDAwMDA7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjM3LjM5NTM7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTQwMi4zOTUsMjcxLjIzYy01MC4zMDIsMTAuMzc2LTUzLjc2LTYuNjU1LTUzLjc2LTYuNjU1YzUzLjExMS03OC44MDgsNzUuMzEzLTE3OC44NDMsNTYuMTUzLTIwMy4zMjZjLTUyLjI3LTY2Ljc4NS0xNDIuNzUyLTM1LjItMTQ0LjI2Mi0zNC4zOGwtMC40ODYsMC4wODdjLTkuOTM4LTIuMDYzLTIxLjA2LTMuMjkyLTMzLjU2LTMuNDk2Yy0yMi43NjEtMC4zNzMtNDAuMDI2LDUuOTY3LTUzLjEyNywxNS45MDIgYzAsMC0xNjEuNDExLTY2LjQ5NS0xNTMuOTA0LDgzLjYzYzEuNTk3LDMxLjkzOCw0NS43NzYsMjQxLjY1Nyw5OC40NzEsMTc4LjMxMmMxOS4yNi0yMy4xNjMsMzcuODY5LTQyLjc0OCwzNy44NjktNDIuNzQ4YzkuMjQzLDYuMTQsMjAuMzA4LDkuMjcyLDMxLjkwOCw4LjE0N2wwLjkwMS0wLjc2NWMtMC4yOCwyLjg3Ni0wLjE1Miw1LjY4OSwwLjM2MSw5LjAxOWMtMTMuNTc1LDE1LjE2Ny05LjU4NiwxNy44My0zNi43MjMsMjMuNDE2IGMtMjcuNDU5LDUuNjU5LTExLjMyOCwxNS43MzQtMC43OTYsMTguMzY3YzEyLjc2OCwzLjE5Myw0Mi4zMDcsNy43MTYsNjIuMjY2LTIwLjIyNGwtMC43OTYsMy4xODhjNS4zMTksNC4yNiw5LjA1NCwyNy43MTEsOC40MjgsNDguOTY5Yy0wLjYyNiwyMS4yNTktMS4wNDQsMzUuODU0LDMuMTQ3LDQ3LjI1NGM0LjE5MSwxMS40LDguMzY4LDM3LjA1LDQ0LjA0MiwyOS40MDZjMjkuODA5LTYuMzg4LDQ1LjI1Ni0yMi45NDIsNDcuNDA1LTUwLjU1NSBjMS41MjUtMTkuNjMxLDQuOTc2LTE2LjcyOSw1LjE5NC0zNC4yOGwyLjc2OC04LjMwOWMzLjE5Mi0yNi42MTEsMC41MDctMzUuMTk2LDE4Ljg3Mi0zMS4yMDNsNC40NjMsMC4zOTJjMTMuNTE3LDAuNjE1LDMxLjIwOC0yLjE3NCw0MS41OTEtN2MyMi4zNTgtMTAuMzc2LDM1LjYxOC0yNy43LDEzLjU3My0yMy4xNDh6IiBzdHlsZT0iZmlsbDojMzM2NzkxO3N0cm9rZTpub25lIi8+IDxwYXRoIGQ9Ik0yMTUuODY2LDI4Ni40ODRjLTEuMzg1LDQ5LjUxNiwwLjM0OCw5OS4zNzcsNS4xOTMsMTExLjQ5NWM0Ljg0OCwxMi4xMTgsMTUuMjIzLDM1LjY4OCw1MC45LDI4LjA0NWMyOS44MDYtNi4zOSw0MC42NTEtMTguNzU2LDQ1LjM1Ny00Ni4wNTFjMy40NjYtMjAuMDgyLDEwLjE0OC03NS44NTQsMTEuMDA1LTg3LjI4MSIvPiA8cGF0aCBkPSJNMTczLjEwNCwzOC4yNTZjMCwwLTE2MS41MjEtNjYuMDE2LTE1NC4wMTIsODQuMTA5YzEuNTk3LDMxLjkzOCw0NS43NzksMjQxLjY2NCw5OC40NzMsMTc4LjMxNmMxOS4yNTYtMjMuMTY2LDM2LjY3MS00MS4zMzUsMzYuNjcxLTQxLjMzNSIvPiA8cGF0aCBkPSJNMjYwLjM0OSwyNi4yMDdjLTUuNTkxLDEuNzUzLDg5Ljg0OC0zNC44ODksMTQ0LjA4NywzNC40MTdjMTkuMTU5LDI0LjQ4NC0zLjA0MywxMjQuNTE5LTU2LjE1MywyMDMuMzI5Ii8+IDxwYXRoIGQ9Ik0zNDguMjgyLDI2My45NTNjMCwwLDMuNDYxLDE3LjAzNiw1My43NjQsNi42NTNjMjIuMDQtNC41NTIsOC43NzYsMTIuNzc0LTEzLjU3NywyMy4xNTVjLTE4LjM0NSw4LjUxNC01OS40NzQsMTAuNjk2LTYwLjE0Ni0xLjA2OWMtMS43MjktMzAuMzU1LDIxLjY0Ny0yMS4xMzMsMTkuOTYtMjguNzM5Yy0xLjUyNS02Ljg1LTExLjk3OS0xMy41NzMtMTguODk0LTMwLjMzOCBjLTYuMDM3LTE0LjYzMy04Mi43OTYtMTI2Ljg0OSwyMS4yODctMTEwLjE4M2MzLjgxMy0wLjc4OS0yNy4xNDYtOTkuMDAyLTEyNC41NTMtMTAwLjU5OWMtOTcuMzg1LTEuNTk3LTk0LjE5LDExOS43NjItOTQuMTksMTE5Ljc2MiIgc3R5bGU9InN0cm9rZS1saW5lam9pbjpiZXZlbCIvPiA8cGF0aCBkPSJNMTg4LjYwNCwyNzQuMzM0Yy0xMy41NzcsMTUuMTY2LTkuNTg0LDE3LjgyOS0zNi43MjMsMjMuNDE3Yy0yNy40NTksNS42Ni0xMS4zMjYsMTUuNzMzLTAuNzk3LDE4LjM2NWMxMi43NjgsMy4xOTUsNDIuMzA3LDcuNzE4LDYyLjI2Ni0yMC4yMjljNi4wNzgtOC41MDktMC4wMzYtMjIuMDg2LTguMzg1LTI1LjU0N2MtNC4wMzQtMS42NzEtOS40MjgtMy43NjUtMTYuMzYxLDMuOTk0eiIvPiA8cGF0aCBkPSJNMTg3LjcxNSwyNzQuMDY5Yy0xLjM2OC04LjkxNywyLjkzLTE5LjUyOCw3LjUzNi0zMS45NDJjNi45MjItMTguNjI2LDIyLjg5My0zNy4yNTUsMTAuMTE3LTk2LjMzOWMtOS41MjMtNDQuMDI5LTczLjM5Ni05LjE2My03My40MzYtMy4xOTNjLTAuMDM5LDUuOTY4LDIuODg5LDMwLjI2LTEuMDY3LDU4LjU0OGMtNS4xNjIsMzYuOTEzLDIzLjQ4OCw2OC4xMzIsNTYuNDc5LDY0LjkzOCIvPiA8cGF0aCBkPSJNMTcyLjUxNywxNDEuN2MtMC4yODgsMi4wMzksMy43MzMsNy40OCw4Ljk3Niw4LjIwN2M1LjIzNCwwLjczLDkuNzE0LTMuNTIyLDkuOTk4LTUuNTU5YzAuMjg0LTIuMDM5LTMuNzMyLTQuMjg1LTguOTc3LTUuMDE1Yy01LjIzNy0wLjczMS05LjcxOSwwLjMzMy05Ljk5NiwyLjM2N3oiIHN0eWxlPSJmaWxsOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjQuMTU1O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyIi8+IDxwYXRoIGQ9Ik0zMzEuOTQxLDEzNy41NDNjMC4yODQsMi4wMzktMy43MzIsNy40OC04Ljk3Niw4LjIwN2MtNS4yMzgsMC43My05LjcxOC0zLjUyMi0xMC4wMDUtNS41NTljLTAuMjc3LTIuMDM5LDMuNzQtNC4yODUsOC45NzktNS4wMTVjNS4yMzktMC43Myw5LjcxOCwwLjMzMywxMC4wMDIsMi4zNjh6IiBzdHlsZT0iZmlsbDojRkZGRkZGO3N0cm9rZS13aWR0aDoyLjA3NzU7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTM1MC42NzYsMTIzLjQzMmMwLjg2MywxNS45OTQtMy40NDUsMjYuODg4LTMuOTg4LDQzLjkxNGMtMC44MDQsMjQuNzQ4LDExLjc5OSw1My4wNzQtNy4xOTEsODEuNDM1Ii8+IDxwYXRoIGQ9Ik0wLDYwLjIzMiIgc3R5bGU9InN0cm9rZS13aWR0aDozIi8+IDwvZz48L3N2Zz4KPHRleHQgeD0iNzEyIiB5PSIxMDMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTJweCI+U2NhbGV3YXkgTWFuYWdlZCBEQjwvdGV4dD4KPHRleHQgeD0iNzEyIiB5PSIxMjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5Qb3N0Z3JlU1FMIGVuZ2luZTwvdGV4dD4KPHRleHQgeD0iMjAwIiB5PSIxNTgiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4Ij5BVCBERVBMT1lNRU5UIMK3IFZJQSBURU5TT1I5PC90ZXh0Pgo8cmVjdCB4PSIyNiIgeT0iMTY0IiB3aWR0aD0iMTI4IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojY2JkNWUxIi8+Cjx0ZXh0IHg9IjkwIiB5PSIxODYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMGYxNzJhOyBmb250LXNpemU6MTJweCI+WW91ciBzdGFjazwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjIwMyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGIiPlJEUyBQb3N0Z3JlU1FMPC90ZXh0Pgo8dGV4dCB4PSI5MCIgeT0iMjE4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YiI+ZGF0YWJhc2UgaW5zdGFuY2U8L3RleHQ+CjxsaW5lIHgxPSIxNTQiIHkxPSIxOTYiIHgyPSIzMDAiIHkyPSIxOTYiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtZGVwbG95LXNjYWxld2F5LW1hbmFnZWQtZGIpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iMjI3IiB5PSIxODgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiIj5kZWNsYXJhdGlvbjwvdGV4dD4KPHJlY3QgeD0iMzA0IiB5PSIxNjQiIHdpZHRoPSIxODAiIGhlaWdodD0iNjYiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiNlY2ZkZjU7c3Ryb2tlOiMwNDc4NTciLz4KPHRleHQgeD0iMzk0IiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjMDQ3ODU3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSIzOTQiIHk9IjIwOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzA0Nzg1NyI+Y29tcGlsZXMgb25jZTwvdGV4dD4KPHBhdGggZD0iTTQ4NCwxOTYgTDcxMiwxOTYgTDcxMiwxNDYiIGZpbGw9Im5vbmUiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtZGVwbG95LXNjYWxld2F5LW1hbmFnZWQtZGIpIiBzdHlsZT0ic3Ryb2tlOiM5NGEzYjgiLz4KPHRleHQgeD0iNTk4IiB5PSIxODgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiIj5wcm92aXNpb25zIHRoZSBpbnN0YW5jZTwvdGV4dD4KPHRleHQgeD0iNTk4IiB5PSIyMjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiIj5ubyBSRFMgbWFuYWdlbWVudCBBUEkgYXQgcnVudGltZTwvdGV4dD4KPC9zdmc+) ![Database requests (SQL over pgwire) connect directly to Scaleway Managed DB. Tensor9 compiles the RDS PostgreSQL database instance into Scaleway Managed DB at deployment; there is no management API at runtime.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMjUyIiB2aWV3Qm94PSIwIDAgODM2IDI1MiIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJEYXRhYmFzZSByZXF1ZXN0cyAoU1FMIG92ZXIgcGd3aXJlKSBjb25uZWN0IGRpcmVjdGx5IHRvIFNjYWxld2F5IE1hbmFnZWQgREIuIFRlbnNvcjkgY29tcGlsZXMgdGhlIFJEUyBQb3N0Z3JlU1FMIGRhdGFiYXNlIGluc3RhbmNlIGludG8gU2NhbGV3YXkgTWFuYWdlZCBEQiBhdCBkZXBsb3ltZW50OyB0aGVyZSBpcyBubyBtYW5hZ2VtZW50IEFQSSBhdCBydW50aW1lLiI+PHN0eWxlPnRleHR7Zm9udC1mYW1pbHk6SW50ZXIsLWFwcGxlLXN5c3RlbSxCbGlua01hY1N5c3RlbUZvbnQsJ1NlZ29lIFVJJyxSb2JvdG8sJ0hlbHZldGljYSBOZXVlJyxBcmlhbCxzYW5zLXNlcmlmO2ZpbGw6I2NiZDVlMX08L3N0eWxlPgo8ZGVmcz48bWFya2VyIGlkPSJhaGQtZGVwbG95LXNjYWxld2F5LW1hbmFnZWQtZGIiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOCIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjciIG1hcmtlckhlaWdodD0iNyIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPjxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgc3R5bGU9ImZpbGw6IzY0NzQ4YiIvPjwvbWFya2VyPjwvZGVmcz4KPHJlY3QgeD0iOCIgeT0iMzQiIHdpZHRoPSI4MjAiIGhlaWdodD0iMjA2IiByeD0iMTYiIHN0cm9rZS13aWR0aD0iMS40IiBzdHJva2UtZGFzaGFycmF5PSI1IDUiIHN0eWxlPSJmaWxsOiMwZjE3MmE7c3Ryb2tlOiM0NzU1NjkiLz4KPHRleHQgeD0iMjYiIHk9IjU0IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzY0NzQ4YjsgZmlsbDojNmVlN2I3Ij5PTiBTQ0FMRVdBWTwvdGV4dD4KPHN2ZyB4PSI3OTIiIHk9IjM2IiB3aWR0aD0iMTYiIGhlaWdodD0iMTYiIHZpZXdCb3g9IjAgMCAxNiAxNiIgcHJlc2VydmVBc3BlY3RSYXRpbz0ieE1pZFlNaWQgbWVldCIgZmlsbD0ibm9uZSI+PHBhdGggZD0iTTguMzcgMy42NjZINS43MzZBMS4xODIgMS4xODIgMCAwIDAgNC42OSA0Ljc5djMuODFjMCAuMjU3LjEuNDguMjY3LjY0Ny4xNjYuMTY3LjM4OS4yNjcuNjQ0LjI2Ny41IDAgLjkxMi0uNDEyLjkxMi0uOTEzVjYuMTg0YzAtLjM3OS4zMTEtLjY5MS42OS0uNjkxaDEuMTg5Yy4yNTUgMCAuNDc4LS4xLjY0NC0uMjY3YS45MjcuOTI3IDAgMCAwIC4yNjctLjY1OGMwLS41MDEtLjQzMy0uOTAyLS45MzQtLjkwMlpNNy4xODEgMTIuMzU3aDIuNjM1YTEuMTgxIDEuMTgxIDAgMCAwIDEuMDQ1LTEuMTI2di0zLjgxYS45LjkgMCAwIDAtLjI2Ny0uNjQ3Ljg5Ny44OTcgMCAwIDAtLjY0NS0uMjY3Yy0uNSAwLS45MTIuNDEyLS45MTIuOTE0djIuNDE3YzAgLjM4LS4zMS42OTEtLjY4OS42OTFoLTEuMTljLS4yNTUgMC0uNDc3LjEtLjY0NC4yNjhhLjkyNy45MjcgMCAwIDAtLjI2Ny42NTcuOTM0LjkzNCAwIDAgMCAuOTM0LjkwMloiIGZpbGw9IiNCRjk1RjkiLz4gPHBhdGggZmlsbC1ydWxlPSJldmVub2RkIiBjbGlwLXJ1bGU9ImV2ZW5vZGQiIGQ9Ik00LjAyNCAwaDQuNzkxYTUuNjgzIDUuNjgzIDAgMCAxIDUuNjkyIDUuNzE2djcuNTg4QTMuMDI3IDMuMDI3IDAgMCAxIDExLjc1IDE2SDYuNzAzQzMuNTU3IDE2IDEgMTMuNDM3IDEgMTAuMjg0VjMuMDMxQTMuMDMgMy4wMyAwIDAgMSA0LjAyNCAwWm04LjY3IDUuNzE2YzAtMi4xNC0xLjc0NC0zLjg4OS0zLjg3OS0zLjg4OWgtNC43OGMtLjY2NyAwLTEuMi41MzUtMS4yIDEuMjA0djcuMjUzYTMuODggMy44OCAwIDAgMCAzLjg4IDMuODg5aDQuOTU3YTEuMTkzIDEuMTkzIDAgMCAwIDEuMDIzLS45OFY1LjcxNVoiIGZpbGw9IiNCRjk1RjkiLz48L3N2Zz4KPHJlY3QgeD0iMjYiIHk9Ijc2IiB3aWR0aD0iMTI4IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjkwIiB5PSIxMDAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTNweCI+WW91ciBhcHA8L3RleHQ+Cjx0ZXh0IHg9IjkwIiB5PSIxMTciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5Qb3N0Z3JlU1FMIGRyaXZlcjwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjEzMiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDYwMCAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3Ij51bmNoYW5nZWQ8L3RleHQ+Cjx0ZXh0IHg9IjIwMCIgeT0iODIiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiM2ZWU3YjciPkRBVEFCQVNFIFJFUVVFU1RTIMK3IERJUkVDVCBDT05ORUNUSU9OPC90ZXh0Pgo8bGluZSB4MT0iMTU0IiB5MT0iMTA4IiB4Mj0iNjEwIiB5Mj0iMTA4IiBzdHJva2Utd2lkdGg9IjIuMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtZGVwbG95LXNjYWxld2F5LW1hbmFnZWQtZGIpIiBzdHlsZT0ic3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iMzgyIiB5PSIxMDAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiM2ZWU3YjciPlNRTCBvdmVyIHBnd2lyZTwvdGV4dD4KPHJlY3QgeD0iNjE0IiB5PSI3NiIgd2lkdGg9IjE5NiIgaGVpZ2h0PSI2NCIgcng9IjEyIiBzdHJva2Utd2lkdGg9IjEuNSIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6IzQ3NTU2OSIvPgo8c3ZnIHg9Ijc4NiIgeT0iNTYiIHdpZHRoPSIyMCIgaGVpZ2h0PSIyMCIgdmlld0JveD0iMCAwIDQzMi4wNzEgNDQ1LjM4MyIgcHJlc2VydmVBc3BlY3RSYXRpbz0ieE1pZFlNaWQgbWVldCI+PGcgc3R5bGU9ImZpbGwtcnVsZTpub256ZXJvO2NsaXAtcnVsZTpub256ZXJvO3N0cm9rZTojMDAwMDAwO3N0cm9rZS1taXRlcmxpbWl0OjQiPiA8L2c+IDxnIHN0eWxlPSJmaWxsLXJ1bGU6bm9uemVybztjbGlwLXJ1bGU6bm9uemVybztmaWxsOm5vbmU7c3Ryb2tlOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjEyLjQ2NTE7c3Ryb2tlLWxpbmVjYXA6cm91bmQ7c3Ryb2tlLWxpbmVqb2luOnJvdW5kO3N0cm9rZS1taXRlcmxpbWl0OjQiPiA8cGF0aCBkPSJNMzIzLjIwNSwzMjQuMjI3YzIuODMzLTIzLjYwMSwxLjk4NC0yNy4wNjIsMTkuNTYzLTIzLjIzOWw0LjQ2MywwLjM5MmMxMy41MTcsMC42MTUsMzEuMTk5LTIuMTc0LDQxLjU4Ny03YzIyLjM2Mi0xMC4zNzYsMzUuNjIyLTI3LjcsMTMuNTcyLTIzLjE0OGMtNTAuMjk3LDEwLjM3Ni01My43NTUtNi42NTUtNTMuNzU1LTYuNjU1YzUzLjExMS03OC44MDMsNzUuMzEzLTE3OC44MzYsNTYuMTQ5LTIwMy4zMjIgQzM1Mi41MTQtNS41MzQsMjYyLjAzNiwyNi4wNDksMjYwLjUyMiwyNi44NjlsLTAuNDgyLDAuMDg5Yy05LjkzOC0yLjA2Mi0yMS4wNi0zLjI5NC0zMy41NTQtMy40OTZjLTIyLjc2MS0wLjM3NC00MC4wMzIsNS45NjctNTMuMTMzLDE1LjkwNGMwLDAtMTYxLjQwOC02Ni40OTgtMTUzLjg5OSw4My42MjhjMS41OTcsMzEuOTM2LDQ1Ljc3NywyNDEuNjU1LDk4LjQ3LDE3OC4zMSBjMTkuMjU5LTIzLjE2MywzNy44NzEtNDIuNzQ4LDM3Ljg3MS00Mi43NDhjOS4yNDIsNi4xNCwyMC4zMDcsOS4yNzIsMzEuOTEyLDguMTQ3bDAuODk3LTAuNzY1Yy0wLjI4MSwyLjg3Ni0wLjE1Nyw1LjY4OSwwLjM1OSw5LjAxOWMtMTMuNTcyLDE1LjE2Ny05LjU4NCwxNy44My0zNi43MjMsMjMuNDE2Yy0yNy40NTcsNS42NTktMTEuMzI2LDE1LjczNC0wLjc5NywxOC4zNjdjMTIuNzY4LDMuMTkzLDQyLjMwNSw3LjcxNiw2Mi4yNjgtMjAuMjI0IGwtMC43OTUsMy4xODhjNS4zMjUsNC4yNiw0Ljk2NSwzMC42MTksNS43Miw0OS40NTJjMC43NTYsMTguODM0LDIuMDE3LDM2LjQwOSw1Ljg1Niw0Ni43NzFjMy44MzksMTAuMzYsOC4zNjksMzcuMDUsNDQuMDM2LDI5LjQwNmMyOS44MDktNi4zODgsNTIuNi0xNS41ODIsNTQuNjc3LTEwMS4xMDciIHN0eWxlPSJmaWxsOiMwMDAwMDA7c3Ryb2tlOiMwMDAwMDA7c3Ryb2tlLXdpZHRoOjM3LjM5NTM7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTQwMi4zOTUsMjcxLjIzYy01MC4zMDIsMTAuMzc2LTUzLjc2LTYuNjU1LTUzLjc2LTYuNjU1YzUzLjExMS03OC44MDgsNzUuMzEzLTE3OC44NDMsNTYuMTUzLTIwMy4zMjZjLTUyLjI3LTY2Ljc4NS0xNDIuNzUyLTM1LjItMTQ0LjI2Mi0zNC4zOGwtMC40ODYsMC4wODdjLTkuOTM4LTIuMDYzLTIxLjA2LTMuMjkyLTMzLjU2LTMuNDk2Yy0yMi43NjEtMC4zNzMtNDAuMDI2LDUuOTY3LTUzLjEyNywxNS45MDIgYzAsMC0xNjEuNDExLTY2LjQ5NS0xNTMuOTA0LDgzLjYzYzEuNTk3LDMxLjkzOCw0NS43NzYsMjQxLjY1Nyw5OC40NzEsMTc4LjMxMmMxOS4yNi0yMy4xNjMsMzcuODY5LTQyLjc0OCwzNy44NjktNDIuNzQ4YzkuMjQzLDYuMTQsMjAuMzA4LDkuMjcyLDMxLjkwOCw4LjE0N2wwLjkwMS0wLjc2NWMtMC4yOCwyLjg3Ni0wLjE1Miw1LjY4OSwwLjM2MSw5LjAxOWMtMTMuNTc1LDE1LjE2Ny05LjU4NiwxNy44My0zNi43MjMsMjMuNDE2IGMtMjcuNDU5LDUuNjU5LTExLjMyOCwxNS43MzQtMC43OTYsMTguMzY3YzEyLjc2OCwzLjE5Myw0Mi4zMDcsNy43MTYsNjIuMjY2LTIwLjIyNGwtMC43OTYsMy4xODhjNS4zMTksNC4yNiw5LjA1NCwyNy43MTEsOC40MjgsNDguOTY5Yy0wLjYyNiwyMS4yNTktMS4wNDQsMzUuODU0LDMuMTQ3LDQ3LjI1NGM0LjE5MSwxMS40LDguMzY4LDM3LjA1LDQ0LjA0MiwyOS40MDZjMjkuODA5LTYuMzg4LDQ1LjI1Ni0yMi45NDIsNDcuNDA1LTUwLjU1NSBjMS41MjUtMTkuNjMxLDQuOTc2LTE2LjcyOSw1LjE5NC0zNC4yOGwyLjc2OC04LjMwOWMzLjE5Mi0yNi42MTEsMC41MDctMzUuMTk2LDE4Ljg3Mi0zMS4yMDNsNC40NjMsMC4zOTJjMTMuNTE3LDAuNjE1LDMxLjIwOC0yLjE3NCw0MS41OTEtN2MyMi4zNTgtMTAuMzc2LDM1LjYxOC0yNy43LDEzLjU3My0yMy4xNDh6IiBzdHlsZT0iZmlsbDojMzM2NzkxO3N0cm9rZTpub25lIi8+IDxwYXRoIGQ9Ik0yMTUuODY2LDI4Ni40ODRjLTEuMzg1LDQ5LjUxNiwwLjM0OCw5OS4zNzcsNS4xOTMsMTExLjQ5NWM0Ljg0OCwxMi4xMTgsMTUuMjIzLDM1LjY4OCw1MC45LDI4LjA0NWMyOS44MDYtNi4zOSw0MC42NTEtMTguNzU2LDQ1LjM1Ny00Ni4wNTFjMy40NjYtMjAuMDgyLDEwLjE0OC03NS44NTQsMTEuMDA1LTg3LjI4MSIvPiA8cGF0aCBkPSJNMTczLjEwNCwzOC4yNTZjMCwwLTE2MS41MjEtNjYuMDE2LTE1NC4wMTIsODQuMTA5YzEuNTk3LDMxLjkzOCw0NS43NzksMjQxLjY2NCw5OC40NzMsMTc4LjMxNmMxOS4yNTYtMjMuMTY2LDM2LjY3MS00MS4zMzUsMzYuNjcxLTQxLjMzNSIvPiA8cGF0aCBkPSJNMjYwLjM0OSwyNi4yMDdjLTUuNTkxLDEuNzUzLDg5Ljg0OC0zNC44ODksMTQ0LjA4NywzNC40MTdjMTkuMTU5LDI0LjQ4NC0zLjA0MywxMjQuNTE5LTU2LjE1MywyMDMuMzI5Ii8+IDxwYXRoIGQ9Ik0zNDguMjgyLDI2My45NTNjMCwwLDMuNDYxLDE3LjAzNiw1My43NjQsNi42NTNjMjIuMDQtNC41NTIsOC43NzYsMTIuNzc0LTEzLjU3NywyMy4xNTVjLTE4LjM0NSw4LjUxNC01OS40NzQsMTAuNjk2LTYwLjE0Ni0xLjA2OWMtMS43MjktMzAuMzU1LDIxLjY0Ny0yMS4xMzMsMTkuOTYtMjguNzM5Yy0xLjUyNS02Ljg1LTExLjk3OS0xMy41NzMtMTguODk0LTMwLjMzOCBjLTYuMDM3LTE0LjYzMy04Mi43OTYtMTI2Ljg0OSwyMS4yODctMTEwLjE4M2MzLjgxMy0wLjc4OS0yNy4xNDYtOTkuMDAyLTEyNC41NTMtMTAwLjU5OWMtOTcuMzg1LTEuNTk3LTk0LjE5LDExOS43NjItOTQuMTksMTE5Ljc2MiIgc3R5bGU9InN0cm9rZS1saW5lam9pbjpiZXZlbCIvPiA8cGF0aCBkPSJNMTg4LjYwNCwyNzQuMzM0Yy0xMy41NzcsMTUuMTY2LTkuNTg0LDE3LjgyOS0zNi43MjMsMjMuNDE3Yy0yNy40NTksNS42Ni0xMS4zMjYsMTUuNzMzLTAuNzk3LDE4LjM2NWMxMi43NjgsMy4xOTUsNDIuMzA3LDcuNzE4LDYyLjI2Ni0yMC4yMjljNi4wNzgtOC41MDktMC4wMzYtMjIuMDg2LTguMzg1LTI1LjU0N2MtNC4wMzQtMS42NzEtOS40MjgtMy43NjUtMTYuMzYxLDMuOTk0eiIvPiA8cGF0aCBkPSJNMTg3LjcxNSwyNzQuMDY5Yy0xLjM2OC04LjkxNywyLjkzLTE5LjUyOCw3LjUzNi0zMS45NDJjNi45MjItMTguNjI2LDIyLjg5My0zNy4yNTUsMTAuMTE3LTk2LjMzOWMtOS41MjMtNDQuMDI5LTczLjM5Ni05LjE2My03My40MzYtMy4xOTNjLTAuMDM5LDUuOTY4LDIuODg5LDMwLjI2LTEuMDY3LDU4LjU0OGMtNS4xNjIsMzYuOTEzLDIzLjQ4OCw2OC4xMzIsNTYuNDc5LDY0LjkzOCIvPiA8cGF0aCBkPSJNMTcyLjUxNywxNDEuN2MtMC4yODgsMi4wMzksMy43MzMsNy40OCw4Ljk3Niw4LjIwN2M1LjIzNCwwLjczLDkuNzE0LTMuNTIyLDkuOTk4LTUuNTU5YzAuMjg0LTIuMDM5LTMuNzMyLTQuMjg1LTguOTc3LTUuMDE1Yy01LjIzNy0wLjczMS05LjcxOSwwLjMzMy05Ljk5NiwyLjM2N3oiIHN0eWxlPSJmaWxsOiNGRkZGRkY7c3Ryb2tlLXdpZHRoOjQuMTU1O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyIi8+IDxwYXRoIGQ9Ik0zMzEuOTQxLDEzNy41NDNjMC4yODQsMi4wMzktMy43MzIsNy40OC04Ljk3Niw4LjIwN2MtNS4yMzgsMC43My05LjcxOC0zLjUyMi0xMC4wMDUtNS41NTljLTAuMjc3LTIuMDM5LDMuNzQtNC4yODUsOC45NzktNS4wMTVjNS4yMzktMC43Myw5LjcxOCwwLjMzMywxMC4wMDIsMi4zNjh6IiBzdHlsZT0iZmlsbDojRkZGRkZGO3N0cm9rZS13aWR0aDoyLjA3NzU7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXIiLz4gPHBhdGggZD0iTTM1MC42NzYsMTIzLjQzMmMwLjg2MywxNS45OTQtMy40NDUsMjYuODg4LTMuOTg4LDQzLjkxNGMtMC44MDQsMjQuNzQ4LDExLjc5OSw1My4wNzQtNy4xOTEsODEuNDM1Ii8+IDxwYXRoIGQ9Ik0wLDYwLjIzMiIgc3R5bGU9InN0cm9rZS13aWR0aDozIi8+IDwvZz48L3N2Zz4KPHRleHQgeD0iNzEyIiB5PSIxMDMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTJweCI+U2NhbGV3YXkgTWFuYWdlZCBEQjwvdGV4dD4KPHRleHQgeD0iNzEyIiB5PSIxMjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5Qb3N0Z3JlU1FMIGVuZ2luZTwvdGV4dD4KPHRleHQgeD0iMjAwIiB5PSIxNTgiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiIj5BVCBERVBMT1lNRU5UIMK3IFZJQSBURU5TT1I5PC90ZXh0Pgo8cmVjdCB4PSIyNiIgeT0iMTY0IiB3aWR0aD0iMTI4IiBoZWlnaHQ9IjY0IiByeD0iMTIiIHN0cm9rZS13aWR0aD0iMS41IiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNDc1NTY5Ii8+Cjx0ZXh0IHg9IjkwIiB5PSIxODYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA2NTAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjZjFmNWY5OyBmb250LXNpemU6MTJweCI+WW91ciBzdGFjazwvdGV4dD4KPHRleHQgeD0iOTAiIHk9IjIwMyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjgiPlJEUyBQb3N0Z3JlU1FMPC90ZXh0Pgo8dGV4dCB4PSI5MCIgeT0iMjE4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiOCI+ZGF0YWJhc2UgaW5zdGFuY2U8L3RleHQ+CjxsaW5lIHgxPSIxNTQiIHkxPSIxOTYiIHgyPSIzMDAiIHkyPSIxOTYiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtZGVwbG95LXNjYWxld2F5LW1hbmFnZWQtZGIpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iMjI3IiB5PSIxODgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4Ij5kZWNsYXJhdGlvbjwvdGV4dD4KPHJlY3QgeD0iMzA0IiB5PSIxNjQiIHdpZHRoPSIxODAiIGhlaWdodD0iNjYiIHJ4PSIxMiIgc3Ryb2tlLXdpZHRoPSIxLjciIHN0eWxlPSJmaWxsOiMwNjRlM2I7c3Ryb2tlOiM2ZWU3YjciLz4KPHRleHQgeD0iMzk0IiB5PSIxOTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiA3MDAgMTMuNXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNmVlN2I3OyBmb250LXNpemU6MTJweCI+VGVuc29yOTwvdGV4dD4KICA8dGV4dCB4PSIzOTQiIHk9IjIwOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwLjVweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzZlZTdiNyI+Y29tcGlsZXMgb25jZTwvdGV4dD4KPHBhdGggZD0iTTQ4NCwxOTYgTDcxMiwxOTYgTDcxMiwxNDYiIGZpbGw9Im5vbmUiIHN0cm9rZS13aWR0aD0iMiIgbWFya2VyLWVuZD0idXJsKCNhaGQtZGVwbG95LXNjYWxld2F5LW1hbmFnZWQtZGIpIiBzdHlsZT0ic3Ryb2tlOiM2NDc0OGIiLz4KPHRleHQgeD0iNTk4IiB5PSIxODgiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4Ij5wcm92aXNpb25zIHRoZSBpbnN0YW5jZTwvdGV4dD4KPHRleHQgeD0iNTk4IiB5PSIyMjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4Ij5ubyBSRFMgbWFuYWdlbWVudCBBUEkgYXQgcnVudGltZTwvdGV4dD4KPC9zdmc+) 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 database instance your stack declares and writes the matching Scaleway resources once, when the product is deployed. Settings with a direct equivalent are kept. Settings that Scaleway handles differently are translated and called out. Settings with no equivalent are removed, and the deployment reports each one instead of dropping it silently. After deployment there is no RDS management API on this backend. Day-to-day operations, such as resizing the node or volume, adding read replicas, changing backup frequency and retention, restoring a backup and editing engine settings, use Scaleway's console, CLI or API against the customer's own Scaleway project. ![What each YOUR RDS POSTGRESQL DECLARATION setting becomes on ON SCALEWAY when Tensor9 deploys the product.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMzQwIiB2aWV3Qm94PSIwIDAgODM2IDM0MCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJXaGF0IGVhY2ggWU9VUiBSRFMgUE9TVEdSRVNRTCBERUNMQVJBVElPTiBzZXR0aW5nIGJlY29tZXMgb24gT04gU0NBTEVXQVkgd2hlbiBUZW5zb3I5IGRlcGxveXMgdGhlIHByb2R1Y3QuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojMzM0MTU1fTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImFodC15b3VyLXJkcy1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5IiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI2IiBtYXJrZXJIZWlnaHQ9IjYiIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM5NGEzYjgiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjE2IiB5PSIyMCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzMTIiIHJ4PSIxMiIgZmlsbD0ibm9uZSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJzdHJva2U6I2NiZDVlMSIvPgo8dGV4dCB4PSIzMiIgeT0iNDQiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjOTRhM2I4Ij5ZT1VSIFJEUyBQT1NUR1JFU1FMIERFQ0xBUkFUSU9OPC90ZXh0Pgo8dGV4dCB4PSIzODQiIHk9IjQ0IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzk0YTNiODsgZmlsbDojMDQ3ODU3Ij5PTiBTQ0FMRVdBWTwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjU4IiB3aWR0aD0iODA0IiBoZWlnaHQ9IjMwIiBzdHlsZT0iZmlsbDojZmZmZmZmIi8+Cjx0ZXh0IHg9IjMyIiB5PSI3NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+SW5zdGFuY2UgY2xhc3M8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSI3MyIgeDI9IjM2OCIgeTI9IjczIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtcG9zdGdyZXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8dGV4dCB4PSIzODQiIHk9Ijc3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjEycHg7ZmlsbDojMGYxNzJhIj5HZW5lcmFsLXB1cnBvc2Ugbm9kZSwgMi04IHZDUFU8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iNjQiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTgiIHJ4PSI5IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2I0NTMwOSIvPgo8dGV4dCB4PSI3NTQiIHk9Ijc3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YjsgZmlsbDojYjQ1MzA5Ij5jaGFuZ2VkPC90ZXh0Pgo8cmVjdCB4PSIxNiIgeT0iODgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiNmOGZhZmMiLz4KPHRleHQgeD0iMzIiIHk9IjEwNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+TXVsdGktQVo8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIxMDMiIHgyPSIzNjgiIHkyPSIxMDMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLXJkcy1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjM4NCIgeT0iMTA3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjEycHg7ZmlsbDojMGYxNzJhIj5Ib3Qgc3RhbmRieSBpbiB0aGUgc2FtZSBkYXRhIGNlbnRlcjwvdGV4dD4KPHJlY3QgeD0iNzA0IiB5PSI5NCIgd2lkdGg9IjEwMCIgaGVpZ2h0PSIxOCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojYjQ1MzA5Ii8+Cjx0ZXh0IHg9Ijc1NCIgeT0iMTA3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YjsgZmlsbDojYjQ1MzA5Ij5jaGFuZ2VkPC90ZXh0Pgo8cmVjdCB4PSIxNiIgeT0iMTE4IiB3aWR0aD0iODA0IiBoZWlnaHQ9IjMwIiBzdHlsZT0iZmlsbDojZmZmZmZmIi8+Cjx0ZXh0IHg9IjMyIiB5PSIxMzciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiOyBmb250LXNpemU6MTJweDtmaWxsOiMwZjE3MmEiPkFsbG9jYXRlZCBzdG9yYWdlPC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMTMzIiB4Mj0iMzY4IiB5Mj0iMTMzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtcG9zdGdyZXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8dGV4dCB4PSIzODQiIHk9IjEzNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+QmxvY2sgc3RvcmFnZSB2b2x1bWUsIDUtMTAsMDAwIEdCPC90ZXh0Pgo8cmVjdCB4PSI3MDQiIHk9IjEyNCIgd2lkdGg9IjEwMCIgaGVpZ2h0PSIxOCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojMDQ3ODU3Ii8+Cjx0ZXh0IHg9Ijc1NCIgeT0iMTM3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YjsgZmlsbDojMDQ3ODU3Ij5tYXBwZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIxNDgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiNmOGZhZmMiLz4KPHRleHQgeD0iMzIiIHk9IjE2NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+UG9zdGdyZVNRTCBtYWpvciB2ZXJzaW9uPC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMTYzIiB4Mj0iMzY4IiB5Mj0iMTYzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtcG9zdGdyZXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8dGV4dCB4PSIzODQiIHk9IjE2NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+UG9zdGdyZVNRTCAxNC0xNyAob2xkZXIgbWFqb3JzIG1vdmUgdG8gMTcpPC90ZXh0Pgo8cmVjdCB4PSI3MDQiIHk9IjE1NCIgd2lkdGg9IjEwMCIgaGVpZ2h0PSIxOCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojZmZmZmZmO3N0cm9rZTojYjQ1MzA5Ii8+Cjx0ZXh0IHg9Ijc1NCIgeT0iMTY3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzY0NzQ4YjsgZmlsbDojYjQ1MzA5Ij5jaGFuZ2VkPC90ZXh0Pgo8cmVjdCB4PSIxNiIgeT0iMTc4IiB3aWR0aD0iODA0IiBoZWlnaHQ9IjMwIiBzdHlsZT0iZmlsbDojZmZmZmZmIi8+Cjx0ZXh0IHg9IjMyIiB5PSIxOTciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjNjQ3NDhiOyBmb250LXNpemU6MTJweDtmaWxsOiMwZjE3MmEiPk1hc3RlciB1c2VybmFtZSBhbmQgcGFzc3dvcmQ8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIxOTMiIHgyPSIzNjgiIHkyPSIxOTMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLXJkcy1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjM4NCIgeT0iMTk3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjEycHg7ZmlsbDojMGYxNzJhIj5Qcm92aXNpb25lZCBhZG1pbiB1c2VyLCBwYXNzd29yZCB2aWEgdmFyaWFibGU8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMTg0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNiNDUzMDkiLz4KPHRleHQgeD0iNzU0IiB5PSIxOTciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiNiNDUzMDkiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIyMDgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiNmOGZhZmMiLz4KPHRleHQgeD0iMzIiIHk9IjIyNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+SUFNIGRhdGFiYXNlIGF1dGhlbnRpY2F0aW9uPC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMjIzIiB4Mj0iMzY4IiB5Mj0iMjIzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtcG9zdGdyZXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8dGV4dCB4PSIzODQiIHk9IjIyNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+Tm8gZXF1aXZhbGVudDsgY2xpZW50cyBjYW5ub3QgY29ubmVjdDwvdGV4dD4KPHJlY3QgeD0iNzA0IiB5PSIyMTQiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTgiIHJ4PSI5IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6I2ZmZmZmZjtzdHJva2U6I2RjMjYyNiIvPgo8dGV4dCB4PSI3NTQiIHk9IjIyNyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM2NDc0OGI7IGZpbGw6I2RjMjYyNiI+b21pdHRlZDwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjIzOCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzMCIgc3R5bGU9ImZpbGw6I2ZmZmZmZiIvPgo8dGV4dCB4PSIzMiIgeT0iMjU3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjEycHg7ZmlsbDojMGYxNzJhIj5CYWNrdXAgcmV0ZW50aW9uIGFuZCB3aW5kb3c8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIyNTMiIHgyPSIzNjgiIHkyPSIyNTMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLXJkcy1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojOTRhM2I4Ii8+Cjx0ZXh0IHg9IjM4NCIgeT0iMjU3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzY0NzQ4YjsgZm9udC1zaXplOjEycHg7ZmlsbDojMGYxNzJhIj5TY2FsZXdheSdzIG93biBiYWNrdXAgc2NoZWR1bGU8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMjQ0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNiNDUzMDkiLz4KPHRleHQgeD0iNzU0IiB5PSIyNTciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiNiNDUzMDkiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIyNjgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiNmOGZhZmMiLz4KPHRleHQgeD0iMzIiIHk9IjI4NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+Q3VzdG9tZXItbWFuYWdlZCBLTVMga2V5PC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMjgzIiB4Mj0iMzY4IiB5Mj0iMjgzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtcG9zdGdyZXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8dGV4dCB4PSIzODQiIHk9IjI4NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+U2NhbGV3YXktbWFuYWdlZCBlbmNyeXB0aW9uIGF0IHJlc3Q8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMjc0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNiNDUzMDkiLz4KPHRleHQgeD0iNzU0IiB5PSIyODciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiNiNDUzMDkiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIyOTgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiNmZmZmZmYiLz4KPHRleHQgeD0iMzIiIHk9IjMxNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+UGFyYW1ldGVyIGFuZCBvcHRpb24gZ3JvdXBzPC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMzEzIiB4Mj0iMzY4IiB5Mj0iMzEzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtcG9zdGdyZXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6Izk0YTNiOCIvPgo8dGV4dCB4PSIzODQiIHk9IjMxNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM2NDc0OGI7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6IzBmMTcyYSI+UmVtb3ZlZDsgc2V0IGVuZ2luZSBzZXR0aW5ncyBvbiB0aGUgaW5zdGFuY2U8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMzA0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiNmZmZmZmY7c3Ryb2tlOiNkYzI2MjYiLz4KPHRleHQgeD0iNzU0IiB5PSIzMTciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjNjQ3NDhiOyBmaWxsOiNkYzI2MjYiPm9taXR0ZWQ8L3RleHQ+Cjwvc3ZnPg==) ![What each YOUR RDS POSTGRESQL DECLARATION setting becomes on ON SCALEWAY when Tensor9 deploys the product.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI4MzYiIGhlaWdodD0iMzQwIiB2aWV3Qm94PSIwIDAgODM2IDM0MCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsPSJXaGF0IGVhY2ggWU9VUiBSRFMgUE9TVEdSRVNRTCBERUNMQVJBVElPTiBzZXR0aW5nIGJlY29tZXMgb24gT04gU0NBTEVXQVkgd2hlbiBUZW5zb3I5IGRlcGxveXMgdGhlIHByb2R1Y3QuIj48c3R5bGU+dGV4dHtmb250LWZhbWlseTpJbnRlciwtYXBwbGUtc3lzdGVtLEJsaW5rTWFjU3lzdGVtRm9udCwnU2Vnb2UgVUknLFJvYm90bywnSGVsdmV0aWNhIE5ldWUnLEFyaWFsLHNhbnMtc2VyaWY7ZmlsbDojY2JkNWUxfTwvc3R5bGU+CjxkZWZzPjxtYXJrZXIgaWQ9ImFodC15b3VyLXJkcy1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5IiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjgiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI2IiBtYXJrZXJIZWlnaHQ9IjYiIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj48cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIHN0eWxlPSJmaWxsOiM2NDc0OGIiLz48L21hcmtlcj48L2RlZnM+CjxyZWN0IHg9IjE2IiB5PSIyMCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzMTIiIHJ4PSIxMiIgZmlsbD0ibm9uZSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0eWxlPSJzdHJva2U6IzQ3NTU2OSIvPgo8dGV4dCB4PSIzMiIgeT0iNDQiIHN0eWxlPSJmb250OiA3MDAgMTBweCBJbnRlciwgc2Fucy1zZXJpZjsgbGV0dGVyLXNwYWNpbmc6IDEuM3B4OyBmaWxsOiAjNjQ3NDhiIj5ZT1VSIFJEUyBQT1NUR1JFU1FMIERFQ0xBUkFUSU9OPC90ZXh0Pgo8dGV4dCB4PSIzODQiIHk9IjQ0IiBzdHlsZT0iZm9udDogNzAwIDEwcHggSW50ZXIsIHNhbnMtc2VyaWY7IGxldHRlci1zcGFjaW5nOiAxLjNweDsgZmlsbDogIzY0NzQ4YjsgZmlsbDojNmVlN2I3Ij5PTiBTQ0FMRVdBWTwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjU4IiB3aWR0aD0iODA0IiBoZWlnaHQ9IjMwIiBzdHlsZT0iZmlsbDojMWUyOTNiIi8+Cjx0ZXh0IHg9IjMyIiB5PSI3NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+SW5zdGFuY2UgY2xhc3M8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSI3MyIgeDI9IjM2OCIgeTI9IjczIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtcG9zdGdyZXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8dGV4dCB4PSIzODQiIHk9Ijc3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjEycHg7ZmlsbDojZjFmNWY5Ij5HZW5lcmFsLXB1cnBvc2Ugbm9kZSwgMi04IHZDUFU8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iNjQiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTgiIHJ4PSI5IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6I2ZiYmYyNCIvPgo8dGV4dCB4PSI3NTQiIHk9Ijc3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiODsgZmlsbDojZmJiZjI0Ij5jaGFuZ2VkPC90ZXh0Pgo8cmVjdCB4PSIxNiIgeT0iODgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiMwZjE3MmEiLz4KPHRleHQgeD0iMzIiIHk9IjEwNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+TXVsdGktQVo8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIxMDMiIHgyPSIzNjgiIHkyPSIxMDMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLXJkcy1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjM4NCIgeT0iMTA3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjEycHg7ZmlsbDojZjFmNWY5Ij5Ib3Qgc3RhbmRieSBpbiB0aGUgc2FtZSBkYXRhIGNlbnRlcjwvdGV4dD4KPHJlY3QgeD0iNzA0IiB5PSI5NCIgd2lkdGg9IjEwMCIgaGVpZ2h0PSIxOCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojZmJiZjI0Ii8+Cjx0ZXh0IHg9Ijc1NCIgeT0iMTA3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiODsgZmlsbDojZmJiZjI0Ij5jaGFuZ2VkPC90ZXh0Pgo8cmVjdCB4PSIxNiIgeT0iMTE4IiB3aWR0aD0iODA0IiBoZWlnaHQ9IjMwIiBzdHlsZT0iZmlsbDojMWUyOTNiIi8+Cjx0ZXh0IHg9IjMyIiB5PSIxMzciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4OyBmb250LXNpemU6MTJweDtmaWxsOiNmMWY1ZjkiPkFsbG9jYXRlZCBzdG9yYWdlPC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMTMzIiB4Mj0iMzY4IiB5Mj0iMTMzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtcG9zdGdyZXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8dGV4dCB4PSIzODQiIHk9IjEzNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+QmxvY2sgc3RvcmFnZSB2b2x1bWUsIDUtMTAsMDAwIEdCPC90ZXh0Pgo8cmVjdCB4PSI3MDQiIHk9IjEyNCIgd2lkdGg9IjEwMCIgaGVpZ2h0PSIxOCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojNmVlN2I3Ii8+Cjx0ZXh0IHg9Ijc1NCIgeT0iMTM3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiODsgZmlsbDojNmVlN2I3Ij5tYXBwZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIxNDgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiMwZjE3MmEiLz4KPHRleHQgeD0iMzIiIHk9IjE2NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+UG9zdGdyZVNRTCBtYWpvciB2ZXJzaW9uPC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMTYzIiB4Mj0iMzY4IiB5Mj0iMTYzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtcG9zdGdyZXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8dGV4dCB4PSIzODQiIHk9IjE2NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+UG9zdGdyZVNRTCAxNC0xNyAob2xkZXIgbWFqb3JzIG1vdmUgdG8gMTcpPC90ZXh0Pgo8cmVjdCB4PSI3MDQiIHk9IjE1NCIgd2lkdGg9IjEwMCIgaGVpZ2h0PSIxOCIgcng9IjkiIHN0cm9rZS13aWR0aD0iMS4yIiBzdHlsZT0iZmlsbDojMWUyOTNiO3N0cm9rZTojZmJiZjI0Ii8+Cjx0ZXh0IHg9Ijc1NCIgeT0iMTY3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzdHlsZT0iZm9udDogMTBweCAnU0YgTW9ubycsIHVpLW1vbm9zcGFjZSwgJ0pldEJyYWlucyBNb25vJywgTWVubG8sIG1vbm9zcGFjZTsgZmlsbDogIzk0YTNiODsgZmlsbDojZmJiZjI0Ij5jaGFuZ2VkPC90ZXh0Pgo8cmVjdCB4PSIxNiIgeT0iMTc4IiB3aWR0aD0iODA0IiBoZWlnaHQ9IjMwIiBzdHlsZT0iZmlsbDojMWUyOTNiIi8+Cjx0ZXh0IHg9IjMyIiB5PSIxOTciIHN0eWxlPSJmb250OiAxMXB4IEludGVyLCBzYW5zLXNlcmlmOyBmaWxsOiAjOTRhM2I4OyBmb250LXNpemU6MTJweDtmaWxsOiNmMWY1ZjkiPk1hc3RlciB1c2VybmFtZSBhbmQgcGFzc3dvcmQ8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIxOTMiIHgyPSIzNjgiIHkyPSIxOTMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLXJkcy1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjM4NCIgeT0iMTk3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjEycHg7ZmlsbDojZjFmNWY5Ij5Qcm92aXNpb25lZCBhZG1pbiB1c2VyLCBwYXNzd29yZCB2aWEgdmFyaWFibGU8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMTg0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiNmYmJmMjQiLz4KPHRleHQgeD0iNzU0IiB5PSIxOTciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiNmYmJmMjQiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIyMDgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiMwZjE3MmEiLz4KPHRleHQgeD0iMzIiIHk9IjIyNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+SUFNIGRhdGFiYXNlIGF1dGhlbnRpY2F0aW9uPC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMjIzIiB4Mj0iMzY4IiB5Mj0iMjIzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtcG9zdGdyZXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8dGV4dCB4PSIzODQiIHk9IjIyNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+Tm8gZXF1aXZhbGVudDsgY2xpZW50cyBjYW5ub3QgY29ubmVjdDwvdGV4dD4KPHJlY3QgeD0iNzA0IiB5PSIyMTQiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTgiIHJ4PSI5IiBzdHJva2Utd2lkdGg9IjEuMiIgc3R5bGU9ImZpbGw6IzFlMjkzYjtzdHJva2U6I2Y4NzE3MSIvPgo8dGV4dCB4PSI3NTQiIHk9IjIyNyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgc3R5bGU9ImZvbnQ6IDEwcHggJ1NGIE1vbm8nLCB1aS1tb25vc3BhY2UsICdKZXRCcmFpbnMgTW9ubycsIE1lbmxvLCBtb25vc3BhY2U7IGZpbGw6ICM5NGEzYjg7IGZpbGw6I2Y4NzE3MSI+b21pdHRlZDwvdGV4dD4KPHJlY3QgeD0iMTYiIHk9IjIzOCIgd2lkdGg9IjgwNCIgaGVpZ2h0PSIzMCIgc3R5bGU9ImZpbGw6IzFlMjkzYiIvPgo8dGV4dCB4PSIzMiIgeT0iMjU3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjEycHg7ZmlsbDojZjFmNWY5Ij5CYWNrdXAgcmV0ZW50aW9uIGFuZCB3aW5kb3c8L3RleHQ+CjxsaW5lIHgxPSIzMTgiIHkxPSIyNTMiIHgyPSIzNjgiIHkyPSIyNTMiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI2FodC15b3VyLXJkcy1wb3N0Z3Jlc3FsLWRlY2xhcmF0aW9uLW9uLXNjYWxld2F5KSIgc3R5bGU9InN0cm9rZTojNjQ3NDhiIi8+Cjx0ZXh0IHg9IjM4NCIgeT0iMjU3IiBzdHlsZT0iZm9udDogMTFweCBJbnRlciwgc2Fucy1zZXJpZjsgZmlsbDogIzk0YTNiODsgZm9udC1zaXplOjEycHg7ZmlsbDojZjFmNWY5Ij5TY2FsZXdheSdzIG93biBiYWNrdXAgc2NoZWR1bGU8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMjQ0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiNmYmJmMjQiLz4KPHRleHQgeD0iNzU0IiB5PSIyNTciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiNmYmJmMjQiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIyNjgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiMwZjE3MmEiLz4KPHRleHQgeD0iMzIiIHk9IjI4NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+Q3VzdG9tZXItbWFuYWdlZCBLTVMga2V5PC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMjgzIiB4Mj0iMzY4IiB5Mj0iMjgzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtcG9zdGdyZXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8dGV4dCB4PSIzODQiIHk9IjI4NyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+U2NhbGV3YXktbWFuYWdlZCBlbmNyeXB0aW9uIGF0IHJlc3Q8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMjc0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiNmYmJmMjQiLz4KPHRleHQgeD0iNzU0IiB5PSIyODciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiNmYmJmMjQiPmNoYW5nZWQ8L3RleHQ+CjxyZWN0IHg9IjE2IiB5PSIyOTgiIHdpZHRoPSI4MDQiIGhlaWdodD0iMzAiIHN0eWxlPSJmaWxsOiMxZTI5M2IiLz4KPHRleHQgeD0iMzIiIHk9IjMxNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+UGFyYW1ldGVyIGFuZCBvcHRpb24gZ3JvdXBzPC90ZXh0Pgo8bGluZSB4MT0iMzE4IiB5MT0iMzEzIiB4Mj0iMzY4IiB5Mj0iMzEzIiBzdHJva2Utd2lkdGg9IjEuNiIgbWFya2VyLWVuZD0idXJsKCNhaHQteW91ci1yZHMtcG9zdGdyZXNxbC1kZWNsYXJhdGlvbi1vbi1zY2FsZXdheSkiIHN0eWxlPSJzdHJva2U6IzY0NzQ4YiIvPgo8dGV4dCB4PSIzODQiIHk9IjMxNyIgc3R5bGU9ImZvbnQ6IDExcHggSW50ZXIsIHNhbnMtc2VyaWY7IGZpbGw6ICM5NGEzYjg7IGZvbnQtc2l6ZToxMnB4O2ZpbGw6I2YxZjVmOSI+UmVtb3ZlZDsgc2V0IGVuZ2luZSBzZXR0aW5ncyBvbiB0aGUgaW5zdGFuY2U8L3RleHQ+CjxyZWN0IHg9IjcwNCIgeT0iMzA0IiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjE4IiByeD0iOSIgc3Ryb2tlLXdpZHRoPSIxLjIiIHN0eWxlPSJmaWxsOiMxZTI5M2I7c3Ryb2tlOiNmODcxNzEiLz4KPHRleHQgeD0iNzU0IiB5PSIzMTciIHRleHQtYW5jaG9yPSJtaWRkbGUiIHN0eWxlPSJmb250OiAxMHB4ICdTRiBNb25vJywgdWktbW9ub3NwYWNlLCAnSmV0QnJhaW5zIE1vbm8nLCBNZW5sbywgbW9ub3NwYWNlOyBmaWxsOiAjOTRhM2I4OyBmaWxsOiNmODcxNzEiPm9taXR0ZWQ8L3RleHQ+Cjwvc3ZnPg==) Tensor9 applies this translation once, when the product is deployed. #### Limitations Where RDS PostgreSQL and Scaleway differ * **Instance sizes behave differently: they stop at 8 vCPU.** Instance classes map to Scaleway's general-purpose node types from 2 vCPU / 3 GB to 8 vCPU / 29 GB. A larger class maps to the largest of these, with less memory than the origin; size the workload before migrating. * **Availability SLAs behave differently: these node types have none.** Scaleway's SLA (99.95% for high availability, 99.5% standalone) covers only its POP2 node types, which this mapping does not select. * **High availability behaves differently: the standby shares a data center.** Scaleway replicates synchronously to a hot standby in a separate rack of the same data center. It protects against a node or rack failure, not the loss of a whole availability zone. * **Backups behave differently: they follow Scaleway's own schedule.** Backup retention and the preferred backup window are not preserved; set Scaleway's backup frequency and retention after deployment. * **Customer-managed KMS keys are not supported.** Encryption at rest is on, with Scaleway-managed keys. * **Parameter and option groups are not supported.** Engine settings are configured on the Scaleway instance itself; option groups have no equivalent. * **The runtime RDS API is not supported.** Snapshots, restores, failover, replicas, the Data API and event subscriptions are not available through RDS calls on this backend. #### Other considerations **Migration.** Moving the data is a one-time step: a logical dump and restore, or replication for a short cutover. Check IAM database authentication and the instance size first. **Operations.** The customer owns the database in their Scaleway project: maintenance windows, quotas and pricing are Scaleway's. Scaleway's availability SLA covers only its POP2 node types, so the general-purpose node types this mapping selects have no Scaleway availability commitment. **Features and capacity.** The comparison table on this page lists feature and high-availability differences. #### Example monthly charges This Tensor9 Cloud Adapter scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method and what the estimates include. **Native or deployment mapping.** This mapping provisions a native database. SQL clients connect directly to it; this directed mapping does not expose an RDS management adapter endpoint. Database availability and query latency are covered by the database provider, not a Tensor9 request-processing SLA. Cost estimates describe the selected service resources; operation coverage remains separate. ##### RDS PostgreSQL · Primary allocated compute Feature: RDS 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. ![RDS 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/e5d50c9a314396e4a68e8618504f81933cd8ed0e77324a6dc537ee6562408d40-light.svg) ![RDS 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/1666bcf92f475dcae73e8a11a6668e920ff1a2a07f78c1be865d7142c5bc867c-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Primary allocated compute (vCPU-hours/month) | RDS 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 | 129.94 | Scaleway Managed Database for PostgreSQL (one copy) | 101.10 | -28.84 | | 1,460 | 129.94 | Scaleway Managed Database for PostgreSQL (two copies) | 154.69 | 24.75 | | 2,920 | 259.88 | Scaleway Managed Database for PostgreSQL (one copy) | 191.08 | -68.80 | | 2,920 | 259.88 | Scaleway Managed Database for PostgreSQL (two copies) | 292.35 | 32.47 | | 5,840 | 519.76 | Scaleway Managed Database for PostgreSQL (one copy) | 371.03 | -148.73 | | 5,840 | 519.76 | Scaleway Managed Database for PostgreSQL (two copies) | 567.68 | 47.92 | | 11,680 | 1,039.52 | Scaleway Managed Database for PostgreSQL (one copy) | 730.94 | -308.58 | | 11,680 | 1,039.52 | Scaleway Managed Database for PostgreSQL (two copies) | 1,118.33 | 78.81 | | 23,360 | 2,079.04 | Scaleway Managed Database for PostgreSQL (one copy) | 1,450.74 | -628.30 | | 23,360 | 2,079.04 | Scaleway Managed Database for PostgreSQL (two copies) | 2,219.64 | 140.60 | | 46,720 | 4,158.08 | Scaleway Managed Database for PostgreSQL (one copy) | Unpriced | Unavailable | | 46,720 | 4,158.08 | 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.089 | 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.115 | 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.089 | 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.115 | 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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-c828ea2296c34e1fe5b1f54217e1ed4e0bda56ff` / `2026-10-22.planning.2`. Curve: `workload-1`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Scaleway Managed Databases pricing](https://www.scaleway.com/en/pricing/managed-databases/). ##### RDS PostgreSQL · Stored data Feature: RDS PostgreSQL. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: fr-par; currency: USD. ![RDS 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/f8c41fb9c66a8f06319f336f9e5eb9e865eea03b92988f7cb9f4efbb57b52ff4-light.svg) ![RDS 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/1c0e9f41290a7412f36308842eb8ab12f6b7eb7560c0574f7ea3dc82cfc3181b-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Stored data (GiB-month) | RDS 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.15 | Scaleway Managed Database for PostgreSQL (one copy) | 101.10 | 99.95 | | 10 | 1.15 | Scaleway Managed Database for PostgreSQL (two copies) | 154.69 | 153.54 | | 100 | 11.50 | Scaleway Managed Database for PostgreSQL (one copy) | 106.67 | 95.17 | | 100 | 11.50 | Scaleway Managed Database for PostgreSQL (two copies) | 163.20 | 151.70 | | 1,000 | 115.00 | Scaleway Managed Database for PostgreSQL (one copy) | 231.84 | 116.84 | | 1,000 | 115.00 | Scaleway Managed Database for PostgreSQL (two copies) | 354.71 | 239.71 | | 10,000 | 1,150.00 | Scaleway Managed Database for PostgreSQL (one copy) | 1,483.58 | 333.58 | | 10,000 | 1,150.00 | Scaleway Managed Database for PostgreSQL (two copies) | 2,269.87 | 1,119.87 | | 100,000 | 11,500.00 | Scaleway Managed Database for PostgreSQL (one copy) | Unpriced | Unavailable | | 100,000 | 11,500.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.089 | 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.115 | 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.089 | 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.115 | 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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-c828ea2296c34e1fe5b1f54217e1ed4e0bda56ff` / `2026-10-22.planning.2`. Curve: `workload-2`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Scaleway Managed Databases pricing](https://www.scaleway.com/en/pricing/managed-databases/). ##### RDS PostgreSQL · Database writes Feature: RDS PostgreSQL. Estimated monthly service charges by Database writes. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: fr-par; currency: USD. ![RDS 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/755d2f5b7f7a257061e6900dadf938582f052ed1a6984ed1cb94cde674c14ad9-light.svg) ![RDS 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/25c15ddc60f3700610bcd10ddf14e65c5be0ad16fb2e86c7c64f0e468a31fd60-dark.svg) Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. | Database writes (per second) | RDS 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.089 | 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.115 | 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.089 | 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.115 | 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. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * 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-c828ea2296c34e1fe5b1f54217e1ed4e0bda56ff` / `2026-10-22.planning.2`. Curve: `workload-3`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Scaleway Managed Databases pricing](https://www.scaleway.com/en/pricing/managed-databases/). **RDS 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.089 | USD/vCPU-hours | | Origin list price · Primary memory | 0 | USD/GiB-hours | | Origin list price · Primary provisioned storage | 0.115 | USD/GiB-month | | Origin list price · Database reads | 0 | USD/operations | | Origin list price · Database writes | 0 | USD/operations | | Target CPU / source CPU | 1 | multiplier | | Target RAM / source RAM | 1 | multiplier | | Target disk / source disk | 1 | multiplier | | Target price guess · read | 0 | USD/read | | Target price guess · write | 0 | USD/write | | Target price guess · provider operation | 0 | USD/provider operation | | Target list price · GiB-month | 0.111266 | USD/GiB-month | | Target price guess · published GiB | 0 | USD/published GiB | | Target price guess · delivered GiB | 0 | USD/delivered GiB | | Target price guess · network GiB | 0 | USD/network GiB | | Target price guess · replica GiB-month | 0 | USD/replica GiB-month | | Target list price · vCPU-hour | 0.0367275 | USD/vCPU-hour | | Target list price · GiB-hour | 0.006225 | USD/GiB-hour | | Target price guess · resource-hour | 0 | USD/resource-hour | | Target price guess · resource-month | 0 | USD/resource-month | | Target price guess · input token | 0 | USD/input token | | Target price guess · output token | 0 | USD/output token | | Target monthly base charge | 0 | USD/month | | Target service minimum | 89.9762 | USD/month | | Minimum primary CPU | 2 | vCPU | | Minimum primary RAM | 8 | GiB | | Minimum primary disk | 100 | GiB | | Additional full-price standby copy | 0 | 0 or 1 | | Allocated share of provisioned cost | 1 | fraction | | Read/write work per vCPU-second | 1,500 | operations/vCPU-second | | Planning peak / mean work | 2 | multiplier | | Planning primary CPU utilization | 0.7 | fraction | | Resident state reserved in RAM | 0.1 | fraction | | Planning disk utilization | 0.8 | fraction | | Maintenance and log disk reserve | 20 | GiB | | Staging database CPU unit-price guess | 0.0413 | USD/vCPU-hour | | Staging database RAM unit-price guess | 0.007 | USD/GiB-hour | | Staging database disk unit-price guess | 0.17 | USD/GiB-month | | Dependent object sink storage price guess | 0.023 | USD/GiB-month | | Dependent object sink write price guess | 0.000005 | USD/write | | Primary compute | 0 | vCPU-hours | | Primary memory | 0 | GiB-hours | | Primary provisioned storage | 0 | GiB-month | | Database reads | 0 | operations | | Database writes | 0 | operations | * Translated reads: 0 operations. * Translated writes: 0 operations. * Translated resident physical data: 0 GiB-month. * Native provider operations: 0 operations. * Published payload: 0 GiB. * Delivered payload: 0 GiB. * Allocated execution CPU: 0 vCPU-hour. * Allocated execution RAM: 0 GiB-hour. * Independent resource allocation: 0 resource-hour. * Independent inventory: 0 resource-month. * Input tokens: 0 tokens. * Output tokens: 0 tokens. * Billable network: 0 GiB. * Dependent object sink retained data: 0 GiB-month. * Dependent object sink writes: 0 writes. * Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote. * Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free. * Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified. * Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity. * A declared adapter mapping and cost model do not establish implementation availability or service equivalence. * This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support. * Native/deployment comparison scope: This mapping provisions a native database. SQL clients connect directly to it; this directed mapping does not expose an RDS management adapter endpoint. Database availability and query latency are covered by the database provider, not a Tensor9 request-processing SLA. * Authored planning assumptions, not measured adapter capacity. Origin rates are cited first-tier list prices, before free allowances and discounts. * A cost scenario does not establish backend availability, protocol fidelity or production readiness. Registry serving status remains independent. * Provisioned compute and RAM are priced by resource-hour; operations are independently authored. Database size cannot be inferred from dollars alone. * Aurora/AlloyDB, MySQL/PostgreSQL and proxied targets retain their distinct backend contracts. HA, replicas and proxy allocations must be selected explicitly. * RDS memory is included in the instance-hour price; the memory meter is zero so RAM is not counted twice. * Scaleway Managed Database for 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-c828ea2296c34e1fe5b1f54217e1ed4e0bda56ff` / `2026-10-22.planning.2`. Scenario: `planning-example`. Sources: [AWS Price List API, AmazonRDS offer](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRDS/current/us-east-1/index.json), [Scaleway Managed Databases pricing](https://www.scaleway.com/en/pricing/managed-databases/). ## Costs Estimated monthly service charges for each backend with a published cost model, at one sampled workload from that model's cost curve. Adapter hosting and Tensor9 fees are excluded. [How Tensor9 estimates costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/overview.md) explains the method, what the estimates include and how to read their qualifications. | Backend | Sampled workload | Price basis | Origin USD/month | Backend USD/month | Difference | Mapping | | - | - | - | -: | -: | -: | - | | Cloud SQL for PostgreSQL | Primary vCPUs: 8 vCPU; zonal | Reference rates, 2026-10-18 | 531.26 | 421.71 | -109.55 | Service adapter | | Cloud SQL for PostgreSQL (RDS proxy) | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 519.76 | 421.71 | -98.05 | Service adapter | | OCI Database with PostgreSQL | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 519.76 | 340.08 | -179.68 | Service adapter | | PostgreSQL | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 519.76 | 531.50 | +11.74 | Service adapter | | PostgreSQL (CloudNativePG) | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 519.76 | 293.58 | -226.18 | Service adapter | | PostgreSQL Flexible Server | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 519.76 | 531.26 | +11.50 | Service adapter | | Scaleway Managed Database for PostgreSQL | Primary allocated compute: 5,840 vCPU-hours/month; one copy | Cited list prices, 2026-10-22 | 519.76 | 371.03 | -148.73 | Native or deployment | Difference means backend minus origin; a positive difference means the backend costs more. Workloads and target configurations differ by model, so compare each row's difference at its stated workload rather than charges across rows. Cost curves across workload sizes, with every assumption and exclusion: [Amazon RDS costs](https://docs.tensor9.com/cloud-adapter-early-access/costs/rds.md). ## Service level agreements > [!WARNING] > > These tables show Tensor9's standard service levels and adapters whose standard terms are still being defined. Your signed agreement determines the SLAs, covered adapters and operations, limits, remedies and support terms that apply to your deployment. Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider's own SLA. Each origin-to-target pair has its own terms or an explicit pending status. See the [SLA tables](https://docs.tensor9.com/cloud-adapter-early-access/support/service-adapter-slas.md), [measurement rules](https://docs.tensor9.com/cloud-adapter-early-access/support/service-levels.md), and [scaling conditions](https://docs.tensor9.com/cloud-adapter-early-access/support/scaling-and-limits.md). ### RDS 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`, `DescribeDBInstances`, `DescribeDBSnapshots` | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | | Database lifecycle request acceptance adapter-added latency | +30 ms monthly p99 | `aws::1.0.0::rds`: `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DescribeDBClusters`, `DescribeDBInstances`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance` | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | | Bounded database parameter requests adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | | Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::rds`: `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `DescribeDBInstances`, `DescribeDBSnapshots`, `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance`, `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database's configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | | Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. | | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | **Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. **What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA. **How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. **Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. #### What this adapter does For `azure::1.0.0::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`, `DescribeDBInstances`, `DescribeDBSnapshots`. The control adapter reads its durable database records and checks native status; reading the adapter's stored request history and current resource records counts as fabric work. **Database lifecycle request acceptance: +30 ms monthly p99 (adapter-added).** `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DescribeDBClusters`, `DescribeDBInstances`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance`. The RDS adapter durably records the requested change before its background workers update target resources. Waiting for those adapter records and coordination still counts as fabric time, not database query time. **Bounded database parameter requests: +20 ms monthly p99 (adapter-added).** `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup`. Parameter validation and logical-group persistence precede mapping to target flags; provider restart timing is distinct from adapter request handling. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable. #### What counts toward latency For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded. #### Endpoint reachability and request failures The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results. #### Scaling and target-service capacity Control-plane load is measured in logical resources, status polling and concurrent changes, not application SQL QPS. Aggressive Describe loops can exhaust adapter/log capacity even when database query load is small. Tensor9 scales the API and reconciliation workers within agreed resource and polling limits; the customer selects database compute, storage, connections and HA. Native database provisioning or failover speed cannot be improved merely by scaling control-plane replicas. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA. #### Data and behavior guarantees A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database's configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. #### Example and diagnosis Modify `orders-db` to change an allowed parameter and poll its status at an agreed interval. The request-acceptance row covers adapter validation and durable intent; a database restart can take longer without breaching that row. Separately measure an application's SELECT directly against the target endpoint: that SQL latency is not the RDS adapter's 20 or 30 ms control budget. Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed. ### RDS 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`, `DescribeDBInstances`, `DescribeDBSnapshots` | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | | Database lifecycle request acceptance adapter-added latency | +30 ms monthly p99 | `aws::1.0.0::rds`: `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DescribeDBClusters`, `DescribeDBInstances`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance` | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | | Bounded database parameter requests adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | | Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::rds`: `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `DescribeDBInstances`, `DescribeDBSnapshots`, `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance`, `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database's configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | | Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. | | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | **Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. **What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA. **How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. **Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. #### What this adapter does For `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`, `DescribeDBInstances`, `DescribeDBSnapshots`. The control adapter reads its durable database records and checks native status; reading the adapter's stored request history and current resource records counts as fabric work. **Database lifecycle request acceptance: +30 ms monthly p99 (adapter-added).** `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DescribeDBClusters`, `DescribeDBInstances`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance`. The RDS adapter durably records the requested change before its background workers update target resources. Waiting for those adapter records and coordination still counts as fabric time, not database query time. **Bounded database parameter requests: +20 ms monthly p99 (adapter-added).** `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup`. Parameter validation and logical-group persistence precede mapping to target flags; provider restart timing is distinct from adapter request handling. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable. #### What counts toward latency For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded. #### Endpoint reachability and request failures The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results. #### Scaling and target-service capacity Control-plane load is measured in logical resources, status polling and concurrent changes, not application SQL QPS. Aggressive Describe loops can exhaust adapter/log capacity even when database query load is small. Tensor9 scales the API and reconciliation workers within agreed resource and polling limits; the customer selects database compute, storage, connections and HA. Native database provisioning or failover speed cannot be improved merely by scaling control-plane replicas. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA. #### Data and behavior guarantees A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database's configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. #### Example and diagnosis Modify `orders-db` to change an allowed parameter and poll its status at an agreed interval. The request-acceptance row covers adapter validation and durable intent; a database restart can take longer without breaching that row. Separately measure an application's SELECT directly against the target endpoint: that SQL latency is not the RDS adapter's 20 or 30 ms control budget. Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed. ### RDS 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`: `DescribeDBInstances` | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | | Database lifecycle request acceptance adapter-added latency | +30 ms monthly p99 | `aws::1.0.0::rds`: `CreateDBInstance`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DeleteDBInstance`, `DescribeDBInstances`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime` | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | | Bounded database parameter requests adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | | Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::rds`: `DescribeDBInstances`, `CreateDBInstance`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DeleteDBInstance`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database's configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | | Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. | | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | **Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. **What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA. **How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. **Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. #### What this adapter does For `digitalocean::1.0.0::database::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).** `DescribeDBInstances`. The control adapter reads its durable database records and checks native status; reading the adapter's stored request history and current resource records counts as fabric work. **Database lifecycle request acceptance: +30 ms monthly p99 (adapter-added).** `CreateDBInstance`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DeleteDBInstance`, `DescribeDBInstances`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`. The RDS adapter durably records the requested change before its background workers update target resources. Waiting for those adapter records and coordination still counts as fabric time, not database query time. **Bounded database parameter requests: +20 ms monthly p99 (adapter-added).** `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup`. Parameter validation and logical-group persistence precede mapping to target flags; provider restart timing is distinct from adapter request handling. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable. #### What counts toward latency For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded. #### Endpoint reachability and request failures The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results. #### Scaling and target-service capacity Control-plane load is measured in logical resources, status polling and concurrent changes, not application SQL QPS. Aggressive Describe loops can exhaust adapter/log capacity even when database query load is small. Tensor9 scales the API and reconciliation workers within agreed resource and polling limits; the customer selects database compute, storage, connections and HA. Native database provisioning or failover speed cannot be improved merely by scaling control-plane replicas. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA. #### Data and behavior guarantees A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database's configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. #### Example and diagnosis Modify `orders-db` to change an allowed parameter and poll its status at an agreed interval. The request-acceptance row covers adapter validation and durable intent; a database restart can take longer without breaching that row. Separately measure an application's SELECT directly against the target endpoint: that SQL latency is not the RDS adapter's 20 or 30 ms control budget. Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed. ### RDS 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`, `DescribeDBInstances`, `DescribeDBSnapshots` | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | | Database lifecycle request acceptance adapter-added latency | +30 ms monthly p99 | `aws::1.0.0::rds`: `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DescribeDBClusters`, `DescribeDBInstances`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance` | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | | Bounded database parameter requests adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | | Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::rds`: `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `DescribeDBInstances`, `DescribeDBSnapshots`, `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance`, `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database's configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | | Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. | | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | **Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. **What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA. **How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. **Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. #### What this adapter does For `google::1.0.0::cloudsql::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`, `DescribeDBInstances`, `DescribeDBSnapshots`. The control adapter reads its durable database records and checks native status; reading the adapter's stored request history and current resource records counts as fabric work. **Database lifecycle request acceptance: +30 ms monthly p99 (adapter-added).** `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DescribeDBClusters`, `DescribeDBInstances`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance`. The RDS adapter durably records the requested change before its background workers update target resources. Waiting for those adapter records and coordination still counts as fabric time, not database query time. **Bounded database parameter requests: +20 ms monthly p99 (adapter-added).** `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup`. Parameter validation and logical-group persistence precede mapping to target flags; provider restart timing is distinct from adapter request handling. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable. #### What counts toward latency For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded. #### Endpoint reachability and request failures The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results. #### Scaling and target-service capacity Control-plane load is measured in logical resources, status polling and concurrent changes, not application SQL QPS. Aggressive Describe loops can exhaust adapter/log capacity even when database query load is small. Tensor9 scales the API and reconciliation workers within agreed resource and polling limits; the customer selects database compute, storage, connections and HA. Native database provisioning or failover speed cannot be improved merely by scaling control-plane replicas. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA. #### Data and behavior guarantees A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database's configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. #### Example and diagnosis Modify `orders-db` to change an allowed parameter and poll its status at an agreed interval. The request-acceptance row covers adapter validation and durable intent; a database restart can take longer without breaching that row. Separately measure an application's SELECT directly against the target endpoint: that SQL latency is not the RDS adapter's 20 or 30 ms control budget. Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed. ### RDS PostgreSQL to Cloud SQL for PostgreSQL (RDS proxy) | SLA | Service level | What is covered | Conditions | | - | - | - | - | | Bounded database status responses adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `DescribeDBInstances`, `DescribeDBSnapshots` | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. The RDS PostgreSQL-to-Cloud SQL backend behind the Tensor9 PostgreSQL proxy is declared, not a generally deployed production endpoint. It is composed only by sipsvr's Docker deployment with a configured database proxy. 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. | | Database lifecycle request acceptance adapter-added latency | +30 ms monthly p99 | `aws::1.0.0::rds`: `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DescribeDBClusters`, `DescribeDBInstances`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance` | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. The RDS PostgreSQL-to-Cloud SQL backend behind the Tensor9 PostgreSQL proxy is declared, not a generally deployed production endpoint. It is composed only by sipsvr's Docker deployment with a configured database proxy. 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. | | 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. The RDS PostgreSQL-to-Cloud SQL backend behind the Tensor9 PostgreSQL proxy is declared, not a generally deployed production endpoint. It is composed only by sipsvr's Docker deployment with a configured database proxy. 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`: `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `DescribeDBInstances`, `DescribeDBSnapshots`, `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance`, `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database's configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | | Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. The RDS PostgreSQL-to-Cloud SQL backend behind the Tensor9 PostgreSQL proxy is declared, not a generally deployed production endpoint. It is composed only by sipsvr's Docker deployment with a configured database proxy. 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 RDS PostgreSQL-to-Cloud SQL backend behind the Tensor9 PostgreSQL proxy is declared, not a generally deployed production endpoint. It is composed only by sipsvr's Docker deployment with a configured database proxy. 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 For Cloud SQL behind the Tensor9 PostgreSQL proxy, these rows apply to the RDS API adapter. The RDS control runtime retains logical intent, exposes status and reconciles the Cloud SQL instance and its proxy. 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 database status responses: +20 ms monthly p99 (adapter-added).** `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `DescribeDBInstances`, `DescribeDBSnapshots`. The control adapter reads its durable database records and checks native status; reading the adapter's stored request history and current resource records counts as fabric work. **Database lifecycle request acceptance: +30 ms monthly p99 (adapter-added).** `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DescribeDBClusters`, `DescribeDBInstances`, `FailoverDBCluster`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RebootDBInstance`, `RestoreDBClusterFromSnapshot`, `RestoreDBClusterToPointInTime`, `RestoreDBInstanceFromDBSnapshot`, `RestoreDBInstanceToPointInTime`, `StartDBInstance`, `StopDBInstance`. The RDS adapter durably records the requested change before its background workers update target resources. Waiting for those adapter records and coordination still counts as fabric time, not database query time. **Bounded database parameter requests: +20 ms monthly p99 (adapter-added).** `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup`. Parameter validation and logical-group persistence precede mapping to target flags; provider restart timing is distinct from adapter request handling. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable. #### What counts toward latency For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded. #### Endpoint reachability and request failures The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results. #### Scaling and target-service capacity Control-plane load is measured in logical resources, status polling and concurrent changes, not application SQL QPS. Aggressive Describe loops can exhaust adapter/log capacity even when database query load is small. Tensor9 scales the API and reconciliation workers within agreed resource and polling limits; the customer selects database compute, storage, connections and HA. Native database provisioning or failover speed cannot be improved merely by scaling control-plane replicas. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA. #### Data and behavior guarantees A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database's configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. #### Example and diagnosis Modify `orders-db` to change an allowed parameter and poll its status at an agreed interval. The request-acceptance row covers adapter validation and durable intent; a database restart can take longer without breaching that row. Separately measure an application's SELECT directly against the target endpoint: that SQL latency is not the RDS adapter's 20 or 30 ms control budget. Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed. ### RDS 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`, `DescribeDBInstances`, `DescribeDBSnapshots` | One page of at most 100 database, cluster or snapshot records and 256 KiB response. Reports logical state and available native status; it is not a SQL query latency commitment. | | Database lifecycle request acceptance adapter-added latency | +30 ms monthly p99 | `aws::1.0.0::rds`: `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DescribeDBClusters`, `DescribeDBInstances`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RestoreDBClusterFromSnapshot`, `RestoreDBInstanceFromDBSnapshot`, `StartDBInstance`, `StopDBInstance` | One instance or cluster change and at most 32 KiB settings. Instance failover uses RebootDBInstance with ForceFailover=true where this target supports that behavior. Measures validation and durable request acceptance/status response, not elapsed provisioning, backup, restore, restart or failover completion. | | Bounded database parameter requests adapter-added latency | +20 ms monthly p99 | `aws::1.0.0::rds`: `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | One logical parameter group, at most 50 supported overrides and 32 KiB settings, or one page of at most 100 parameter descriptions. Does not promise when a pending-reboot parameter takes effect. | | Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::rds`: `DescribeDBClusterSnapshots`, `DescribeDBClusters`, `DescribeDBInstances`, `DescribeDBSnapshots`, `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RestoreDBClusterFromSnapshot`, `RestoreDBInstanceFromDBSnapshot`, `StartDBInstance`, `StopDBInstance`, `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup` | A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database's configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. | | Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. | | Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. | **Adapter-added latency.** A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider's SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. **What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA. **How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. **Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment. #### What this adapter does For `oci::1.0.0::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`, `DescribeDBInstances`, `DescribeDBSnapshots`. The control adapter reads its durable database records and checks native status; reading the adapter's stored request history and current resource records counts as fabric work. **Database lifecycle request acceptance: +30 ms monthly p99 (adapter-added).** `CreateDBClusterSnapshot`, `CreateDBInstanceReadReplica`, `CreateDBSnapshot`, `DescribeDBClusters`, `DescribeDBInstances`, `ModifyDBCluster`, `ModifyDBInstance`, `PromoteReadReplica`, `RestoreDBClusterFromSnapshot`, `RestoreDBInstanceFromDBSnapshot`, `StartDBInstance`, `StopDBInstance`. The RDS adapter durably records the requested change before its background workers update target resources. Waiting for those adapter records and coordination still counts as fabric time, not database query time. **Bounded database parameter requests: +20 ms monthly p99 (adapter-added).** `DescribeDBParameters`, `ModifyDBClusterParameterGroup`, `ModifyDBParameterGroup`. Parameter validation and logical-group persistence precede mapping to target flags; provider restart timing is distinct from adapter request handling. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable. #### What counts toward latency For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded. #### Endpoint reachability and request failures The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9's responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results. #### Scaling and target-service capacity Control-plane load is measured in logical resources, status polling and concurrent changes, not application SQL QPS. Aggressive Describe loops can exhaust adapter/log capacity even when database query load is small. Tensor9 scales the API and reconciliation workers within agreed resource and polling limits; the customer selects database compute, storage, connections and HA. Native database provisioning or failover speed cannot be improved merely by scaling control-plane replicas. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA. #### Data and behavior guarantees A successful lifecycle response must accurately identify accepted work and logical state, not falsely claim that the target is already ready. Reconciliation must not apply one logical database's configuration to another. Unsupported engine flags, cross-region semantics and AWS-specific SQL remain explicitly limited by the profile. Backup retention, database data durability, query consistency and target failover recovery are not implicitly replaced by this control-plane SLA. #### Example and diagnosis Modify `orders-db` to change an allowed parameter and poll its status at an agreed interval. The request-acceptance row covers adapter validation and durable intent; a database restart can take longer without breaching that row. Separately measure an application's SELECT directly against the target endpoint: that SQL latency is not the RDS adapter's 20 or 30 ms control budget. Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed. ### RDS 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::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.