RDS PostgreSQL

On this page

• Coverage by target cloud
• How the backends compare
  • Max adaptation
  • Infrastructure-only adaptation
• On Google Cloud
  • Via Cloud SQL for PostgreSQL
  • Via Cloud SQL for PostgreSQL (RDS proxy)
• On Azure
• On OCI
• On Private Kubernetes
• Costs
• Service level agreements
  • RDS PostgreSQL to PostgreSQL Flexible Server
  • RDS PostgreSQL to PostgreSQL (CloudNativePG)
  • RDS PostgreSQL to Cloud SQL for PostgreSQL
  • RDS PostgreSQL to Cloud SQL for PostgreSQL (RDS proxy)
  • RDS PostgreSQL to OCI Database with PostgreSQL
  • RDS PostgreSQL to Scaleway Managed Database for PostgreSQL
• Debug this service

​

Coverage by target cloud

​

How the backends compare

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

​

Max adaptation

​

Runtime surface

​

Management surface

​

Limits

​

Infrastructure-only adaptation

​

Runtime surface

​

Management surface

​

Limits

​

On Google Cloud

​

Via Cloud SQL for PostgreSQL

​

How it works

Your application’s PostgreSQL driver connects directly to Cloud SQL for PostgreSQL. These database requests are the data plane. The driver and 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 appliance and translates each of these requests to the backend’s management API. The sections below list which operations work and which return an error.

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.

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 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs 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. 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. Curve assumptions

• 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/
• 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/

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, AWS RDS us-east-1 reference price list, Cloud SQL Enterprise PostgreSQL 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. 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. Curve assumptions

• 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/
• 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/

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, AWS RDS us-east-1 reference price list, Cloud SQL Enterprise PostgreSQL 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. 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. Curve assumptions

• 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/
• 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/

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, AWS RDS us-east-1 reference price list, Cloud SQL Enterprise PostgreSQL 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. 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. Curve assumptions

• 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/
• 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/

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, AWS RDS us-east-1 reference price list, Cloud SQL Enterprise PostgreSQL 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. 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

• 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, AWS RDS us-east-1 reference price list, Cloud SQL Enterprise PostgreSQL pricing.

​

Via Cloud SQL for PostgreSQL (RDS proxy)

​

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

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:<DB resource ID>/<user>, 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.

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 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs 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. 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. 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

• 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): 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). 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).
• 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
• Cloud 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, Cloud 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. 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. 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

• 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): 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). 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).
• 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
• Cloud 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, Cloud 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. 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. Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample. Curve assumptions

• 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): 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). 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).
• 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
• Cloud 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, Cloud 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. 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

• 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): 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). 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).
• 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, Cloud SQL pricing.

​

On Azure

​

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 appliance and translates each of these requests to the backend’s management API. The sections below list which operations work and which return an error.

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.

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 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs 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. 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. 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

• 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): 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). 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); Premium SSD storage holds up to 32,767 GiB (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
• Azure Retail Prices API: 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, Azure Retail Prices API.

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

• 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): 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). 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); Premium SSD storage holds up to 32,767 GiB (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
• Azure Retail Prices API: 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, Azure Retail Prices API.

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. 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. Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample. Curve assumptions

• 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): 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). 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); Premium SSD storage holds up to 32,767 GiB (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
• Azure Retail Prices API: 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, Azure Retail Prices API. 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. 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

• 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): 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). 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); Premium SSD storage holds up to 32,767 GiB (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, Azure Retail Prices API.

​

On OCI

​

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 appliance and translates each of these requests to the backend’s management API. The sections below list which operations work and which return an error.

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.

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 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs 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. 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. 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

• 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). 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): 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). 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); a database system stores up to 32 TB (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
• 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/

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, OCI price list API, Oracle 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. 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. 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

• 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). 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): 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). 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); a database system stores up to 32 TB (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
• 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/

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, OCI price list API, Oracle 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. 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. Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample. Curve assumptions

• 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). 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): 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). 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); a database system stores up to 32 TB (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
• 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/

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, OCI price list API, Oracle 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. 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

• 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). 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): 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). 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); a database system stores up to 32 TB (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, OCI price list API, Oracle Cloud price list.

​

On Private Kubernetes

​

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 appliance and translates each of these requests to the backend’s management API. The sections below list which operations work and which return an error.

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

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 appliance runs a single CloudNativePG cluster; a second region would need a second appliance.
• 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 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs 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. 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. 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

• 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) 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): 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). 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); a Persistent Disk volume holds up to 64 TiB (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
• 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

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, Compute Engine general-purpose machine pricing, Disk and image pricing, 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. 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. 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

• 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) 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): 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). 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); a Persistent Disk volume holds up to 64 TiB (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
• 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

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, Compute Engine general-purpose machine pricing, Disk and image pricing, 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. 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. Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample. Curve assumptions

• 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) 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): 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). 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); a Persistent Disk volume holds up to 64 TiB (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
• 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

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, Compute Engine general-purpose machine pricing, Disk and image pricing, 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. 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

• 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) 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): 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). 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); a Persistent Disk volume holds up to 64 TiB (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, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.

​

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 explains the method, what the estimates include and how to read their qualifications. 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.

​

Service level agreements

Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider’s own SLA. Each origin-to-target pair has its own terms or an explicit pending status. See the SLA tables, measurement rules, and scaling conditions.

​

RDS PostgreSQL to PostgreSQL Flexible Server

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)

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 Cloud SQL for PostgreSQL

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)

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

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.

​

Debug this service

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