> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # Service Adapter Costs > How Tensor9 estimates what an adapted service costs, what each estimate includes, and how to read the results. ![Origin service charges pass through a Tensor9 cost estimate built from origin usage, physical work and target prices, and become target service charges.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/143d7ff13707bd18a8a797566cce6ba206d1aecf2863aeac623e09e4f1b80a49-light.svg) ![Origin service charges pass through a Tensor9 cost estimate built from origin usage, physical work and target prices, and become target service charges.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/401c39586a168a4536765d9299e2aa93850205d99134adb21142b7a090df3e24-dark.svg) Tensor9 Cloud Adapter keeps the service API your application calls while a different service does the work. Your bill then follows the target service's meters and size, not the origin's. A single multiplier on an origin bill cannot describe every workload: a service billed per request, a service billed per byte and a provisioned database respond differently to the same traffic. Every service page and cost guide therefore estimates both bills from the same workload and shows the difference. Cloud Adapter's bundled [Support Agents](https://docs.tensor9.com/cloud-adapter-early-access/support/agents.md) help you connect those estimates to your workload: review the inputs, explain which assumptions drive a result and identify the evidence needed to validate it. Keep the model's version, regions, rates and exclusions with the comparison so the reasoning remains reviewable. The cost guides publish 198 directed cost models across 55 origin services: 8 use reference rate snapshots and 190 are planning estimates. Every planning estimate cites a provider list price for each rate it bills. ## How Tensor9 estimates adapted-service costs ![Three steps: origin usage in native billing units, physical work from workload assumptions, and target charges at listed prices.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/4a2620bb8b77ce7536d45c6441a0affc5ed9c668d98d40f71ac9b36f7965ec91-light.svg) ![Three steps: origin usage in native billing units, physical work from workload assumptions, and target charges at listed prices.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/145cbefb7e5ca071bd8961b90edc0df77c247d2219632f189432fcbd7ac329b1-dark.svg) **1. Origin usage** The estimate starts from the origin service's native billing quantities: SQS 64-KiB request units, DynamoDB read and write request units, S3 GB-months and request counts. State usage directly, or state monthly charges at the model's reference rates and let the model divide each charge by its rate. **2. Physical work** Workload assumptions translate billing units into the operations, bytes and retained data the target service meters. Message size and batch fill set how many messages a number of SQS request units represents; item size and read consistency set how many point reads a number of DynamoDB read units represents. Every assumption is listed beside the result and can be changed. **3. Target prices** Each target meter is priced at the model's rates. A provisioned target, such as a database instance, is priced for its selected size for 730 hours per month, whatever the traffic. The comparison is the target subtotal minus the origin subtotal. A positive difference means the target service costs more. ## Reference rates and planning estimates Each model states which kind of estimate it is. | | Reference rates | Planning estimates | | - | - | - | | Prices | One named provider rate snapshot, with its date and pricing sources | Cited provider list prices where available, including free allowances, minimums and base charges; otherwise an authored estimate labeled price guess | | Workload translation | Explicit assumptions listed with the result | Explicit assumptions, plus capacity coefficients that are planning assumptions rather than benchmark measurements | | Use it to | Compare list prices for a known workload | Size a direction before measuring it; verify the coefficients before relying on it | Neither kind predicts your invoice. ## What the estimates include ![The estimate covers origin and target service charges. Adapter hosting and Tensor9 fees are allocations you add.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/f8c572855e9eaa4b58c0db117a342f3239bbc6d26d68e38e8e4ba6f607e6efeb-light.svg) ![The estimate covers origin and target service charges. Adapter hosting and Tensor9 fees are allocations you add.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/343220cb79497242232f7599719e3e3ad502cf417f1afa2783a9034d7f910a1b-dark.svg) | Cost | Included | How to account for it | | - | - | - | | Origin service charges for the modeled meters | Yes | Priced at list rates; compare native usage quantities rather than a discounted bill. | | Target service charges for the modeled meters and configuration | Yes | Each result lists every priced line with its quantity and rate. | | Tensor9 fees | No | Allocate the monthly amount from your commercial agreement. A blank allocation stays unestimated. | | Adapter hosting | No | Allocate the compute, load balancers and supporting infrastructure that run the adapter. A blank allocation stays unestimated. | | Free tiers and free allowances | Only when listed | Listed target allowances reduce billed quantities without reducing physical work. Set an allowance to zero if another workload uses it. | | Negotiated discounts, credits, committed-use pricing and tax | No | Apply your own terms to both subtotals. | | Network transfer, backups and encryption keys | Only when listed | Each result's exclusion list names the charges it leaves out. | | Migration, application compute changes and operational labor | No | Estimate separately. | > [!NOTE] > > Because the estimates leave out Tensor9 fees and adapter hosting, a lower target subtotal is not a savings figure. A modeled adapted total exists only after both allocations are supplied. ## Usage charges and provisioned capacity ![A usage-priced service grows with the workload from near zero. A provisioned instance stays flat, steps up between sizes and is not priced beyond its largest size.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/7d1526bdaacebc5fe6f37f3dc761729b7d39db9fb19ffb0eed5f3515648f424f-light.svg) ![A usage-priced service grows with the workload from near zero. A provisioned instance stays flat, steps up between sizes and is not priced beyond its largest size.](https://docs.tensor9.com/images/cloud-adapter-early-access/diagrams/service-cost/687bd741bb3e2a761e6cf05fcd91458df083c150e17c1b49252bd3949cd871a5-dark.svg) A service billed per request approaches zero charges at low traffic. A provisioned database keeps charging for compute and disk while idle, so its curve stays flat until the workload needs the next instance size. A flat curve does not prove that the instance can serve every displayed rate. Planning models size a provisioned target from its throughput, retained data and memory needs, up to the largest instance size the provider documents for that service. Beyond that size the target is unpriced, and the result names the limit it exceeds, such as CPU, memory or disk. A target that scales out, such as a Kubernetes cluster, an object store or a sharded cache, adds identical nodes instead. These sizes are not benchmark calibrated. High-availability and zonal configurations have different charges and availability behavior. Where a curve includes both, compare those named scenarios rather than assuming equivalent resilience. If several adapters share a database, allocate that database's charges once across those workloads. An allocation of zero assumes spare capacity and still requires capacity validation. ## Read the cost curves Each service page and cost guide shows curves without entering usage or uploading a report. A curve varies one named workload dimension, such as message rate or stored data, and keeps the other assumptions fixed in its assumption table. * **Axes.** Workload and cost axes are logarithmic so several orders of magnitude stay readable. Equal distance means proportional growth; zero has a separate endpoint when present. * **Lines.** The dashed line is the origin service. Each colored line is a target configuration. Lines connect evaluated samples; intermediate points, break-even behavior and capacity are not inferred. * **Rows beside the chart.** One row per service gives its monthly charge and the difference at the named workload. * **Comparison label.** Costs More and Costs Less hold at every sampled point. Costs The Same means within the stated tolerance at every point. Costs Depend covers mixed results and unpriced samples. * **Tables.** The table under each curve lists the exact sampled charges and the target-minus-origin difference. Use it rather than the chart for comparisons. ## Estimate your own workload The curves and examples use reference workloads. The monthly cost calculator evaluates the same models with your inputs and returns the same line items, subtotals, qualifications and exclusions. Ask your Tensor9 contact or [hello@tensor9.com](mailto:hello@tensor9.com) for calculator access or for an estimate of your workload. The calculator accepts three kinds of input: * **Usage report.** For models that support it, upload an AWS Cost and Usage Report (CUR or CUR 2.0) as an uncompressed CSV file of at most 4 MiB. Tensor9 processes the report in memory and does not save it. Review the recognized meters, period, region and excluded rows, supply any missing meters, and confirm that the report covers a complete month for the selected service before applying it. * **Usage entered by hand.** Enter native monthly quantities, such as SQS request units or DynamoDB read and write request units. * **Charges entered by hand.** Enter monthly origin charges at list price. The model divides each charge by its reference rate to recover usage, so a discounted or credited total understates the workload. Then adjust the workload and deployment assumptions to match your application. Leave adapter hosting and Tensor9 fees blank when you do not know them, and enter 0 only when a cost is known to be zero. ### Review assumptions with a support agent Ask the agent to separate measured inputs from assumptions and show which changes affect the estimate most. For SQS, for example, message size, batch fill, empty receives and redelivery can change the relationship between application traffic and billed units. A lower modeled subtotal is a hypothesis to test against that workload. Provide a reviewed selection of usage and configuration evidence. A billing report can reveal account identifiers, resource names and business activity. Approval to use the calculator does not authorize sending its report to a model or sharing it with another participant. Use the input and processing controls in [Agents and Permissions](https://docs.tensor9.com/cloud-adapter-early-access/operations/agents.md). ### Validate the estimate against observed work Use [Tuning with Agents](https://docs.tensor9.com/cloud-adapter-early-access/tuning/agents.md) to define a bounded comparison before changing capacity or moving traffic. Record the model inputs and expected cost drivers, then measure completed work, correctness, retries, latency and native usage for the same workload. Compare the matching billing period and resource scope, and account for hosting, Tensor9 fees and other excluded costs separately. Keep estimate and observation labeled separately. A modeled instance size is not proof of achieved capacity, and a successful test is not a complete monthly invoice. If the result differs, investigate the assumptions and metered operations with the support agent before claiming savings. Use [Operations with Agents](https://docs.tensor9.com/cloud-adapter-early-access/operations/overview.md) for any resulting resource change, including its owner, spending approval, verification and recovery procedure. ## Read the qualifications Every result lists the statements that limit it. Read them before comparing totals. * **Rate snapshot**, **List prices read** or **Planning assumptions authored** gives the date of the rates: a provider rate snapshot, the date cited list prices were read, or the date authored estimates were written. Do not apply them to another region or service tier. * **Designed mapping** means the cost model describes an intended adapter. A price does not make that backend available. * **Native or deployment mapping** means the cost covers the selected service resources, not request-level operation coverage. * **Estimated allocation from planning assumptions; not benchmark calibrated** marks instance sizes chosen by a planning policy rather than measured capacity. * **Unpriced** means the workload exceeds a documented limit of the target, named in the result; the difference is then **Unavailable**. * **Unestimated components** lists allocations, such as adapter hosting and Tensor9 fees, that the total does not include. * **Cost scope** and **Excluded costs and workload features** state exactly which charges the subtotals cover. * A **benchmark plan** lists planned measurement cases. Planned cases are not completed measurements and do not qualify capacity. ## Worked examples Each example evaluates a published model's reference workload when this page is generated, so its figures change when the models or their rates change. ### DynamoDB on Firestore A DynamoDB Standard on-demand table serving point reads and plain item writes, with retained table data. Monthly AWS usage charges at the 2026-10-18 reference list rates in us-east-1, before free allowances, discounts, credits and tax. For this reference workload, DynamoDB service charges are USD 43.75 per month and Firestore service charges are USD 54.00 per month. Firestore costs USD 10.25 more per month. **Step 1: origin usage.** The example enters monthly origin charges at list price, and the model divides each charge by its reference rate to recover native usage: * DynamoDB on-demand reads: 12.5 USD/month * DynamoDB on-demand writes: 6.25 USD/month * DynamoDB Standard storage: 25 USD/month | Meter | Quantity | Unit | USD per unit | USD/month | | - | -: | - | -: | -: | | DynamoDB read units | 100,000,000 | ReadRequestUnits | 0.000000125 | 12.50 | | DynamoDB write units | 10,000,000 | WriteRequestUnits | 0.000000625 | 6.25 | | DynamoDB stored data | 100 | GB-Mo | 0.25 | 25.00 | **Step 2: physical work.** These workload assumptions translate the billing units into the work the target service meters: | Assumption | Value | Unit | | - | -: | - | | Representative DynamoDB item size | 1,024 | bytes | | Strongly consistent origin reads | 1 | 0 = eventual, 1 = strong | | Origin write-unit amplification | 1 | multiplier | | Additional document reads per write | 0 | reads/write | | Document writes per origin write | 1 | writes/write | | Firestore physical storage / source billed bytes | 1 | multiplier | Implied usage: * Inferred point reads: 100,000,000 calls/month * Inferred base item writes: 10,000,000 calls/month * Origin billed storage: 100 GiB-month **Step 3: target prices.** Each target meter is priced at the model's rates: | Meter | Quantity | Unit | USD per unit | USD/month | | - | -: | - | -: | -: | | Firestore document reads | 100,000,000 | document | 0.0000003 | 30.00 | | Firestore document writes | 10,000,000 | document | 0.0000009 | 9.00 | | Firestore physical storage | 100 | GiB-month | 0.15 | 15.00 | **Step 4: comparison.** | Monthly amount | USD | | - | -: | | DynamoDB service subtotal | 43.75 | | Firestore service subtotal | 54.00 | | Difference (target minus origin) | +10.25 | | Allocated adapter hosting | Not estimated | | Allocated Tensor9 fees | Not estimated | Across the Monthly cost by DynamoDB point-read rate curve, the difference for the target scenario (Firestore: point reads and blind writes) moves from USD -9.47 per month at 1 reads/s to USD +5311.70 per month at 10,000 reads/s. The [Amazon DynamoDB cost guide](https://docs.tensor9.com/cloud-adapter-early-access/costs/dynamodb.md) plots every backend across that range. Every published backend for DynamoDB, each at one sampled workload from its own cost curve: | Backend | Sampled workload | Price basis | Origin USD/month | Backend USD/month | Difference | Mapping | | - | - | - | -: | -: | -: | - | | Azure Cosmos DB (provisioned) | DynamoDB read units: 100 per second | Cited list prices, 2026-10-22 | 32.85 | 23.36 | -9.49 | Service adapter | | Azure Cosmos DB (serverless) | DynamoDB read units: 100 per second | Cited list prices, 2026-10-22 | 32.85 | 65.70 | +32.85 | Service adapter | | Cloud Bigtable | DynamoDB read units: 100 per second; one copy | Cited list prices, 2026-10-22 | 32.85 | 474.50 | +441.65 | Service adapter | | Cloud SQL for PostgreSQL | Read operations/s: 100 reads/s; HA | Reference rates, 2026-10-18 | 74.28 | 270.36 | +196.08 | Service adapter | | Cloud Spanner | DynamoDB read units: 100 per second; one copy | Cited list prices, 2026-10-22 | 32.85 | 65.70 | +32.85 | Service adapter | | Firestore | Read operations/s: 100 reads/s | Reference rates, 2026-10-18 | 74.28 | 117.49 | +43.22 | Service adapter | | OCI NoSQL Database | DynamoDB read units: 100 per second | Cited list prices, 2026-10-22 | 32.85 | 15.70 | -17.15 | Native or deployment | | PostgreSQL | DynamoDB read units: 100 per second; one copy | Cited list prices, 2026-10-22 | 32.85 | 80.90 | +48.05 | Service adapter | Qualifications for this example: * Firestore Standard edition, regional us-central1. One document read per origin point read; explicit reads/writes per write. * Plain unconditioned PutItem can use the blind write path; read-modify-write, conditions and retries increase document reads. * Equal physical storage is an illustrative assumption; tagged item envelopes, metadata and indexes can change billed bytes. Rates as of 2026-10-18. Model `dynamodb-firestore` version `2026-10-18.4`, scenario `dynamodb-firestore-reference`. ### SQS (Simple Queue Service, Classic) on Pub/Sub A Standard SQS queue whose messages are sent, received and deleted with the batch fills listed below. Monthly AWS usage charges at the 2026-10-18 reference list rates in us-east-1, before free allowances, discounts, credits and tax. For this reference workload, SQS (Simple Queue Service, Classic) service charges are USD 120.00 per month and Pub/Sub service charges are USD 7.92 per month. Pub/Sub costs USD 112.08 less per month. **Step 1: origin usage.** The example enters monthly origin charges at list price, and the model divides each charge by its reference rate to recover native usage: * Standard SQS requests: 120 USD/month | Meter | Quantity | Unit | USD per unit | USD/month | | - | -: | - | -: | -: | | Standard SQS billing units | 300,000,000 | Requests | 0.0000004 | 120.00 | **Step 2: physical work.** These workload assumptions translate the billing units into the work the target service meters: | Assumption | Value | Unit | | - | -: | - | | Representative SQS message size | 1,024 | bytes | | Origin send batch fill | 1 | messages/request | | Origin receive batch fill | 1 | messages/request | | Origin delete batch fill | 1 | messages/request | | Receive deliveries per original message | 1 | deliveries/message | | Empty receive requests per original message | 0 | requests/message | | Pub/Sub metadata and carrier overhead | 64 | bytes/message | | Target publish batch fill | 1 | messages/request | | Target delivery batch fill | 1 | messages/request | Implied usage: * Inferred original messages: 100,000,000 messages/month **Step 3: target prices.** Each target meter is priced at the model's rates: | Meter | Quantity | Unit | USD per unit | USD/month | | - | -: | - | -: | -: | | Pub/Sub published throughput | 0.098953 | TiB | 40 | 3.96 | | Pub/Sub delivered throughput | 0.098953 | TiB | 40 | 3.96 | **Step 4: comparison.** | Monthly amount | USD | | - | -: | | SQS (Simple Queue Service, Classic) service subtotal | 120.00 | | Pub/Sub service subtotal | 7.92 | | Difference (target minus origin) | -112.08 | | Allocated adapter hosting | Not estimated | | Allocated Tensor9 fees | Not estimated | Across the Monthly cost by SQS request rate curve, the difference for the target scenario (one subscription) moves from USD -0.98 per month at 1 requests/s to USD -29455.61 per month at 30,000 requests/s. The [Amazon SQS cost guide](https://docs.tensor9.com/cloud-adapter-early-access/costs/sqs.md) plots every backend across that range. Every published backend for SQS (Simple Queue Service, Classic), each at one sampled workload from its own cost curve: | Backend | Sampled workload | Price basis | Origin USD/month | Backend USD/month | Difference | Mapping | | - | - | - | -: | -: | -: | - | | Azure Cosmos DB (queue) | SQS request billing units: 100 per second | Cited list prices, 2026-10-22 | 105.12 | 70.08 | -35.04 | Service adapter | | Azure Queue Storage | SQS request billing units: 100 per second | Cited list prices, 2026-10-22 | 105.12 | 105.12 | +0.00 | Service adapter | | Azure Service Bus | SQS request billing units: 100 per second | Cited list prices, 2026-10-22 | 105.12 | 160.81 | +55.69 | Service adapter | | Cloud SQL for PostgreSQL | Average API requests/s: 100 requests/s; HA | Reference rates, 2026-10-18 | 105.12 | 236.36 | +131.24 | Service adapter | | OCI Queue | SQS request billing units: 100 per second | Cited list prices, 2026-10-22 | 105.12 | 57.60 | -47.52 | Service adapter | | PostgreSQL | SQS request billing units: 100 per second; one copy | Cited list prices, 2026-10-22 | 105.12 | 80.90 | -24.22 | Service adapter | | PostgreSQL Flexible Server | SQS request billing units: 100 per second; one copy | Cited list prices, 2026-10-22 | 105.12 | 141.44 | +36.32 | Service adapter | | Pub/Sub | API requests/s: 100 requests/s; one subscription | Reference rates, 2026-10-18 | 105.12 | 6.93 | -98.19 | Service adapter | | Scaleway Managed Database for PostgreSQL | SQS request billing units: 100 per second; one copy | Cited list prices, 2026-10-22 | 105.12 | 101.10 | -4.02 | Service adapter | | Scaleway Queues (SQS-compatible) | SQS request billing units: 100 per second | Cited list prices, 2026-10-22 | 105.12 | 0.94 | -104.18 | Service adapter | Qualifications for this example: * One pull subscription, Standard SQS semantics compatible with this mapping, representative message size and batching. * Pub/Sub publish and delivery each cost USD 40/TiB, with a 1,000-byte minimum per request. Metadata overhead is an explicit assumption. Rates as of 2026-10-18. Model `sqs-pubsub` version `2026-10-18.4`, scenario `sqs-pubsub-reference`. ### S3 on Cloud Storage An S3 Standard bucket with retained objects, ordinary PUT requests and ordinary GET requests. Monthly AWS usage charges at the 2026-10-18 reference list rates in us-east-1, before free allowances, discounts, credits and tax. For this reference workload, S3 service charges are USD 244.52 per month and Cloud Storage service charges are USD 213.80 per month. Cloud Storage costs USD 30.72 less per month. **Step 1: origin usage.** The example enters monthly origin charges at list price, and the model divides each charge by its reference rate to recover native usage: * S3 Standard storage: 235.52 USD/month * S3 PUT requests: 5 USD/month * S3 GET requests: 4 USD/month | Meter | Quantity | Unit | USD per unit | USD/month | | - | -: | - | -: | -: | | S3 Standard storage | 10,240 | GB-Mo | 0.023 | 235.52 | | S3 PUT requests | 1,000,000 | Requests | 0.000005 | 5.00 | | S3 GET requests | 10,000,000 | Requests | 0.0000004 | 4.00 | **Step 2: physical work.** These workload assumptions translate the billing units into the work the target service meters: | Assumption | Value | Unit | | - | -: | - | | Target retained bytes / source retained bytes | 1 | multiplier | | Additional GCS Class A operations per PUT | 0 | operations/PUT | | Additional GCS Class B operations per PUT | 0 | operations/PUT | | Additional GCS Class B operations per GET | 0 | operations/GET | Implied usage: * Origin retained data: 10,240 GiB-month * Inferred ordinary PUTs: 1,000,000 requests/month * Inferred ordinary GETs: 10,000,000 requests/month **Step 3: target prices.** Each target meter is priced at the model's rates: | Meter | Quantity | Unit | USD per unit | USD/month | | - | -: | - | -: | -: | | GCS Standard retained data | 10,240 | GiB-month | 0.02 | 204.80 | | GCS Class A operations | 1,000,000 | operation | 0.000005 | 5.00 | | GCS Class B operations | 10,000,000 | operation | 0.0000004 | 4.00 | **Step 4: comparison.** | Monthly amount | USD | | - | -: | | S3 service subtotal | 244.52 | | Cloud Storage service subtotal | 213.80 | | Difference (target minus origin) | -30.72 | | Allocated adapter hosting | Not estimated | | Allocated Tensor9 fees | Not estimated | Across the Monthly cost by retained S3 Standard data curve, the difference for the target scenario (Standard) moves from USD -0.03 per month at 10 GiB-month to USD -153.60 per month at 51,200 GiB-month. The [Amazon S3 cost guide](https://docs.tensor9.com/cloud-adapter-early-access/costs/s3.md) plots every backend across that range. Every published backend for S3, each at one sampled workload from its own cost curve: | Backend | Sampled workload | Price basis | Origin USD/month | Backend USD/month | Difference | Mapping | | - | - | - | -: | -: | -: | - | | Blob Storage | Stored data: 1,000 GiB-month | Cited list prices, 2026-10-22 | 23.00 | 20.80 | -2.20 | Service adapter | | Cloud Storage | Retained source data: 1,024 GiB-month; Standard | Reference rates, 2026-10-18 | 32.55 | 29.48 | -3.07 | Service adapter | | DigitalOcean Spaces | Stored data: 1,000 GiB-month | Cited list prices, 2026-10-22 | 23.00 | 20.00 | -3.00 | Service adapter | | MinIO Storage | Stored data: 1,000 GiB-month; one copy | Cited list prices, 2026-10-22 | 23.00 | 198.40 | +175.40 | Service adapter | | OCI Object Storage | Stored data: 1,000 GiB-month | Cited list prices, 2026-10-22 | 23.00 | 25.25 | +2.25 | Service adapter | | Scaleway Object Storage | Stored data: 1,000 GiB-month | Cited list prices, 2026-10-22 | 23.00 | 18.00 | -5.00 | Service adapter | Qualifications for this example: * S3 Standard first 50 TiB; GCS Standard regional bucket with flat namespace. Ordinary GET/PUT scenario only. * Zero additional operations is an idealized baseline. Conditional requests, multipart staging and compose/list/HEAD paths require explicit extra operations and retained-byte assumptions. Rates as of 2026-10-18. Model `s3-gcs` version `2026-10-18.4`, scenario `s3-gcs-reference`. ## Regions and currency The reference models compare AWS us-east-1 with Google Cloud us-central1, with the application running alongside the target services. Planning models cover other origin services, backend choices and cloud directions. A planning model with cited prices names the region those prices apply to; otherwise its region label identifies an authored scenario assumption rather than verified regional pricing. Each result names its own regions, currency, version, rate date and pricing sources. ## Cost models by origin service * [Amazon SQS](https://docs.tensor9.com/cloud-adapter-early-access/costs/sqs.md): Compare message traffic, batching, payload size and resident backlog with estimated database allocations. Cloud SQL CPU, memory and disk grow under an explicit planning policy; zonal and high-availability choices change its price. * [Amazon DynamoDB](https://docs.tensor9.com/cloud-adapter-early-access/costs/dynamodb.md): Read/write mix, item size, consistency, index amplification and retained data determine the comparison. A database configuration price does not establish its supported point-operation throughput. * [Amazon S3](https://docs.tensor9.com/cloud-adapter-early-access/costs/s3.md): Stored data and request traffic are separate dimensions. Retention, operation classes and extra physical copies can change the target bill. * [Amazon Kinesis](https://docs.tensor9.com/cloud-adapter-early-access/costs/kinesis.md): Record size, ingest rate, fan-out and retention affect the comparison. Provisioned and usage-based services can charge for different units. * [Amazon RDS](https://docs.tensor9.com/cloud-adapter-early-access/costs/rds.md): Compare database configurations, storage and availability choices. Matching a price or a vCPU count does not establish equivalent database performance. * [Additional services](https://docs.tensor9.com/cloud-adapter-early-access/costs/additional-services.md): consolidated planning models for configuration, secrets, keys, functions, workflows, infrastructure and other origin services, with backend choices grouped together. Each service page in the [service catalog](https://docs.tensor9.com/cloud-adapter-early-access/service-catalog/aws/catalog.md) has a Costs section summarizing its backends. A cost model covers only its named direction and workload; availability of an adapter does not imply that a cost model exists for it. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.