Skip to main content
Tensor9 BYOC can preserve the service API your application calls while changing the services that supply it. The resulting bill follows the target service’s meters and configuration. A single multiplier on an origin bill cannot describe every workload. The articles below show cost curves immediately. You do not need to enter usage or upload a report. Each curve names its workload dimension, sampled scale points, backend configurations, rate snapshot and exclusions.

Start with the workload

A queue workload needs a message rate, payload size, send/receive/delete mix, batch fill and retry behavior. A key-value workload also needs read/write mix, item size, consistency and index amplification. Object and stream workloads add retained data, operation classes, retention and fan-out. The curves vary a named dimension while keeping the listed assumptions explicit.

Separate usage charges from provisioned capacity

A service billed per request can approach zero service charges at low traffic. A provisioned database can continue charging for compute and disk while idle. Its curve can remain flat across a workload range because the selected configuration stays fixed. That shape does not prove that the database can serve every displayed rate. For SQS on Cloud SQL, a provisional planning policy estimates larger CPU, memory and disk allocations as lifecycle throughput, peak traffic and resident backlog increase. Those charts show discrete estimated allocations rather than joining unknown tier transitions. The policy is not benchmark calibrated. A workload beyond its configuration range retains the origin price and leaves the target unpriced. Other models can show explicit configuration pricing; read each curve’s assumptions to distinguish these cases. 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 price scope

Reference-tariff models price the modeled native usage using their named rate snapshot. Models labeled Planning estimate with editable assumptions use educated guesses for rates, workload amplification and capacity. Verify those assumptions against provider prices and benchmarks before relying on a comparison. Neither basis predicts your invoice. Free allowances, negotiated discounts, credits, tax and migration charges can make an origin bill differ. Use native usage quantities when comparing those bills; do not infer usage from a discounted total. Target lines cover only the service meters and configurations listed beside each curve. Adapter hosting and Tensor9 commercial fees require separate allocations and remain unestimated when unspecified. Network transfer, backups, encryption charges, application compute and operational labor may also be outside the displayed scope. The adjacent exclusion list states each model’s limits.

Compare samples, then qualify the deployment

Reference charts use logarithmic scales for positive workload and cost values so several orders of magnitude remain readable. Equal distance on a logarithmic axis means proportional growth; zero has a separate endpoint when present. Read the labeled ticks and exact table values when comparing charges. The tables show exact sampled monthly charges and target-minus-origin differences. A positive difference means the selected target service costs more. Connected samples show the cost trend; intermediate points, break-even behavior and operating capacity require evaluation. Validate representative latency, concurrency, sustained throughput and retained data before choosing a configuration. The initial reference models compare AWS us-east-1 with Google Cloud us-central1, with the application running alongside the target services. Additional planning models cover other origin services, backend choices and cloud directions. Their region labels identify authored scenario assumptions rather than verified regional tariffs. Each curve retains its own region, currency, version, rate date and pricing-source links. Do not apply those rates to a different region or service tier without a corresponding model.

Cost models by origin service

  • Amazon SQS: 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: 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: Stored data and request traffic are separate dimensions. Retention, operation classes and extra physical copies can change the target bill.
  • Amazon Kinesis: Record size, ingest rate, fan-out and retention affect the comparison. Provisioned and usage-based services can charge for different units.
  • Amazon RDS: Compare database configurations, storage and availability choices. Matching a price or a vCPU count does not establish equivalent database performance.
  • Additional services: consolidated planning models for configuration, secrets, keys, functions, workflows, infrastructure and other origin services, with backend choices grouped together.
The service catalog describes operation coverage and backend limitations. A cost model covers only its named direction and workload; availability of an adapter does not imply that a cost model exists for it.