Skip to main content
This page covers both halves of DynamoDB: the item APIs, and the table administration that creates and configures the tables those items live in, under Table administration. They are adapted separately, so support for one does not imply support for the other. On this page

​
Coverage by target cloud

​
How the backends compare

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

​
Max adaptation

​
Infrastructure-only adaptation

​
On Google Cloud

​
Via Firestore

​
How it works

Your application keeps its AWS SDK and code. Tensor9 runs a DynamoDB adapter beside it in the customer’s environment and sets AWS_ENDPOINT_URL_DYNAMODB, so the SDK sends its requests to the adapter over the local network. The adapter accepts DynamoDB requests and data types, returns DynamoDB responses and errors, and stores the data in Google Cloud Firestore. Items, conditions, indexes and transactions map to Firestore documents and operations. Three differences matter most: numbers must fit Firestore’s native number types, every read is strongly consistent, and writes that need the current item first add a read and can meet contention.
Before: on AWS, the application's DynamoDB SDK calls Amazon DynamoDB. After: on Google Cloud, the same application and SDK call a Tensor9 adapter, which stores the data in Firestore.Before: on AWS, the application's DynamoDB SDK calls Amazon DynamoDB. After: on Google Cloud, the same application and SDK call a Tensor9 adapter, which stores the data in Firestore.

Your application keeps its DynamoDB SDK; an adapter in the customer environment stores the data in Firestore.

​
Architecture

The adapter parses DynamoDB requests and expressions, runs the matching Firestore operations and returns DynamoDB responses. It authenticates to Firestore with the customer’s workload identity, using short-lived tokens rather than a stored key. All item and table data lives in Firestore, so an adapter instance can restart without recovering anything locally. A table with DynamoDB Streams enabled still needs a single writing instance. There is no Firestore collection or capacity to provision per table. Every DynamoDB table lives in one Firestore collection named ddb. Each item is a document whose ID combines the table name and the item’s key (for example orders|u#42), with fields recording its table and partition. A registry document in the same collection holds the table definitions, so a table your application creates at run time needs no Firestore setup. Each declared secondary index is a Firestore composite index over the item’s own fields.
Your app's DynamoDB SDK calls the Tensor9 adapter, which keeps no data of its own. Firestore holds every table's items as documents in one collection named ddb, and Firestore composite indexes over the item fields serve the secondary indexes.Your app's DynamoDB SDK calls the Tensor9 adapter, which keeps no data of its own. Firestore holds every table's items as documents in one collection named ddb, and Firestore composite indexes over the item fields serve the secondary indexes.

The adapter keeps no data; every table’s items live as documents in one Firestore collection, ddb.

​
Item types and numbers

Each attribute is stored as a map with one DynamoDB type tag: strings as {"S": …}, numbers as {"N": …}, binary as {"B": …}, and sets, lists, maps, booleans and null with their own tags. The value inside is a native Firestore value, so a number stays distinct from a string that looks like a number, and Firestore can filter and index fields such as item.total.N. Numbers have a limit. Signed 64-bit integers are stored exactly, as Firestore integers. Other numbers are accepted only if they fit within 15 significant digits, and are stored as doubles. A DynamoDB number outside that range is rejected before it is stored rather than rounded. Beside the item map, each document also holds fields the adapter manages: id, _pk, _tbl, _okey and _keyAttrs.
A DynamoDB item is stored in a Firestore document. Each attribute keeps its DynamoDB type tag around a native Firestore value. Integers stay exact; other numbers are checked for precision before they are stored as doubles.A DynamoDB item is stored in a Firestore document. Each attribute keeps its DynamoDB type tag around a native Firestore value. Integers stay exact; other numbers are checked for precision before they are stored as doubles.

Each attribute keeps its DynamoDB type tag around a native Firestore value, so filters and indexes can run in Firestore.

​
Tables

Firestore is serverless: there is no account tier, throughput mode or capacity to size. Every DynamoDB table you declare goes into the same ddb collection, and documents are kept apart by table-prefixed IDs and a table field. Firestore shards documents automatically and bills for operations and stored data, so an idle table still costs storage. CreateTable, UpdateTable and DeleteTable change only the registry document, and DescribeTable and ListTables read it; none of them calls Firestore’s admin API. DeleteTable removes the table with one metadata write: its documents disappear from the application at once but stay stored until a later deletion of a table with the same name cleans them up in bounded batches. A table re-created under the same name starts empty, under a new internal name such as orders#2.
  • The key schema must be known. It comes from a declared table, the registry or the first request that includes the key. A PutItem whose key schema cannot be resolved is rejected, never written under a guessed key.
  • Tables are separated by name, not by database. All tables share the project’s one Firestore database, which other Firestore-backed apps in the project also use. A GetItem or base Query reads only its table’s documents by ID prefix; a Scan filters on the table field. A dedicated database or database-scoped identity per install is not provided.
Every table lives in one Firestore collection named ddb, told apart by a table field. Firestore is serverless: there is no throughput mode to choose and no capacity to size, documents are sharded automatically, and billing follows operations and storage.Every table lives in one Firestore collection named ddb, told apart by a table field. Firestore is serverless: there is no throughput mode to choose and no capacity to size, documents are sharded automatically, and billing follows operations and storage.

Every table shares the ddb collection; Firestore has no throughput mode or capacity to size.

​
Conditional writes

A conditional write reads the document and its updateTime, evaluates your DynamoDB condition in the adapter, and writes only if the document has not changed since. Creating an item uses a does-not-exist precondition instead. A false condition returns ConditionalCheckFailed. A concurrent change returns a retryable conflict, which your SDK retries with its own backoff; the adapter does not loop. The read adds latency and a billed read operation even without contention. On a heavily contended document, retries can keep colliding, and once the SDK’s retry budget runs out your application sees a throttling error. Read-then-write updates are computed in the adapter and written with a version check, so they stay atomic when another writer races. Which writes skip the read? Firestore supports masked field updates and atomic increments, but the adapter uses a narrower set:
  • PutItem and DeleteItem: one direct document write when there is no condition, ReturnValues=NONE and DynamoDB Streams is off.
  • UpdateItem with only top-level REMOVE actions: one masked document write under the same conditions, provided the update does not touch the configured TTL attribute.
  • Everything else, including SET: read, then write. A SET cannot check DynamoDB’s 400-KiB item limit without the current item. Arithmetic, nested updates, returned attributes and TTL changes also read first, and Firestore’s native increment is not used for numeric updates.
Relaxing the size check. Setting FIRESTORE_ALLOW_OVERSIZED_BLIND_UPDATES to "true" in the adapter configuration lets top-level SET and REMOVE updates skip the read under the same conditions: no condition, no returned values, Streams off and no TTL change. Primary-key and secondary-index-key changes, and tables with a local secondary index, still read first. The default is "false". The option skips only the 400-KiB check on the resulting item. Firestore’s own 1-MiB document limit still applies and includes the adapter’s type tags and fields, so it is not a 1-MiB DynamoDB item allowance. PutItem, read-then-write updates and transactions keep their checks, so an item grown past 400 KiB may need a large attribute removed or replaced before those writes succeed. This option has not been benchmarked.
A conditional write reads the current document and its update time, evaluates the DynamoDB condition in the adapter, then writes only if the document is unchanged. A write that loses a race returns a retryable conflict, not a condition failure.A conditional write reads the current document and its update time, evaluates the DynamoDB condition in the adapter, then writes only if the document is unchanged. A write that loses a race returns a retryable conflict, not a condition failure.

A false condition and a concurrent change to the document return different errors.

​
Secondary indexes

Each declared global secondary index is a pair of Firestore composite indexes, ascending and descending, over the table field, the index’s hash attribute, its optional range attribute and the document ID. There is no separate copy of the item. Firestore updates the index with the item write: a changed key moves the item, a deleted item leaves the index, and an item without the hash or range attribute is not in the index, as on DynamoDB. Index reads are therefore stronger than on DynamoDB, whose GSIs are eventually consistent: a query sees the write that just completed. Key conditions, ordering, cursor, limit and supported filters run in Firestore; other filters run in the adapter over that bounded result. Numbers compare numerically, and the document ID breaks ties, so pagination is exact when items share a range value. Indexes must be declared when your stack is compiled; querying an undeclared index returns a validation error rather than scanning the table.
A base write stores the item's fields. Firestore updates composite indexes over those fields with the write, so a GSI query runs its key conditions, order, cursor and limit in Firestore.A base write stores the item's fields. Firestore updates composite indexes over those fields with the write, so a GSI query runs its key conditions, order, cursor and limit in Firestore.

Each declared GSI is a Firestore composite index over the item’s own fields, and the query runs in Firestore.

​
Transactions

TransactWriteItems runs as a Firestore read-write transaction. The adapter reads each target document inside the transaction, evaluates each DynamoDB condition itself, and commits all the writes atomically. If any condition fails, nothing is written. If the commit loses a race with another writer, the SDK retries it as a temporary conflict. A transaction can span documents, tables and partition keys, up to DynamoDB’s 100-action limit. A cancelled transaction returns a single condition-failure error without per-item CancellationReasons, so your application cannot tell which condition failed.
A TransactWriteItems whose items span two different partition keys commits as one atomic Firestore transaction across documents; both the debit and credit commit, or neither does.A TransactWriteItems whose items span two different partition keys commits as one atomic Firestore transaction across documents; both the debit and credit commit, or neither does.

TransactWriteItems runs as one Firestore transaction across documents: the debit and credit both commit, or neither does.

​
Limitations

  • Numbers beyond 15 significant digits are not supported. Signed 64-bit integers are stored exactly. Other numbers must fit within 15 significant digits; a number outside that range is rejected, not rounded.
  • Frequent writes to one document behave differently: they can conflict. Repeated updates to the same document can hit version conflicts or throttling. SDK retries add latency and billed operations, and a finite retry budget can surface an error. Test with your real key distribution.
  • Most updates behave differently: they read the item first. By default SET reads the item to enforce the 400-KiB limit, as do conditions, arithmetic, nested updates and returned attributes; only eligible REMOVE-only updates write directly. FIRESTORE_ALLOW_OVERSIZED_BLIND_UPDATES extends direct writes to eligible SET and REMOVE updates but relaxes the size check.
  • A separate database per table or install is not supported. All tables share the project’s one Firestore database and are kept apart by document ID and a table field, not by a dedicated database or a database-scoped identity.
  • You must declare secondary indexes at compile time. They come from the global_secondary_index blocks on your aws_dynamodb_table; adding one means editing your Terraform and releasing again. CreateTable may name only the compiled indexes, UpdateTable cannot add one, and querying an index that was not declared at compile time returns a validation error.
  • Strongly consistent reads on a global secondary index are not supported. ConsistentRead=true on a GSI is rejected, as on DynamoDB; ConsistentRead=false is accepted. Local secondary indexes accept strong reads, and GSI updates are still synchronous.
  • Reads behave differently: they are always strongly consistent. A single-document read reflects the latest committed write whatever ConsistentRead says. Estimate Firestore document and index-entry read charges for your actual queries.
  • Some filters behave differently: they run in the adapter. Equality, bounded IN and type checks run in Firestore. <>, attribute_not_exists, contains, begins_with, NOT and filters whose Firestore order would conflict with DynamoDB key order run in the adapter over the bounded result; begins_with on a GSI sort key still runs in Firestore.
  • You must run one writer per table with Streams enabled. Stream records are saved in order, in the same transaction as each change. A second instance writing to that table gets a retryable throttling error until the first instance’s lease expires. Tables without a stream accept concurrent writers, and reads are unaffected.
  • Deleted-table storage behaves differently: it is cleaned up later. DeleteTable hides the table’s documents at once, but they stay stored until a later deletion of a table with the same name removes them in bounded batches. A large deleted table can keep costing storage.
  • Per-item transaction cancellation reasons are not supported. A cancelled TransactWriteItems returns one condition-failure error instead of CancellationReasons, so your application cannot tell which item’s condition failed.

​
Other considerations

  • Moving data. The Firestore store starts empty. Move existing DynamoDB data by export and import, backfill or dual writes, and validate it before switching traffic.
  • Operations and ownership. Google operates Firestore and Tensor9 operates the adapter, which uses workload identity and short-lived credentials. The customer manages the Google Cloud project, cluster maintenance and monitoring.
  • Capacity and cost. Firestore bills operations and storage, with no provisioned throughput. Estimate charges from the documents and index entries your queries examine, counting every read as strongly consistent, and test contention on frequently updated documents.
  • Change streams. DynamoDB Streams work through the Streams API with all four view types. Records are kept for a fixed window.

​
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 cost by DynamoDB point-read rate
Reference monthly service charges by Read operations/s. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
Monthly cost by DynamoDB point-read rate: monthly service charges by Read operations/s. Exact values are in the following table.Monthly cost by DynamoDB point-read rate: monthly service charges by Read operations/s. Exact values are in the following table.
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
  • Strong 1 KiB point reads and plain writes; one write per ten reads, no origin index amplification. 730 hours/month; retained source data stays at 100 GiB. Firestore uses one document per item, blind writes, no extra reads and equal billed storage; this is an illustrative storage assumption.
  • 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.
  • 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.
  • Source usage is priced at reference rates; source lines are not actual invoice charges. Free or discounted usage still consumes target resources.
  • AWS DynamoDB Standard on-demand pricing: https://aws.amazon.com/dynamodb/pricing/
  • Firestore Standard regional pricing: https://cloud.google.com/firestore/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.
  • Queries, scans and index-entry reads, transactions, Streams, document deletes/TTL and unsupported item domains.
Rate snapshot: 2026-10-18. Model: dynamodb-firestore / 2026-10-18.4. Curve: read-rate. Sources: AWS DynamoDB Standard on-demand pricing, Firestore Standard regional pricing.
Monthly cost by retained DynamoDB data
Reference monthly service charges by Retained source data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
Monthly cost by retained DynamoDB data: monthly service charges by Retained source data. Exact values are in the following table.Monthly cost by retained DynamoDB data: monthly service charges by Retained source data. Exact values are in the following table.
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
  • Source traffic stays at 100 million strong 1 KiB read units and 10 million plain write units/month, with no origin index amplification. Firestore assumes equal billed storage, one document per item and blind writes; physical expansion and indexing require separate qualification.
  • 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.
  • 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.
  • Source usage is priced at reference rates; source lines are not actual invoice charges. Free or discounted usage still consumes target resources.
  • AWS DynamoDB Standard on-demand pricing: https://aws.amazon.com/dynamodb/pricing/
  • Firestore Standard regional pricing: https://cloud.google.com/firestore/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.
  • Queries, scans and index-entry reads, transactions, Streams, document deletes/TTL and unsupported item domains.
Rate snapshot: 2026-10-18. Model: dynamodb-firestore / 2026-10-18.4. Curve: retained-data. Sources: AWS DynamoDB Standard on-demand pricing, Firestore Standard regional pricing. DynamoDB → Firestore: 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.
  • Queries, scans and index-entry reads, transactions, Streams, document deletes/TTL and unsupported item domains.
Scenario assumptions
  • Inferred point reads: 100,000,000 calls/month.
  • Inferred base item writes: 10,000,000 calls/month.
  • Origin billed storage: 100 GiB-month.
  • 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.
Rate snapshot: 2026-10-18. Model: dynamodb-firestore / 2026-10-18.4. Scenario: dynamodb-firestore-reference. Sources: AWS DynamoDB Standard on-demand pricing, Firestore Standard regional pricing.

​
Via Cloud Spanner

​
What the adapter adds

Those two rows are not the whole read. The measured 5.377 ms GetItem also spends about 1.24 ms (23%) on HTTP framing, the driver and the loopback hop, which exists because the call now goes to an adapter rather than straight out. Translating the call is nearly free; reaching the adapter is not free, and the backing store’s round trip and commit are larger than both. Size a workload against Spanner’s behaviour first, and count one local hop.

​
How it works

Your application keeps its AWS SDK, endpoint configuration and DynamoDB item formats. The Tensor9 adapter accepts DynamoDB requests, returns DynamoDB responses and errors, and stores the data in Spanner. The adapter turns a Query’s key condition, filter, ordering and limit into one GoogleSQL statement, and Spanner runs it. A selective key range keeps the work small. A filter can still examine rows it does not return, so the compute a query uses depends on more than the size of its result.
Before: on AWS your application's DynamoDB SDK calls Amazon DynamoDB. After: on Google Cloud the same application and SDK call a Tensor9 adapter, which stores the data in Google Cloud Spanner.Before: on AWS your application's DynamoDB SDK calls Amazon DynamoDB. After: on Google Cloud the same application and SDK call a Tensor9 adapter, which stores the data in Google Cloud Spanner.

Your application keeps calling the DynamoDB JSON API. The adapter turns each call into GoogleSQL for Spanner.

​
Architecture

How a request is carried out: the adapter checks each DynamoDB request and turns it into Spanner work. A read runs as one GoogleSQL statement and a write commits as Spanner mutations. Spanner holds one database with one table per DynamoDB table and a secondary index per declared index.How a request is carried out: the adapter checks each DynamoDB request and turns it into Spanner work. A read runs as one GoogleSQL statement and a write commits as Spanner mutations. Spanner holds one database with one table per DynamoDB table and a secondary index per declared index.

Spanner runs each query’s key condition, filter, ordering and limit itself, as one SQL statement.

​
Rows and keys

Each DynamoDB table becomes a Spanner table. An item is one row, keyed first by its partition key and then by its sort key. Spanner can therefore read a key range in order, and ScanIndexForward and paging work through the key. Attribute values keep their DynamoDB types. Numbers keep their full decimal precision, binary stays binary, and strings and sets keep the distinctions the API requires. The adapter stores numbers as decimal text that sorts correctly and stores sets in a consistent order. Spanner can then evaluate supported comparisons in GoogleSQL without converting numbers to floating point. A local secondary index is interleaved with its table, so its entries are stored next to the row they describe. If a table declares a TTL attribute, a generated column holds the expiry time and a Spanner row-deletion policy deletes expired rows. Expired items are physically deleted on Spanner’s schedule; the adapter does not hide them on read.
A DynamoDB item becomes a Spanner row whose primary key is the partition key then the sort key, so a Query over a key range reads one contiguous range of rows.A DynamoDB item becomes a Spanner row whose primary key is the partition key then the sort key, so a Query over a key range reads one contiguous range of rows.

Partition and sort keys form the Spanner primary key, which supports ordered range reads.

​
Transactions and consistency

TransactWriteItems runs as one Spanner read-write transaction, across tables and partition keys. Spanner’s external consistency also orders transactions in real time. The adapter enforces DynamoDB’s 100-action limit, one operation per item and the ClientRequestToken idempotency window. The adapter reads and locks the items whose conditions or changes need their current values, checks the conditions, then commits. A failed condition and a conflict with another transaction return different errors, so the client can decide whether to retry. If the request asks for the failed item, it comes back with the condition error. An unconditional Put can skip reading the item because it supplies the whole replacement. Conditions, returned old values, updates computed from existing attributes and the size check on a delete all need the existing item to be read. DynamoDB’s limits apply, not Spanner’s. Each resulting item must fit DynamoDB’s 400 KiB item limit, and the whole transaction must fit DynamoDB’s 4 MiB limit on total item data. A request over either limit fails the way it fails on AWS. Normal reads are strongly consistent, including requests with ConsistentRead=false; that flag does not select a cheaper or faster read. Strongly consistent reads on a global secondary index are still rejected, as on DynamoDB.
One TransactWriteItems becomes one Spanner transaction. Conditional actions read the current items before their conditions are checked; an unconditional put can skip the read. All writes commit together.One TransactWriteItems becomes one Spanner transaction. Conditional actions read the current items before their conditions are checked; an unconditional put can skip the read. All writes commit together.

Transactions can span tables and partition keys. External consistency preserves transaction order in real time.

​
Secondary indexes

A global secondary index becomes a Spanner secondary index, and a local secondary index becomes an index interleaved with its table. A Query on either looks up the index; it does not scan the table. Spanner updates the index in the same commit as the row, so the next strongly consistent index read includes the change. On DynamoDB a GSI catches up asynchronously; an application that already tolerates that delay needs no change here. Because the index is a real Spanner index, Spanner applies the key condition, ordering, paging and limit while it reads the index. A selective index query reads close to what it returns instead of filtering a wider read afterwards. An item missing the index’s key attribute has no index entry, as in DynamoDB’s sparse indexes. Two DynamoDB rules still apply. ConsistentRead=true on a global secondary index is rejected, as DynamoDB rejects it. A query that asks for attributes the index does not include is rejected, instead of fetching them from the table. These return the same errors as on AWS, so code that handles them there works unchanged.
Spanner updates the row and secondary index in one transaction. A subsequent strong index read includes the committed update.Spanner updates the row and secondary index in one transaction. A subsequent strong index read includes the committed update.

Spanner commits row and index updates together. A subsequent strong index read includes the update.

​
Limitations

Where DynamoDB and Spanner differ
  • Cost behaves differently: provisioned compute bills through quiet periods. Both services charge for stored data; Spanner also charges for provisioned compute. Steady use can spread that cost, but any saving depends on workload, capacity, region and replication topology.
  • Hot items behave differently: one busy item still contends. The adapter spreads independent keys by hashing their partition keys, but repeated updates to one item still compete. A benchmark with evenly spread keys says nothing about hot-item performance.
  • Full-item reads from a partial index are not supported. Select=ALL_ATTRIBUTES on a global secondary index that does not include every attribute is rejected, instead of fetching the missing attributes from the table. The error names the index: query only the attributes it has, or declare it with all of them.
  • Scan behaves differently: it uses provisioned compute. Paging limits the response size, but a broad scan still reads the table and competes with point reads and writes. Use a selective Query where you can.
  • DynamoDB Streams are not supported. Writes to a stream-enabled table are rejected. Use another backend if the application needs a DynamoDB change log saved atomically with each write.
  • Some updates behave differently: they read the item first. Conditions, responses that need the existing item, nested updates, arithmetic, changes to secondary-index keys and updates to tables with an LSI read the item, check and compute the change, then commit it in the same Spanner transaction. A transaction conflict can repeat that work. Eligible top-level SET and REMOVE updates skip the read, including UPDATED_NEW responses that follow from the assigned values.
  • Latency behaves differently by request type. The 2026-08-31 run measured simple unconditional updates, not the extra read or conflict retries of read-then-write updates. It used 1,000 processing units in us-west1, 100,000 records and a 50/50 read/update workload. With 16 worker threads, steady median throughput was 2,403.0 operations/s through Spanner and 5,929.5 on native DynamoDB in us-west-2, over three 200,000-operation repetitions after warm-up. Spanner returned strong reads and DynamoDB eventual reads. The adapter-only run left out appliance authorization and control-plane logging. These are end-to-end results with different regions and consistency, not the adapter’s own overhead, and they do not measure transactions or hot-item contention.

​
Other considerations

  • Moving from AWS. The Spanner database starts empty, and existing DynamoDB items are not moved for you. Load them through the adapter’s DynamoDB API, then validate the data and representative queries before switching application traffic. For an online migration, coordinate the backfill with ongoing writes so changes made during the copy reach Spanner before cutover.
  • Capacity planning. Size Spanner compute in processing units. Start from the read and write rates the DynamoDB table was provisioned for, not its storage size, and expect to tune under real load. Throughput per unit depends heavily on how evenly the primary key spreads.
  • Who runs what. Google operates Spanner, including replication, backups and failover. Tensor9 operates the adapter, which runs beside your application.
  • Authentication. The adapter connects to Spanner with the workload’s own identity through GKE Workload Identity. There is no key file and no secret to rotate.

​
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.
DynamoDB · DynamoDB read units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB read units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.
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
  • Writes and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Spanner bills compute capacity in processing units (100 PU minimum and steps, 1,000 PU per node) whose price includes the three replicas of a regional configuration, plus SSD storage including all replicas. Capacity is sized from planning-peak reads and writes against Google’s per-node throughput; replication is built in, so the standby selection adds no copy. Enterprise (USD 1.23) and Enterprise Plus (1.71 per node-hour) editions, dual- and multi-region configurations and per-node storage limits are not selected.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • Spanner pricing: https://cloud.google.com/spanner/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.
  • 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-610b516e23e900c58eeb455757b30a011c363c10 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Spanner pricing.
DynamoDB · DynamoDB write units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB write units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.
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
  • Reads and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Spanner bills compute capacity in processing units (100 PU minimum and steps, 1,000 PU per node) whose price includes the three replicas of a regional configuration, plus SSD storage including all replicas. Capacity is sized from planning-peak reads and writes against Google’s per-node throughput; replication is built in, so the standby selection adds no copy. Enterprise (USD 1.23) and Enterprise Plus (1.71 per node-hour) editions, dual- and multi-region configurations and per-node storage limits are not selected.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • Spanner pricing: https://cloud.google.com/spanner/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.
  • 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-610b516e23e900c58eeb455757b30a011c363c10 / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Spanner pricing.
DynamoDB · Stored data
Feature: DynamoDB. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.
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
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Spanner bills compute capacity in processing units (100 PU minimum and steps, 1,000 PU per node) whose price includes the three replicas of a regional configuration, plus SSD storage including all replicas. Capacity is sized from planning-peak reads and writes against Google’s per-node throughput; replication is built in, so the standby selection adds no copy. Enterprise (USD 1.23) and Enterprise Plus (1.71 per node-hour) editions, dual- and multi-region configurations and per-node storage limits are not selected.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • Spanner pricing: https://cloud.google.com/spanner/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.
  • 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-610b516e23e900c58eeb455757b30a011c363c10 / 2026-10-22.planning.2. Curve: workload-3. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Spanner pricing. DynamoDB → Cloud Spanner: 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. 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.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Spanner bills compute capacity in processing units (100 PU minimum and steps, 1,000 PU per node) whose price includes the three replicas of a regional configuration, plus SSD storage including all replicas. Capacity is sized from planning-peak reads and writes against Google’s per-node throughput; replication is built in, so the standby selection adds no copy. Enterprise (USD 1.23) and Enterprise Plus (1.71 per node-hour) editions, dual- and multi-region configurations and per-node storage limits are not selected.
List prices read: 2026-10-22. Model: plan-610b516e23e900c58eeb455757b30a011c363c10 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Spanner pricing.

​
Via Cloud Bigtable

​
How it works

Tensor9 runs a DynamoDB adapter beside your application in the customer’s environment and sets AWS_ENDPOINT_URL_DYNAMODB so the AWS SDK sends its requests to the adapter over the local network. Your SDK and code stay the same. The adapter accepts DynamoDB requests and data types, returns DynamoDB responses and errors, and stores the data in Google Cloud Bigtable. It connects to Bigtable over pooled gRPC with the workload identity, so no key file is needed. Bigtable writes are atomic for one row, not across rows, and each DynamoDB item is exactly one row. That is why single-item writes, including conditional ones, behave as on DynamoDB, and why multi-item transactions, secondary indexes, DynamoDB Streams and per-item TTL are rejected. The limitations below list what is missing.
On AWS, your application's DynamoDB SDK calls Amazon DynamoDB. On Google Cloud, the same application and SDK call a Tensor9 adapter, which answers the DynamoDB API and stores the data in Cloud Bigtable.On AWS, your application's DynamoDB SDK calls Amazon DynamoDB. On Google Cloud, the same application and SDK call a Tensor9 adapter, which answers the DynamoDB API and stores the data in Cloud Bigtable.

Your application keeps using the DynamoDB API; an adapter in the customer environment stores the data in Bigtable.

​
Architecture

The adapter translates DynamoDB keys and operations into Bigtable row keys, row ranges and mutations. Base-table queries become ordered key ranges. DynamoDB attribute filters run in the adapter over the rows it read. A conditional write reads the item, evaluates the DynamoDB condition and uses CheckAndMutateRow to write only if the item has not changed since it was read. If another writer changed it, the adapter reads and checks the condition again.
The adapter turns each DynamoDB request into Bigtable calls: one ReadRows range for a read, or a MutateRow or CheckAndMutateRow for a write. Bigtable stores one row per item and is atomic for one row, not across rows.The adapter turns each DynamoDB request into Bigtable calls: one ReadRows range for a read, or a MutateRow or CheckAndMutateRow for a write. Bigtable stores one row per item and is atomic for one row, not across rows.

Each DynamoDB request becomes one Bigtable row-range read or one row mutation.

​
One row per item

All your DynamoDB tables live in one Bigtable table that you provision, and each item is one row in it. A metadata row records each DynamoDB table’s schema, so the tables stay separate inside the shared Bigtable table. The row key is laid out as the DynamoDB table, then the partition, then the sort key encoded in DynamoDB’s own order, then an item digest. A table that is deleted and re-created gets a new key prefix, so it starts empty and cannot read the old table’s rows. Because the sort key keeps DynamoDB’s order, one partition is one contiguous Bigtable range, and a Query over a key range is a range read in the right order rather than a filter over unrelated rows. Item data is stored in a plain column family, d. A second family, n, is an INT64 SUM aggregate, so Bigtable itself can add to an integer counter in one round trip instead of the adapter reading, adding and writing back. See the next section.
Each DynamoDB item is one Bigtable row. Its row key is the table, the partition, the sort key in DynamoDB order and an item digest, so one DynamoDB partition is one contiguous Bigtable range in sort-key order.Each DynamoDB item is one Bigtable row. Its row key is the table, the partition, the sort key in DynamoDB order and an item digest, so one DynamoDB partition is one contiguous Bigtable range in sort-key order.

The row key is built so a DynamoDB partition is one contiguous Bigtable range, in the origin’s sort order.

​
Writes and atomicity

An unconditional PutItem or DeleteItem, and an UpdateItem with only top-level SET/REMOVE, is a single MutateRow: one round trip, with no read of the old item. A single integer ADD, or a SET computed from the attribute’s own value, uses the INT64 SUM cell, so Bigtable does the addition in one call. Conditions, returned item values, nested changes and other arithmetic need a read. The adapter computes the change and writes it with CheckAndMutateRow only if the item’s version cell is unchanged. On a conflict it repeats the read and condition check, up to eight attempts. Every write is atomic for one item and linearizable because the app profile routes to a single cluster. Multi-cluster routing would break that, so at startup, before it accepts any requests, the adapter checks through the Bigtable Admin API that the app profile uses single-cluster routing with transactional writes allowed and that both column families exist as expected. A misconfiguration stops the adapter instead of showing up under load. A top-level SET/REMOVE that skips the read cannot check the size of the item it produces, so DynamoDB’s 400 KiB item limit is not enforced on that path. If your application depends on that limit being enforced exactly, use a backend that reads before writing.
There are three write paths. An unconditional write is one MutateRow. An integer counter addition uses the aggregate cell in one call. Everything else reads the item and writes it with CheckAndMutateRow only if its version is unchanged.There are three write paths. An unconditional write is one MutateRow. An integer counter addition uses the aggregate cell in one call. Everything else reads the item and writes it with CheckAndMutateRow only if its version is unchanged.

Simple mutations and supported counters can avoid a read; other writes read the item and use a version guard.

​
Reads and filters

A Query is a range read. Because the row key keeps DynamoDB’s sort order, the key condition, the direction and the page position all map to the row range, and results come back in DynamoDB’s order without re-sorting. A FilterExpression runs in the adapter, not in Bigtable. Bigtable’s row filters work on column families, qualifiers and versions, not on DynamoDB’s typed attributes, so the adapter reads the range and filters the items it read. A filtered read can read more rows than it returns, and a selective filter over a wide range costs what the range costs. Prefer a selective key condition to a broad range plus a filter. Scan pages through the table the same way. Paging limits the response size, but a broad scan still reads every row it passes and competes with single-item requests for the instance’s provisioned capacity. Reads are strongly consistent through the single-cluster app profile. ConsistentRead=false does not pick a cheaper or staler read; a request that would be eventually consistent on DynamoDB is strongly consistent here.
A Query's key condition becomes a Bigtable row range, and Bigtable returns every row in it. The adapter then applies the FilterExpression, so a filtered read can examine many more rows than it returns.A Query's key condition becomes a Bigtable row range, and Bigtable returns every row in it. The adapter then applies the FilterExpression, so a filtered read can examine many more rows than it returns.

A filtered read examines every row in the selected key range. The adapter returns only rows that match the filter.

​
Limitations

Where Bigtable and DynamoDB differ
  • Multi-item transactions are not supported. TransactWriteItems, TransactGetItems and transactional PartiQL are rejected, because Bigtable cannot commit or read several rows as one unit. For cross-item atomicity, use Spanner or a PostgreSQL backend.
  • Secondary indexes are not supported. A GSI or LSI query is rejected rather than answered by scanning the table. Bigtable materialized views are not offered as DynamoDB indexes.
  • DynamoDB Streams are not supported. Bigtable change streams are not compatible with DynamoDB Streams, and a change record cannot be written in the same atomic step as the write it describes.
  • Per-item TTL is not supported. Bigtable expires data only through a column-family garbage-collection rule (one maximum age or version count for the whole family), not per item from an attribute. Configuring TTL fails instead of applying a different expiry rule.
  • The 400 KiB item limit behaves differently. A top-level SET/REMOVE that skips the read does not check the resulting item’s size, as described above. PutItem and updates that read the item still enforce it.
  • Filtered reads behave differently: they can read more rows than they return. Filters run in the adapter over the whole key range; see the previous section.
  • A frequently updated item behaves differently: its writes queue up. Different partition keys spread across Bigtable, but repeated updates to one item take turns on that row, and adding nodes does not split it. A benchmark with evenly spread keys does not predict this.

​
Other considerations

Before going live. Provision the Bigtable instance, the Bigtable table with its d and n column families, and a single-cluster app profile with single-row transactions allowed. The adapter checks these at startup and does not start without them. Capacity and cost. Bigtable bills for provisioned nodes and storage, including while your application is idle. Additional clusters add cost without giving this adapter automatic failover between clusters. Moving from AWS. Tables start empty. Existing DynamoDB items are not copied; load them through the DynamoDB API.

​
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.
DynamoDB · DynamoDB read units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB read units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.
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
  • Writes and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Bigtable bills whole provisioned nodes per hour, not vCPU or RAM, plus SSD storage of the compressed physical data. Nodes are sized from planning-peak reads and writes against Google’s per-node SSD throughput, with a one-node minimum. A replicated instance bills every cluster’s nodes and its own copy of the data; this profile prices one cluster, so the standby selection does not add a cluster.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • Bigtable pricing: https://cloud.google.com/bigtable/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.
  • 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-320830a9a89c06c228905dd61fe8054528d71731 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Bigtable pricing.
DynamoDB · DynamoDB write units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB write units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.
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
  • Reads and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Bigtable bills whole provisioned nodes per hour, not vCPU or RAM, plus SSD storage of the compressed physical data. Nodes are sized from planning-peak reads and writes against Google’s per-node SSD throughput, with a one-node minimum. A replicated instance bills every cluster’s nodes and its own copy of the data; this profile prices one cluster, so the standby selection does not add a cluster.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • Bigtable pricing: https://cloud.google.com/bigtable/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.
  • 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-320830a9a89c06c228905dd61fe8054528d71731 / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Bigtable pricing.
DynamoDB · Stored data
Feature: DynamoDB. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.
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
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Bigtable bills whole provisioned nodes per hour, not vCPU or RAM, plus SSD storage of the compressed physical data. Nodes are sized from planning-peak reads and writes against Google’s per-node SSD throughput, with a one-node minimum. A replicated instance bills every cluster’s nodes and its own copy of the data; this profile prices one cluster, so the standby selection does not add a cluster.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • Bigtable pricing: https://cloud.google.com/bigtable/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.
  • 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-320830a9a89c06c228905dd61fe8054528d71731 / 2026-10-22.planning.2. Curve: workload-3. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Bigtable pricing. DynamoDB → Cloud Bigtable: 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. 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.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Bigtable bills whole provisioned nodes per hour, not vCPU or RAM, plus SSD storage of the compressed physical data. Nodes are sized from planning-peak reads and writes against Google’s per-node SSD throughput, with a one-node minimum. A replicated instance bills every cluster’s nodes and its own copy of the data; this profile prices one cluster, so the standby selection does not add a cluster.
List prices read: 2026-10-22. Model: plan-320830a9a89c06c228905dd61fe8054528d71731 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Bigtable pricing.

​
Via Cloud SQL for PostgreSQL

​
How it works

Your application keeps its AWS SDK and code. Tensor9 runs a DynamoDB adapter beside it in the customer’s environment and sets AWS_ENDPOINT_URL_DYNAMODB, so the SDK sends its requests to the adapter over the local network. The adapter accepts DynamoDB requests and data types, returns DynamoDB responses and errors, and stores the data in PostgreSQL. Unsupported requests return errors. DynamoDB’s 38-digit numbers, typed sets, conditional writes, secondary indexes and atomic transactions are implemented with PostgreSQL storage and transactions. PostgreSQL adds multi-table transactions and indexes that update with each write, but has different concurrency, capacity and naming limits, described below. For a base-table Query or Scan, supported filters run in PostgreSQL as part of the SQL WHERE clause, and numbers compare as exact decimals. Results are fetched in batches until the request’s Limit or 1 MiB of item data is reached. Filters SQL cannot express run in the adapter over the rows PostgreSQL returns. Secondary-index queries work differently, as described below.
Before: on AWS, the application's DynamoDB SDK calls Amazon DynamoDB. After: on the target cloud, the same application and SDK call a Tensor9 adapter, which stores the data in PostgreSQL.Before: on AWS, the application's DynamoDB SDK calls Amazon DynamoDB. After: on the target cloud, the same application and SDK call a Tensor9 adapter, which stores the data in PostgreSQL.

Your application keeps its DynamoDB SDK; an adapter in the customer environment stores the data in PostgreSQL.

​
Architecture

The adapter parses DynamoDB requests and expressions, runs the matching PostgreSQL statements and returns DynamoDB responses. It connects through a connection pool with the customer’s credentials. All data stays in PostgreSQL, so adapter instances can restart or scale out without sharing local state; tables with Streams enabled have the single-writer limit described below. Each DynamoDB table is a PostgreSQL table named ddb_<name> in one database. The ddb_tables registry records each table’s PostgreSQL name, key schema, billing mode, time-to-live (TTL) settings, global secondary indexes (GSIs) and stream settings. A write or query for a table missing from the registry returns ResourceNotFoundException; writes never create tables. CreateTable at run time creates a PostgreSQL index for each declared GSI, and each table with Streams enabled also gets a _strm table that stores its change records.
Your app's DynamoDB SDK calls the Tensor9 adapter, which keeps no data of its own. PostgreSQL holds everything in one database: a table for each DynamoDB table, the ddb_tables registry, an index for each declared GSI, and a change-record table for each table with Streams enabled.Your app's DynamoDB SDK calls the Tensor9 adapter, which keeps no data of its own. PostgreSQL holds everything in one database: a table for each DynamoDB table, the ddb_tables registry, an index for each declared GSI, and a change-record table for each table with Streams enabled.

The adapter keeps no data; each DynamoDB table is its own table in one PostgreSQL database.

​
Item storage

Each DynamoDB item is one PostgreSQL row with columns pk TEXT, sk TEXT, okey TEXT and item JSONB. The PRIMARY KEY (pk, sk) index serves GetItem, and a second index over pk and byte-ordered okey serves ordered base-table Query requests. The item column keeps DynamoDB’s typed attributes, such as {"N":"123.45"}, {"B":"<b64>"} and typed sets. Numbers stay decimal strings, so a 38-digit amount or a Snowflake ID is never rounded, and a number stays distinct from a numeric string. Enabling TTL builds a PostgreSQL expression index over the configured epoch attribute in the item JSONB, and a leader-elected background worker, one adapter instance at a time, deletes expired rows through it in bounded batches. Expired items stay readable until they are deleted, because reads do not filter on TTL.
A DynamoDB item becomes one row with pk, sk, okey and item columns and PRIMARY KEY (pk, sk). The whole item is stored as JSONB in its DynamoDB form, so a number keeps its exact decimal text. The okey column keeps the sort order, and TTL uses an index over the item.A DynamoDB item becomes one row with pk, sk, okey and item columns and PRIMARY KEY (pk, sk). The whole item is stored as JSONB in its DynamoDB form, so a number keeps its exact decimal text. The okey column keeps the sort order, and TTL uses an index over the item.

Each attribute keeps its DynamoDB type tag inside item JSONB , so {“N”:“123.45”} keeps its exact decimal string.

​
Tables

Each DynamoDB table has its own PostgreSQL table, indexes and, when Streams is on, a _strm change-record table. CreateTable creates those objects and the registry entry, and DeleteTable drops them. You can tune storage, indexes and vacuum settings per table. When it creates a table, the adapter checks a limit of 500 DynamoDB tables per namespace. Concurrent creates of different tables can exceed it; it is a safeguard, not a PostgreSQL quota. Tables are not spread across database instances automatically, so plan database capacity and table placement for larger deployments. A provisioned instance costs compute while idle.
Each DynamoDB table is its own PostgreSQL table in one database, next to the ddb_tables registry and each table's indexes. The adapter allows 500 tables per namespace; larger deployments need capacity and placement planning.Each DynamoDB table is its own PostgreSQL table in one database, next to the ddb_tables registry and each table's indexes. The adapter allows 500 tables per namespace; larger deployments need capacity and placement planning.

Each DynamoDB table is its own PostgreSQL table; CreateTable and DeleteTable create and drop them.

​
Conditional writes

For a conditional write, the adapter locks the item’s row with SELECT … FOR UPDATE, checks the ConditionExpression against it, then writes and commits. The lock stops another writer from changing the item between the check and the write, at the cost of one extra round trip. For attribute_not_exists(pk), the primary key ensures that only one of two concurrent creates succeeds. A false condition returns the non-retryable ConditionalCheckFailed error and can return the item that failed it. A PostgreSQL serialization failure or lock timeout (40001 or lock-not-available) returns a retryable throughput error instead, so the SDK backs off and retries. Concurrency failures are never reported as failed conditions. Some unconditional writes skip the read: a top-level SET or REMOVE update, or an integer counter add, runs as one statement when it has no condition, asks for no returned item and touches no secondary index or stream.
A conditional write locks the row with SELECT … FOR UPDATE, evaluates the DynamoDB condition in the adapter against the locked row, then writes and commits. A false condition returns ConditionalCheckFailed; a concurrency conflict returns a retryable error, never a condition failure. The primary key prevents duplicate creates.A conditional write locks the row with SELECT … FOR UPDATE, evaluates the DynamoDB condition in the adapter against the locked row, then writes and commits. A false condition returns ConditionalCheckFailed; a concurrency conflict returns a retryable error, never a condition failure. The primary key prevents duplicate creates.

Failed conditions and PostgreSQL concurrency conflicts return different error types.

​
Secondary indexes

On each write, the adapter adds two index fields to the item’s JSONB. _idx_<name>_h holds the index partition key and treats equal numbers such as 1 and 1.0 as the same; _idx_<name>_o holds the sort key in sort order, with the base key breaking ties. A PostgreSQL index over these fields finds the items with a matching partition key, and the adapter then applies sort-key conditions, ordering, pagination and any FilterExpression. The index fields are saved in the same transaction as the item, so GSI queries are strongly consistent; DynamoDB’s own GSIs update asynchronously. One index lookup can examine at most 10,000 items for a single partition-key value, and a lookup beyond that returns an error, so choose index keys with this limit in mind.
On each write, the adapter adds two index fields to the item's JSONB, and PostgreSQL keeps an index over them. A GSI query looks up the index, then the adapter filters and orders the results. The index fields are saved with the item, so the index is strongly consistent.On each write, the adapter adds two index fields to the item's JSONB, and PostgreSQL keeps an index over them. A GSI query looks up the index, then the adapter filters and orders the results. The index fields are saved with the item, so the index is strongly consistent.

A GSI uses a PostgreSQL index to find candidates, which the adapter filters and orders; the index updates with the item.

​
Transactions

TransactWriteItems runs in one PostgreSQL transaction at SERIALIZABLE isolation: a debit in one table and a credit in another both commit or both fail, as in DynamoDB. DynamoDB’s 100-action limit and one-operation-per-item rule apply. The adapter saves the ClientRequestToken in the same transaction, so within DynamoDB’s idempotency window a retry with the same token returns the earlier success without writing again. Row locks are taken in a fixed order so opposite transfers do not deadlock, and serialization or deadlock failures return retryable conflicts. A transaction that touches a table with Streams enabled returns ValidationException before it runs, because transactions do not write stream records.
A TransactWriteItems request with a debit in one table and a credit in another commits atomically in one PostgreSQL transaction at SERIALIZABLE isolation, as on DynamoDB.A TransactWriteItems request with a debit in one table and a credit in another commits atomically in one PostgreSQL transaction at SERIALIZABLE isolation, as on DynamoDB.

TransactWriteItems runs in one PostgreSQL transaction at SERIALIZABLE isolation, atomic across tables.

​
Limitations

  • Hot keys behave differently: one PostgreSQL instance holds each table. Heavy contention on one key causes serialization failures and row-lock conflicts. The adapter returns retryable errors, but sustained contention can use up the SDK’s retry budget and appear as throttling.
  • You must run one writer per table with Streams enabled. A writer lease of about 90 seconds keeps stream records in order; a second adapter instance writing during the lease gets a retryable ThrottlingException. Throughput depends on the writer, database and workload. Tables without streams accept concurrent writers.
  • Listing more than 100 shards in DescribeStream is not supported. A stream with more shards is not fully listed in one call.
  • Transactions on tables with Streams enabled are not supported. A TransactWriteItems request touching one returns ValidationException, because transactions do not write stream records.
  • DynamoDB backup and global-table APIs are not supported. On-demand backup and restore, point-in-time recovery (PITR) and global-table replication APIs are not available. Use PostgreSQL backups, snapshots, PITR and replica failover instead.
  • Capacity behaves differently: it is provisioned and billed while idle. Size PostgreSQL capacity ahead of demand. More tables need more instances and table-placement planning.
  • Index lookups over 10,000 items are not supported. A lookup that examines more than 10,000 items for one index partition-key value returns an error.
  • You must plan around the 500-table limit. The adapter checks 500 DynamoDB tables per namespace. Larger deployments need database capacity and table-placement planning.
  • Expired items behave differently: they stay readable until deleted. A background job deletes expired rows through the TTL index in bounded batches. Until then, GetItem, Query and Scan can return the item, and it still uses storage.

​
Other considerations

  • Stream records. Each change record is saved in the table’s _strm table in the same transaction as the write, so a record exists only if its write committed. The single-writer lease keeps record order equal to commit order, so a reader can resume without skipping records.
  • Connections. The adapter pools PostgreSQL connections. With many adapter instances, you may need a separate pooler to keep total connections under the database’s limit.
  • Moving data. Move and test one table at a time, by export and import, dual writes or backfill and switch. Application code keeps using the DynamoDB API.
  • Operations. Monitor SQL activity, maintain indexes, vacuum tables and run backups, PITR and failover with your usual PostgreSQL tools.

​
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 cost by DynamoDB point-read rate
Reference monthly service charges by Read operations/s. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
Monthly cost by DynamoDB point-read rate: monthly service charges by Read operations/s. Exact values are in the following table.Monthly cost by DynamoDB point-read rate: monthly service charges by Read operations/s. Exact values are in the following table.
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
  • Strong 1 KiB point reads and plain writes; one write per ten reads, no origin index amplification. 730 hours/month; retained source data stays at 100 GiB. Cloud SQL has 2 vCPU, 8 GiB memory and 200 GiB SSD. Twice source storage is an authored reserve, not a measured sizing rule; throughput remains unqualified.
  • 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.
  • Origin workload is point GetItem and plain PutItem on Standard on-demand tables. Queries, transactions and Streams are not modeled.
  • Source usage is priced at reference rates; source lines are not actual invoice charges. Free or discounted usage still consumes target resources.
  • AWS DynamoDB Standard on-demand pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • DynamoDB provisioned capacity, global replicas, transactions, queries/scans and Streams; unqualified database sizing.
Rate snapshot: 2026-10-18. Model: dynamodb-cloudsql / 2026-10-18.4. Curve: read-rate. Sources: AWS DynamoDB Standard on-demand pricing, Cloud SQL Enterprise PostgreSQL pricing.
Monthly cost by retained DynamoDB data
Reference monthly service charges by Retained source data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
Monthly cost by retained DynamoDB data: monthly service charges by Retained source data. Exact values are in the following table.Monthly cost by retained DynamoDB data: monthly service charges by Retained source data. Exact values are in the following table.
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
  • Source traffic stays at 100 million strong 1 KiB read units and 10 million plain write units/month, with no origin index amplification. Cloud SQL uses 2 vCPU and 8 GiB memory; SSD provision is twice source GiB, rounded up to whole GiB with a 10 GiB minimum. This reserve is an authored assumption, not a measured expansion factor or capacity qualification.
  • 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.
  • Origin workload is point GetItem and plain PutItem on Standard on-demand tables. Queries, transactions and Streams are not modeled.
  • Source usage is priced at reference rates; source lines are not actual invoice charges. Free or discounted usage still consumes target resources.
  • AWS DynamoDB Standard on-demand pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • DynamoDB provisioned capacity, global replicas, transactions, queries/scans and Streams; unqualified database sizing.
Rate snapshot: 2026-10-18. Model: dynamodb-cloudsql / 2026-10-18.4. Curve: retained-data. Sources: AWS DynamoDB Standard on-demand pricing, Cloud SQL Enterprise PostgreSQL pricing. DynamoDB → 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.
  • DynamoDB provisioned capacity, global replicas, transactions, queries/scans and Streams; unqualified database sizing.
Scenario assumptions
  • Inferred point reads: 100,000,000 calls/month.
  • Inferred base item writes: 10,000,000 calls/month.
  • Origin billed 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.
  • Origin workload is point GetItem and plain PutItem on Standard on-demand tables. Queries, transactions and Streams are not modeled.
Rate snapshot: 2026-10-18. Model: dynamodb-cloudsql / 2026-10-18.4. Scenario: dynamodb-cloudsql-reference. Sources: AWS DynamoDB Standard on-demand pricing, Cloud SQL Enterprise PostgreSQL pricing.

​
On Azure

​
Via Azure Cosmos DB (provisioned)

​
How it works

Your application keeps its DynamoDB SDK and code. Tensor9 runs a DynamoDB adapter beside it in the customer’s environment and sets AWS_ENDPOINT_URL_DYNAMODB so the SDK sends its requests to the adapter over the local network. The adapter accepts DynamoDB requests and data types, returns DynamoDB responses and errors, and stores the data in Azure Cosmos DB. Each item is stored as a Cosmos document. Most operations behave as they do on DynamoDB. The differences you can see are numeric precision, how results are paged, and multi-item transactions, which are rejected. The sections below describe each one.
Before: on AWS your application's DynamoDB SDK calls Amazon DynamoDB. After: in the target cloud the same application and SDK call a Tensor9 adapter, which stores the data in Azure Cosmos DB.Before: on AWS your application's DynamoDB SDK calls Amazon DynamoDB. After: in the target cloud the same application and SDK call a Tensor9 adapter, which stores the data in Azure Cosmos DB.

Your application keeps using the DynamoDB API; an adapter beside it stores the data in Cosmos DB.

​
Architecture

The adapter keeps no data of its own. Items and table definitions live in Cosmos, and the adapter connects with the customer’s workload identity, so an adapter instance can restart without recovering anything. A table with DynamoDB Streams enabled still accepts writes from only one adapter instance at a time. Tensor9 provisions one Cosmos account and one ddb database per stack, with a container for each declared table. The backend you select sets provisioned or serverless throughput for the account. Each item’s partition key starts with its table name, and a reserved _tablemeta partition holds table definitions and creation times. Tables created at runtime share an existing container, as described below. A local secondary index lives in its table’s container. On the provisioned backend, each global secondary index has a separate container that Azure updates asynchronously.
Architecture: your app's DynamoDB SDK calls the Tensor9 adapter, which keeps no data of its own and stores everything in Azure Cosmos DB. The stack has one Cosmos account with one database named ddb. Each declared table has its own container, partitioned on /_pk, holding its items and a partition of table definitions. Each global secondary index has its own index container that Azure keeps up to date, and a local secondary index lives in its table's container. Runtime-created tables share a deployed container and its capacity.Architecture: your app's DynamoDB SDK calls the Tensor9 adapter, which keeps no data of its own and stores everything in Azure Cosmos DB. The stack has one Cosmos account with one database named ddb. Each declared table has its own container, partitioned on /_pk, holding its items and a partition of table definitions. Each global secondary index has its own index container that Azure keeps up to date, and a local secondary index lives in its table's container. Runtime-created tables share a deployed container and its capacity.
How a request is carried out: the adapter checks each DynamoDB request and turns it into one Cosmos operation: a point read, a SQL query, a PATCH or a stored procedure. Cosmos holds a container per declared table, partitioned on /_pk, and an index container per global secondary index that Azure keeps up to date. Runtime-created tables share a deployed container and its capacity.How a request is carried out: the adapter checks each DynamoDB request and turns it into one Cosmos operation: a point read, a SQL query, a PATCH or a stored procedure. Cosmos holds a container per declared table, partitioned on /_pk, and an index container per global secondary index that Azure keeps up to date. Runtime-created tables share a deployed container and its capacity.

The adapter keeps no data of its own; Cosmos holds it all. One account and one “ddb” database hold a container per declared table, partitioned on /_pk. Runtime-created tables share a deployed container and its capacity.

Each DynamoDB request becomes one Cosmos operation. Each declared table has its own container; runtime-created tables share a deployed container and its capacity.

​
Schemas

Each item keeps its DynamoDB type tags inside the document’s item field. Numbers are stored as native Cosmos JSON numbers, and binary values as hex that sorts in the same order. Extra fields record the table and partition each item belongs to. Numbers have less precision. A number must have at most 15 significant digits and fit Cosmos’s native number range. A value outside that is rejected before anything is stored; DynamoDB’s full 38-digit numbers are not kept as strings. Items are still limited to 400 KiB. Updates check the size of the resulting item, including the attributes copied into local secondary indexes. Cosmos’s larger document limit does not lift this DynamoDB check.
A DynamoDB item keeps its type tags inside the Cosmos document. Numbers are stored as native JSON numbers after their precision and range are checked.A DynamoDB item keeps its type tags inside the Cosmos document. Numbers are stored as native JSON numbers after their precision and range are checked.

Type tags keep numbers, strings, binary values and sets distinct; native numbers let Cosmos evaluate conditions on them.

​
Where tables live

Each declared table has its own container, indexing policy and storage within the stack’s shared account and database. The containers share account administration and lifecycle, so watch account limits as the number of tables grows. You choose provisioned or serverless throughput when you select the backend. A provisioned container gets an autoscale range of request units (RUs) derived from the table’s declared capacity; a PAY_PER_REQUEST table gets a configurable default range. Serverless containers bill for the requests they use and do not reserve the table’s requested capacity. Throughput depends on request-unit use and on how evenly keys spread across partitions. Changing the selected backend recreates the account and containers, so plan a data migration. Inside a container, a partition key that starts with the table name, such as orders|S:user#42, keeps tables apart. Point reads and base-table queries use that _pk value; scans and table lookups filter on _tbl. A runtime CreateTable writes a table record in the stack’s first deployed container, because the adapter’s identity has no permission to create Cosmos containers. DescribeTable and ListTables read those records.
  • A table needs a known key schema. A composite-key table’s key schema comes from a declared table, its table record, or the first request that includes the full key. A Put whose key schema cannot be determined is rejected; it is never written under a guessed key.
  • Declared tables get their own container; runtime-created tables share one. A declared table’s container, throughput, index and storage are its own. A table created at runtime shares a deployed container: the table-name prefix keeps its items apart, but it shares that container’s physical partitions. A hot partition key is still limited by the capacity of the physical partition it lands on.
All of a stack's tables share one Cosmos account with one database named ddb; each declared table keeps its own container, index and storage. The selected backend sets the account's throughput mode: provisioned gives each container its own autoscale range of request units, serverless bills per request with no throughput reserved per container. Runtime-created tables share a deployed container and its capacity.All of a stack's tables share one Cosmos account with one database named ddb; each declared table keeps its own container, index and storage. The selected backend sets the account's throughput mode: provisioned gives each container its own autoscale range of request units, serverless bills per request with no throughput reserved per container. Runtime-created tables share a deployed container and its capacity.

A stack’s tables share one account and one “ddb” database, using the selected throughput mode. Each declared table has its own container; runtime-created tables share a deployed container and its capacity. At runtime, CreateTable, DeleteTable and UpdateTable change table records, not Cosmos resources.

​
Conditional writes

How the adapter writes an item depends on the operation and its options. Ordinary SET updates run in a stored procedure scoped to the item’s partition. Cosmos reads the current item, checks the condition, applies the update and checks the 400 KiB item limit in one atomic step. This is read-modify-write inside the database, with no extra round trip from the adapter. A Cosmos PATCH is used only in a narrower case. The condition must require the item or attribute to exist, every action must remove a top-level attribute, the table must have no TTL or stream, and the request must not ask for the old item. A SET that grows the item cannot use PATCH, because PATCH cannot check the resulting DynamoDB item size. LSI updates, unsupported expressions and requests that need the old item when a condition fails take a third path: the adapter reads the item, then writes it only if its ETag is unchanged. Writes to a table with a stream use this path too, so the item and its stream record are saved together. A conflict with a concurrent write is retryable; it is not reported as a failed condition. The Yahoo! Cloud Serving Benchmark (YCSB) workload F measures read-modify-write from the application side: a GetItem followed by an UpdateItem. Its full latency covers both calls and is not the same as the update step alone, and the sequence is not a multi-item transaction. In the recorded 2026-09-09 provisioned run with 16 workers, the full read-modify-write median (p50) was 21.071 ms and the update step’s median was 15.935 ms, each the median of three completed repetitions. These are two parts of the same workload, not two competing implementations.
Three ways an item is written: eligible removals use a conditional Cosmos PATCH; ordinary writes use a stored procedure that runs atomically; other requests read the item, then write it only if it has not changed.Three ways an item is written: eligible removals use a conditional Cosmos PATCH; ordinary writes use a stored procedure that runs atomically; other requests read the item, then write it only if it has not changed.

​
Secondary indexes

A local secondary index lives in its table’s container and uses the same partition, so a read from it reflects a completed write immediately. Its entry size also counts toward DynamoDB’s item-size check. On the provisioned backend, Azure keeps a separate container for each declared global secondary index and updates it asynchronously. A query on the index reads that container, with its key condition, sort order and paging applied there. GSI reads are eventually consistent, and ConsistentRead=true on a GSI is rejected, as on DynamoDB. Serverless tables cannot declare these global secondary indexes. Index definitions must match the provisioned configuration; the adapter never builds a substitute index at runtime.
A local secondary index lives in the table's container, so writes show up in it immediately. On provisioned accounts, Azure updates a separate container for each global secondary index asynchronously.A local secondary index lives in the table's container, so writes show up in it immediately. On provisioned accounts, Azure updates a separate container for each global secondary index asynchronously.

​
Transactions

The Cosmos adapter rejects DynamoDB multi-item transactions. This includes TransactWriteItems, TransactGetItems and transactional PartiQL (ExecuteTransaction), even when every item shares one partition key. Cosmos still makes each single-item write atomic, and saves an item together with its stream record, using stored procedures and batches within one partition. These do not provide the DynamoDB transaction APIs. If your application needs DynamoDB multi-item transactions, choose another listed backend that supports them.

​
Limitations

Where DynamoDB and Cosmos DB differ
  • Numbers behave differently: at most 15 significant digits. Values must also fit Cosmos’s native number range, where DynamoDB allows 38 digits. A value outside that range is rejected.
  • LSI updates behave differently: they take the read-then-write path. The adapter still enforces DynamoDB’s 400 KiB item limit. Ordinary SET updates are checked in the stored procedure; LSI updates read the item first so the index entry size is counted too.
  • Multi-item transactions are not supported. The adapter rejects every DynamoDB multi-item transaction API, including requests confined to one partition key.
  • Reads behave differently: they are always strongly consistent. The account uses Strong consistency whatever the request’s ConsistentRead flag says. Plan capacity for strongly consistent reads.
  • Paging behaves differently. Query and Scan return Cosmos-sized result pages. Limit and ScannedCount do not exactly match DynamoDB’s count of items examined before filtering, and some filter conditions are checked in the adapter.
  • Global secondary indexes behave differently: provisioned backend only. They are eventually consistent; local secondary indexes share the table’s container. Declared index definitions must match the deployment.
  • Streams behave differently: one writing instance per table. Stream records are saved with the item, but a stream-enabled table accepts writes from one adapter instance at a time to keep records in order. Writes from another instance can be rejected until the writer lease is free.
  • Hot keys behave differently. Capacity depends on how keys spread and on the account’s throughput mode. Requests to one hot item can contend with each other even when overall capacity remains.
  • DeleteTable behaves differently: other instances see it after about five seconds. Adapter instances cache table definitions, so others can take about five seconds to see the deletion. Cleanup of the stored items finishes within a bounded time.

​
Other considerations

  • Moving from AWS. The Cosmos containers start empty. Move existing DynamoDB data with an export and import, a backfill or a dual-write cutover before you switch traffic.
  • Deployment and access. Tensor9 provisions one account with the chosen throughput mode, a shared database and a container for each declared table. Access uses managed identities; no account keys are needed.
  • Capacity. Provisioned containers each have their own autoscale RU range. Serverless containers reserve no throughput and bill for the requests they use. The 2026-09-09 adapter measurements used separate Standard_D8s_v5 driver and adapter VMs in westus2, Strong consistency and gateway-mode connections; the provisioned container autoscaled up to 40,000 RU/s. YCSB used 100,000 verified records of ten 100-byte fields and 200,000 operations per repetition. Each mode has its own results, and medians summarize three completed repetitions. There is no matching native DynamoDB baseline for this setup, so these results do not show a performance advantage over DynamoDB.
  • Runtime-created tables. They live inside an already deployed container, kept apart by name, and share its capacity. Declared tables have their own containers.
  • What to monitor. Microsoft operates Cosmos storage; Tensor9 operates the adapter. Watch request units, throttling, write conflicts and latency, along with resource use on the adapter and application hosts.

​
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.
DynamoDB · DynamoDB read units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB read units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.
DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.
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
  • Writes and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Provisioned Cosmos DB bills reserved throughput in 100 RU/s blocks per hour, not consumed operations: planning-peak reads at 1 RU and writes at about 5.5 RU each are summed and rounded up to whole 100 RU/s blocks, with the documented 400 RU/s manual minimum (https://learn.microsoft.com/en-us/azure/cosmos-db/set-throughput). The blocks are a hard throughput limit, so they are planned at full utilization of the planning peak. Autoscale (USD 0.012 per 100 RU/s-hour, 100-1,000 RU/s entry) and the free tier (1,000 RU/s and 25 GB on one account) are not selected. Each additional region bills its own RU/s and storage.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-fa502df1b7bcaf6b86688cf2258a7216e475f489 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Azure Retail Prices API.
DynamoDB · DynamoDB write units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB write units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.
DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.
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
  • Reads and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Provisioned Cosmos DB bills reserved throughput in 100 RU/s blocks per hour, not consumed operations: planning-peak reads at 1 RU and writes at about 5.5 RU each are summed and rounded up to whole 100 RU/s blocks, with the documented 400 RU/s manual minimum (https://learn.microsoft.com/en-us/azure/cosmos-db/set-throughput). The blocks are a hard throughput limit, so they are planned at full utilization of the planning peak. Autoscale (USD 0.012 per 100 RU/s-hour, 100-1,000 RU/s entry) and the free tier (1,000 RU/s and 25 GB on one account) are not selected. Each additional region bills its own RU/s and storage.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-fa502df1b7bcaf6b86688cf2258a7216e475f489 / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Azure Retail Prices API.
DynamoDB · Stored data
Feature: DynamoDB. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.
DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.
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
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Provisioned Cosmos DB bills reserved throughput in 100 RU/s blocks per hour, not consumed operations: planning-peak reads at 1 RU and writes at about 5.5 RU each are summed and rounded up to whole 100 RU/s blocks, with the documented 400 RU/s manual minimum (https://learn.microsoft.com/en-us/azure/cosmos-db/set-throughput). The blocks are a hard throughput limit, so they are planned at full utilization of the planning peak. Autoscale (USD 0.012 per 100 RU/s-hour, 100-1,000 RU/s entry) and the free tier (1,000 RU/s and 25 GB on one account) are not selected. Each additional region bills its own RU/s and storage.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-fa502df1b7bcaf6b86688cf2258a7216e475f489 / 2026-10-22.planning.2. Curve: workload-3. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Azure Retail Prices API. DynamoDB → Azure Cosmos DB (provisioned): 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. 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.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Provisioned Cosmos DB bills reserved throughput in 100 RU/s blocks per hour, not consumed operations: planning-peak reads at 1 RU and writes at about 5.5 RU each are summed and rounded up to whole 100 RU/s blocks, with the documented 400 RU/s manual minimum (https://learn.microsoft.com/en-us/azure/cosmos-db/set-throughput). The blocks are a hard throughput limit, so they are planned at full utilization of the planning peak. Autoscale (USD 0.012 per 100 RU/s-hour, 100-1,000 RU/s entry) and the free tier (1,000 RU/s and 25 GB on one account) are not selected. Each additional region bills its own RU/s and storage.
List prices read: 2026-10-22. Model: plan-fa502df1b7bcaf6b86688cf2258a7216e475f489 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Azure Retail Prices API.

​
Via Azure Cosmos DB (serverless)

​
Requests and database state

Your DynamoDB client sends requests to the Rust adapter in the customer environment. The adapter parses DynamoDB expressions, performs Cosmos operations and returns DynamoDB responses. Cosmos stores items, table definitions and stream records. The adapter uses workload identity to access that data; restarting an adapter instance does not require restoring local item state.

​
Choosing serverless capacity

Tensor9 provisions a serverless Cosmos account and one ddb database for the deployment. Charges follow consumed request units and stored data, without a dedicated autoscale range. The selected account mode applies to its containers; a source table’s provisioned capacity does not reserve Cosmos request units. Test the workload’s bursts, retries and partition distribution against the serverless limits.

​
Declared and runtime-created tables

Each declared table gets a container. A table created through the runtime CreateTable API instead uses the first deployed container: the adapter records its schema and separates its items with a table-prefixed partition key. The data identity cannot provision a new Cosmos container. DescribeTable and ListTables read the durable registry; DeleteTable invalidates the table generation and performs bounded cleanup. Runtime-created tables therefore share container capacity.

​
Items, reads and conditional writes

DynamoDB attribute type tags are retained, but numbers must fit the native Cosmos representation: at most 15 significant digits and a representable range. Unsupported numbers are rejected. The adapter enforces a 400 KiB item limit and uses strong reads regardless of ConsistentRead. Ordinary writes use a Cosmos stored procedure; eligible conditional removals use PATCH, and other request shapes use guarded read-modify-write. Query and Scan use Cosmos result windows, so Limit and ScannedCount differ from DynamoDB’s examined-item accounting.

​
Indexes, transactions and streams

Local secondary indexes share the table’s container and reflect a write immediately. A global secondary index requires the provisioned backend because the separate Azure-maintained index container needs autoscale throughput; declaring one on serverless stops the build. DynamoDB multi-item transaction APIs are rejected. Streams commit each change record with the item and require one writing instance per streamed table. All four view types and 24-hour retention are available; an older position returns TrimmedDataAccessException.

​
Expiry, migration and operation

The adapter converts the configured absolute TTL epoch into Cosmos’s relative expiry value. Cosmos removes expired documents asynchronously. Deploy the destination, load existing items and validate the application’s queries and stream consumers before switching traffic. Changing between provisioned and serverless accounts requires a new destination and data migration. Microsoft operates Cosmos, while Tensor9 operates the adapter; configure account access, backups and monitoring for the customer environment.

​
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.
DynamoDB · DynamoDB read units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB read units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.
DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.
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
  • Writes and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Cosmos DB serverless bills consumed Request Units (USD 0.25 per million) and stored GB. Per-operation rates assume Microsoft’s published 1 KB costs: a point read is 1 RU and an unindexed insert about 5.5 RU (https://learn.microsoft.com/en-us/azure/cosmos-db/optimize-cost-reads-writes). Larger items, default indexing of every property, replaces (2x an insert) and strong or bounded-staleness reads (2x) cost more RU than these rates assume.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-26501e747dcdbd0b7586f4ab58235e0ced69b13c / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Azure Retail Prices API.
DynamoDB · DynamoDB write units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB write units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.
DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.
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
  • Reads and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Cosmos DB serverless bills consumed Request Units (USD 0.25 per million) and stored GB. Per-operation rates assume Microsoft’s published 1 KB costs: a point read is 1 RU and an unindexed insert about 5.5 RU (https://learn.microsoft.com/en-us/azure/cosmos-db/optimize-cost-reads-writes). Larger items, default indexing of every property, replaces (2x an insert) and strong or bounded-staleness reads (2x) cost more RU than these rates assume.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-26501e747dcdbd0b7586f4ab58235e0ced69b13c / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Azure Retail Prices API.
DynamoDB · Stored data
Feature: DynamoDB. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.
DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.
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
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Cosmos DB serverless bills consumed Request Units (USD 0.25 per million) and stored GB. Per-operation rates assume Microsoft’s published 1 KB costs: a point read is 1 RU and an unindexed insert about 5.5 RU (https://learn.microsoft.com/en-us/azure/cosmos-db/optimize-cost-reads-writes). Larger items, default indexing of every property, replaces (2x an insert) and strong or bounded-staleness reads (2x) cost more RU than these rates assume.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-26501e747dcdbd0b7586f4ab58235e0ced69b13c / 2026-10-22.planning.2. Curve: workload-3. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Azure Retail Prices API. DynamoDB → Azure Cosmos DB (serverless): 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. 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.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Cosmos DB serverless bills consumed Request Units (USD 0.25 per million) and stored GB. Per-operation rates assume Microsoft’s published 1 KB costs: a point read is 1 RU and an unindexed insert about 5.5 RU (https://learn.microsoft.com/en-us/azure/cosmos-db/optimize-cost-reads-writes). Larger items, default indexing of every property, replaces (2x an insert) and strong or bounded-staleness reads (2x) cost more RU than these rates assume.
List prices read: 2026-10-22. Model: plan-26501e747dcdbd0b7586f4ab58235e0ced69b13c / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Azure Retail Prices API.

​
On OCI

​
Infrastructure mapping

Tensor9 converts the declared aws_dynamodb_table to an oci_nosql_table in the customer’s OCI compartment. This is the infrastructure-only adaptation: it provisions storage but does not provide an AWS DynamoDB endpoint. Application reads, writes, queries and runtime table administration use OCI NoSQL APIs. The table and control pages describe this same backend choice.

​
Keys and item data

The DynamoDB partition key becomes the OCI SHARD key. An optional sort key becomes the second primary-key column. String, number and binary key types become corresponding OCI column types; other item attributes occupy a value JSON column. Adapt queries and serialization to that layout rather than sending DynamoDB attribute documents directly.

​
Capacity and storage

PAY_PER_REQUEST selects OCI ON_DEMAND; provisioned DynamoDB capacity selects OCI PROVISIONED settings. OCI read and write units differ from DynamoDB units, so validate them against the workload. OCI also requires an explicit storage cap. Increase that cap before data reaches it; the source DynamoDB table had no equivalent fixed cap.

​
Indexes, expiry and integrations

The current infrastructure mapping does not create declared GSIs or LSIs. Configure native OCI indexes and update the application’s access patterns. A source TTL declaration produces a no-expiry default; its per-item epoch attribute is not translated into automatic expiry. DynamoDB Streams, AWS PITR configuration, source KMS key references and replica settings are not reproduced by this table resource. Configure the corresponding backend data-protection and event requirements separately.

​
Migration and operation

The new table starts empty. Convert application access, load the data, and test key lookups, queries, expiry and recovery before switching traffic. Oracle operates the NoSQL service; the customer manages compartment access, capacity, storage limits and the chosen recovery procedures. Use a different listed adaptation when the application must keep runtime DynamoDB API calls.

​
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. Native or deployment mapping. The application uses the OCI NoSQL API on this mapping. It does not provide a DynamoDB request translator, so DynamoDB fabric latency does not apply. Cost estimates describe the selected service resources; operation coverage remains separate.
DynamoDB · DynamoDB read units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB read units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1 (global list); currency: USD.
DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.
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
  • Writes and storage remain independent. 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.
  • Native/deployment comparison scope: The application uses the OCI NoSQL API on this mapping. It does not provide a DynamoDB request translator, so DynamoDB fabric latency does not apply.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Oracle NoSQL Database Cloud on-demand capacity bills consumed 1 KB read and write units and stored GB. Absolute-consistency reads cost two read units; larger records cost one unit per KB. Provisioned capacity (USD 0.0064 per read unit-month and 0.1254 per write unit-month, parts B89738 and B89737) and the Always Free tables are not selected.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • OCI price list API: https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/
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.
  • 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-d4b2a3538a1c61e563246f36c48dc1568328d822 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, OCI price list API.
DynamoDB · DynamoDB write units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB write units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1 (global list); currency: USD.
DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.
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
  • Reads and storage remain independent. 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.
  • Native/deployment comparison scope: The application uses the OCI NoSQL API on this mapping. It does not provide a DynamoDB request translator, so DynamoDB fabric latency does not apply.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Oracle NoSQL Database Cloud on-demand capacity bills consumed 1 KB read and write units and stored GB. Absolute-consistency reads cost two read units; larger records cost one unit per KB. Provisioned capacity (USD 0.0064 per read unit-month and 0.1254 per write unit-month, parts B89738 and B89737) and the Always Free tables are not selected.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • OCI price list API: https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/
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.
  • 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-d4b2a3538a1c61e563246f36c48dc1568328d822 / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, OCI price list API.
DynamoDB · Stored data
Feature: DynamoDB. 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.
DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.
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
  • 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.
  • Native/deployment comparison scope: The application uses the OCI NoSQL API on this mapping. It does not provide a DynamoDB request translator, so DynamoDB fabric latency does not apply.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Oracle NoSQL Database Cloud on-demand capacity bills consumed 1 KB read and write units and stored GB. Absolute-consistency reads cost two read units; larger records cost one unit per KB. Provisioned capacity (USD 0.0064 per read unit-month and 0.1254 per write unit-month, parts B89738 and B89737) and the Always Free tables are not selected.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • OCI price list API: https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/
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.
  • 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-d4b2a3538a1c61e563246f36c48dc1568328d822 / 2026-10-22.planning.2. Curve: workload-3. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, OCI price list API. DynamoDB → OCI NoSQL Database: 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. 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.
  • 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.
  • Native/deployment comparison scope: The application uses the OCI NoSQL API on this mapping. It does not provide a DynamoDB request translator, so DynamoDB fabric latency does not apply.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Oracle NoSQL Database Cloud on-demand capacity bills consumed 1 KB read and write units and stored GB. Absolute-consistency reads cost two read units; larger records cost one unit per KB. Provisioned capacity (USD 0.0064 per read unit-month and 0.1254 per write unit-month, parts B89738 and B89737) and the Always Free tables are not selected.
List prices read: 2026-10-22. Model: plan-d4b2a3538a1c61e563246f36c48dc1568328d822 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, OCI price list API.

​
On Private Kubernetes

​
PostgreSQL in the appliance

Tensor9 deploys and operates the PostgreSQL store with the customer appliance, including disconnected deployments. Application requests use the same Rust DynamoDB-to-PostgreSQL implementation as the managed PostgreSQL backend. Database access uses the configured connection credentials; Cloud SQL IAM authentication is specific to the Google-managed backend. The customer supplies the infrastructure, and the deployment’s storage, backup and recovery configuration determines availability.

​
How it works

Your application keeps its AWS SDK and code. Tensor9 runs a DynamoDB adapter beside it in the customer’s environment and sets AWS_ENDPOINT_URL_DYNAMODB, so the SDK sends its requests to the adapter over the local network. The adapter accepts DynamoDB requests and data types, returns DynamoDB responses and errors, and stores the data in PostgreSQL. Unsupported requests return errors. DynamoDB’s 38-digit numbers, typed sets, conditional writes, secondary indexes and atomic transactions are implemented with PostgreSQL storage and transactions. PostgreSQL adds multi-table transactions and indexes that update with each write, but has different concurrency, capacity and naming limits, described below. For a base-table Query or Scan, supported filters run in PostgreSQL as part of the SQL WHERE clause, and numbers compare as exact decimals. Results are fetched in batches until the request’s Limit or 1 MiB of item data is reached. Filters SQL cannot express run in the adapter over the rows PostgreSQL returns. Secondary-index queries work differently, as described below.
Before: on AWS, the application's DynamoDB SDK calls Amazon DynamoDB. After: on the target cloud, the same application and SDK call a Tensor9 adapter, which stores the data in PostgreSQL.Before: on AWS, the application's DynamoDB SDK calls Amazon DynamoDB. After: on the target cloud, the same application and SDK call a Tensor9 adapter, which stores the data in PostgreSQL.

Your application keeps its DynamoDB SDK; an adapter in the customer environment stores the data in PostgreSQL.

​
Architecture

The adapter parses DynamoDB requests and expressions, runs the matching PostgreSQL statements and returns DynamoDB responses. It connects through a connection pool with the customer’s credentials. All data stays in PostgreSQL, so adapter instances can restart or scale out without sharing local state; tables with Streams enabled have the single-writer limit described below. Each DynamoDB table is a PostgreSQL table named ddb_<name> in one database. The ddb_tables registry records each table’s PostgreSQL name, key schema, billing mode, time-to-live (TTL) settings, global secondary indexes (GSIs) and stream settings. A write or query for a table missing from the registry returns ResourceNotFoundException; writes never create tables. CreateTable at run time creates a PostgreSQL index for each declared GSI, and each table with Streams enabled also gets a _strm table that stores its change records.
Your app's DynamoDB SDK calls the Tensor9 adapter, which keeps no data of its own. PostgreSQL holds everything in one database: a table for each DynamoDB table, the ddb_tables registry, an index for each declared GSI, and a change-record table for each table with Streams enabled.Your app's DynamoDB SDK calls the Tensor9 adapter, which keeps no data of its own. PostgreSQL holds everything in one database: a table for each DynamoDB table, the ddb_tables registry, an index for each declared GSI, and a change-record table for each table with Streams enabled.

The adapter keeps no data; each DynamoDB table is its own table in one PostgreSQL database.

​
Item storage

Each DynamoDB item is one PostgreSQL row with columns pk TEXT, sk TEXT, okey TEXT and item JSONB. The PRIMARY KEY (pk, sk) index serves GetItem, and a second index over pk and byte-ordered okey serves ordered base-table Query requests. The item column keeps DynamoDB’s typed attributes, such as {"N":"123.45"}, {"B":"<b64>"} and typed sets. Numbers stay decimal strings, so a 38-digit amount or a Snowflake ID is never rounded, and a number stays distinct from a numeric string. Enabling TTL builds a PostgreSQL expression index over the configured epoch attribute in the item JSONB, and a leader-elected background worker, one adapter instance at a time, deletes expired rows through it in bounded batches. Expired items stay readable until they are deleted, because reads do not filter on TTL.
A DynamoDB item becomes one row with pk, sk, okey and item columns and PRIMARY KEY (pk, sk). The whole item is stored as JSONB in its DynamoDB form, so a number keeps its exact decimal text. The okey column keeps the sort order, and TTL uses an index over the item.A DynamoDB item becomes one row with pk, sk, okey and item columns and PRIMARY KEY (pk, sk). The whole item is stored as JSONB in its DynamoDB form, so a number keeps its exact decimal text. The okey column keeps the sort order, and TTL uses an index over the item.

Each attribute keeps its DynamoDB type tag inside item JSONB , so {“N”:“123.45”} keeps its exact decimal string.

​
Tables

Each DynamoDB table has its own PostgreSQL table, indexes and, when Streams is on, a _strm change-record table. CreateTable creates those objects and the registry entry, and DeleteTable drops them. You can tune storage, indexes and vacuum settings per table. When it creates a table, the adapter checks a limit of 500 DynamoDB tables per namespace. Concurrent creates of different tables can exceed it; it is a safeguard, not a PostgreSQL quota. Tables are not spread across database instances automatically, so plan database capacity and table placement for larger deployments. A provisioned instance costs compute while idle.
Each DynamoDB table is its own PostgreSQL table in one database, next to the ddb_tables registry and each table's indexes. The adapter allows 500 tables per namespace; larger deployments need capacity and placement planning.Each DynamoDB table is its own PostgreSQL table in one database, next to the ddb_tables registry and each table's indexes. The adapter allows 500 tables per namespace; larger deployments need capacity and placement planning.

Each DynamoDB table is its own PostgreSQL table; CreateTable and DeleteTable create and drop them.

​
Conditional writes

For a conditional write, the adapter locks the item’s row with SELECT … FOR UPDATE, checks the ConditionExpression against it, then writes and commits. The lock stops another writer from changing the item between the check and the write, at the cost of one extra round trip. For attribute_not_exists(pk), the primary key ensures that only one of two concurrent creates succeeds. A false condition returns the non-retryable ConditionalCheckFailed error and can return the item that failed it. A PostgreSQL serialization failure or lock timeout (40001 or lock-not-available) returns a retryable throughput error instead, so the SDK backs off and retries. Concurrency failures are never reported as failed conditions. Some unconditional writes skip the read: a top-level SET or REMOVE update, or an integer counter add, runs as one statement when it has no condition, asks for no returned item and touches no secondary index or stream.
A conditional write locks the row with SELECT … FOR UPDATE, evaluates the DynamoDB condition in the adapter against the locked row, then writes and commits. A false condition returns ConditionalCheckFailed; a concurrency conflict returns a retryable error, never a condition failure. The primary key prevents duplicate creates.A conditional write locks the row with SELECT … FOR UPDATE, evaluates the DynamoDB condition in the adapter against the locked row, then writes and commits. A false condition returns ConditionalCheckFailed; a concurrency conflict returns a retryable error, never a condition failure. The primary key prevents duplicate creates.

Failed conditions and PostgreSQL concurrency conflicts return different error types.

​
Secondary indexes

On each write, the adapter adds two index fields to the item’s JSONB. _idx_<name>_h holds the index partition key and treats equal numbers such as 1 and 1.0 as the same; _idx_<name>_o holds the sort key in sort order, with the base key breaking ties. A PostgreSQL index over these fields finds the items with a matching partition key, and the adapter then applies sort-key conditions, ordering, pagination and any FilterExpression. The index fields are saved in the same transaction as the item, so GSI queries are strongly consistent; DynamoDB’s own GSIs update asynchronously. One index lookup can examine at most 10,000 items for a single partition-key value, and a lookup beyond that returns an error, so choose index keys with this limit in mind.
On each write, the adapter adds two index fields to the item's JSONB, and PostgreSQL keeps an index over them. A GSI query looks up the index, then the adapter filters and orders the results. The index fields are saved with the item, so the index is strongly consistent.On each write, the adapter adds two index fields to the item's JSONB, and PostgreSQL keeps an index over them. A GSI query looks up the index, then the adapter filters and orders the results. The index fields are saved with the item, so the index is strongly consistent.

A GSI uses a PostgreSQL index to find candidates, which the adapter filters and orders; the index updates with the item.

​
Transactions

TransactWriteItems runs in one PostgreSQL transaction at SERIALIZABLE isolation: a debit in one table and a credit in another both commit or both fail, as in DynamoDB. DynamoDB’s 100-action limit and one-operation-per-item rule apply. The adapter saves the ClientRequestToken in the same transaction, so within DynamoDB’s idempotency window a retry with the same token returns the earlier success without writing again. Row locks are taken in a fixed order so opposite transfers do not deadlock, and serialization or deadlock failures return retryable conflicts. A transaction that touches a table with Streams enabled returns ValidationException before it runs, because transactions do not write stream records.
A TransactWriteItems request with a debit in one table and a credit in another commits atomically in one PostgreSQL transaction at SERIALIZABLE isolation, as on DynamoDB.A TransactWriteItems request with a debit in one table and a credit in another commits atomically in one PostgreSQL transaction at SERIALIZABLE isolation, as on DynamoDB.

TransactWriteItems runs in one PostgreSQL transaction at SERIALIZABLE isolation, atomic across tables.

​
Limitations

  • Hot keys behave differently: one PostgreSQL instance holds each table. Heavy contention on one key causes serialization failures and row-lock conflicts. The adapter returns retryable errors, but sustained contention can use up the SDK’s retry budget and appear as throttling.
  • You must run one writer per table with Streams enabled. A writer lease of about 90 seconds keeps stream records in order; a second adapter instance writing during the lease gets a retryable ThrottlingException. Throughput depends on the writer, database and workload. Tables without streams accept concurrent writers.
  • Listing more than 100 shards in DescribeStream is not supported. A stream with more shards is not fully listed in one call.
  • Transactions on tables with Streams enabled are not supported. A TransactWriteItems request touching one returns ValidationException, because transactions do not write stream records.
  • DynamoDB backup and global-table APIs are not supported. On-demand backup and restore, point-in-time recovery (PITR) and global-table replication APIs are not available. Use PostgreSQL backups, snapshots, PITR and replica failover instead.
  • Capacity behaves differently: it is provisioned and billed while idle. Size PostgreSQL capacity ahead of demand. More tables need more instances and table-placement planning.
  • Index lookups over 10,000 items are not supported. A lookup that examines more than 10,000 items for one index partition-key value returns an error.
  • You must plan around the 500-table limit. The adapter checks 500 DynamoDB tables per namespace. Larger deployments need database capacity and table-placement planning.
  • Expired items behave differently: they stay readable until deleted. A background job deletes expired rows through the TTL index in bounded batches. Until then, GetItem, Query and Scan can return the item, and it still uses storage.

​
Other considerations

  • Stream records. Each change record is saved in the table’s _strm table in the same transaction as the write, so a record exists only if its write committed. The single-writer lease keeps record order equal to commit order, so a reader can resume without skipping records.
  • Connections. The adapter pools PostgreSQL connections. With many adapter instances, you may need a separate pooler to keep total connections under the database’s limit.
  • Moving data. Move and test one table at a time, by export and import, dual writes or backfill and switch. Application code keeps using the DynamoDB API.
  • Operations. Monitor SQL activity, maintain indexes, vacuum tables and run backups, PITR and failover with your usual PostgreSQL tools.

​
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.
DynamoDB · DynamoDB read units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB read units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.
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 per second to 32 vCPU, 128 GiB memory and 100 GiB SSD at 10,000 per second. Curve assumptions
  • Writes and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Self-hosted target: PostgreSQL (PostgreSQL License, https://www.postgresql.org/about/licence/). 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 operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-271febef7b5ad970d96d5373c36c91bf2d6b17bb / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.
DynamoDB · DynamoDB write units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB write units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.
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 per second to 32 vCPU, 128 GiB memory and 100 GiB SSD at 10,000 per second. Curve assumptions
  • Reads and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Self-hosted target: PostgreSQL (PostgreSQL License, https://www.postgresql.org/about/licence/). 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 operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-271febef7b5ad970d96d5373c36c91bf2d6b17bb / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.
DynamoDB · Stored data
Feature: DynamoDB. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.
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 128 vCPU, 864 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Self-hosted target: PostgreSQL (PostgreSQL License, https://www.postgresql.org/about/licence/). 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 operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-271febef7b5ad970d96d5373c36c91bf2d6b17bb / 2026-10-22.planning.2. Curve: workload-3. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing. DynamoDB → PostgreSQL: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD. 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.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Self-hosted target: PostgreSQL (PostgreSQL License, https://www.postgresql.org/about/licence/). 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 operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
List prices read: 2026-10-22. Model: plan-271febef7b5ad970d96d5373c36c91bf2d6b17bb / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.

​
Table administration

Creating, updating and deleting tables is served by a separate control plane from the item APIs above, and it maps to each backend’s own administration surface. The two are bound together: a single control plane cannot straddle two different backends, so the backend chosen here and the backend chosen for your items are always the same one.

​
On Google Cloud

​
Via Firestore

Table administration on Google Cloud Firestore
The application’s DynamoDB client sends table-management requests to the Tensor9 adapter in the customer environment. The control endpoint and the table endpoint use the same backend database. CreateTable stores the key schema and table settings in a registry document. The table shares a Firestore collection with other logical tables. ListTables reads the registry, so it can return newly created tables before they contain any items.
Capacity settings
Firestore bills native document operations and storage. UpdateTable retains DynamoDB billing settings in the registry; those settings do not create DynamoDB-style reserved read or write capacity in Firestore.
Deletion and durable state
DeleteTable changes the registry to mark the table deleted and advances its generation number. Item reads, index entries and stream records use that generation, so recreating the same table name starts with an empty logical table even while old documents await cleanup.
Configuration and retry constraints
Physical cleanup is bounded and may leave unreachable documents behind. Those documents still consume storage until removed. Account for cleanup and Firestore document charges in environments that repeatedly create and delete large tables.
Operating the backend
The adapter stores table settings durably in Firestore and uses workload identity to access the database. Configure native backups and database access separately. Stream-enabled tables retain the single-writer requirement described for the item APIs above.
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.
DynamoDB · DynamoDB read units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB read units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.
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
  • Writes and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Firestore Standard edition in us-central1 bills document reads, writes and deletes per operation and stored GiB-months. Index-entry reads (one read per batch of up to 1,000 entries) and query fan-out belong in workload translation. Deletes bill USD 0.01 per 100,000 (one ninth of a write), but this profile has no delete rate, so deletes the workload translates as writes are overstated. The daily free quota (50,000 reads, 20,000 writes, 20,000 deletes, 1 GiB) applies only to a project’s default database and is not applied; the first 10 GiB/month of internet egress are free and are not applied.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • Firestore pricing: https://cloud.google.com/firestore/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.
  • 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-4ac0e0ca0267692d3ee4ec3549bf7a6dc8998ba8 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Firestore pricing.
DynamoDB · DynamoDB write units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB write units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.
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
  • Reads and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Firestore Standard edition in us-central1 bills document reads, writes and deletes per operation and stored GiB-months. Index-entry reads (one read per batch of up to 1,000 entries) and query fan-out belong in workload translation. Deletes bill USD 0.01 per 100,000 (one ninth of a write), but this profile has no delete rate, so deletes the workload translates as writes are overstated. The daily free quota (50,000 reads, 20,000 writes, 20,000 deletes, 1 GiB) applies only to a project’s default database and is not applied; the first 10 GiB/month of internet egress are free and are not applied.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • Firestore pricing: https://cloud.google.com/firestore/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.
  • 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-4ac0e0ca0267692d3ee4ec3549bf7a6dc8998ba8 / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Firestore pricing.
DynamoDB · Stored data
Feature: DynamoDB. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.
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
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Firestore Standard edition in us-central1 bills document reads, writes and deletes per operation and stored GiB-months. Index-entry reads (one read per batch of up to 1,000 entries) and query fan-out belong in workload translation. Deletes bill USD 0.01 per 100,000 (one ninth of a write), but this profile has no delete rate, so deletes the workload translates as writes are overstated. The daily free quota (50,000 reads, 20,000 writes, 20,000 deletes, 1 GiB) applies only to a project’s default database and is not applied; the first 10 GiB/month of internet egress are free and are not applied.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • Firestore pricing: https://cloud.google.com/firestore/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.
  • 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-4ac0e0ca0267692d3ee4ec3549bf7a6dc8998ba8 / 2026-10-22.planning.2. Curve: workload-3. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Firestore pricing. DynamoDB → Firestore: 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. 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.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Firestore Standard edition in us-central1 bills document reads, writes and deletes per operation and stored GiB-months. Index-entry reads (one read per batch of up to 1,000 entries) and query fan-out belong in workload translation. Deletes bill USD 0.01 per 100,000 (one ninth of a write), but this profile has no delete rate, so deletes the workload translates as writes are overstated. The daily free quota (50,000 reads, 20,000 writes, 20,000 deletes, 1 GiB) applies only to a project’s default database and is not applied; the first 10 GiB/month of internet egress are free and are not applied.
List prices read: 2026-10-22. Model: plan-4ac0e0ca0267692d3ee4ec3549bf7a6dc8998ba8 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Firestore pricing.

​
Via Cloud Spanner

Table administration on Google Cloud Spanner
The application’s DynamoDB client sends table-management requests to the Tensor9 adapter in the customer environment. The control endpoint and the table endpoint use the same backend database. CreateTable records the requested key and index definitions, then creates the corresponding Spanner tables and indexes. DeleteTable removes those objects. ListTables and DescribeTable use the durable table catalog.
Capacity settings
Spanner capacity belongs to the instance. DynamoDB billing-mode and throughput settings are retained as table metadata; changing them does not allocate a separate pool of Spanner processing units for that table.
Deletion and durable state
The catalog records creation and deletion before the associated schema work finishes. A retried create can resume matching unfinished work; a request with a different schema cannot reuse that unfinished creation. This makes retry behavior relevant when a client times out during a schema change.
Configuration and retry constraints
Spanner schema changes can take longer than item requests. Allow time for table creation and retain normal SDK retry handling. A deleted table must finish its recorded teardown before its name can be created again.
Operating the backend
Configure the Spanner instance, database access and backup policy for the customer environment. This control endpoint manages DynamoDB tables within that database; it does not turn per-table capacity settings into Spanner instance administration. DynamoDB Streams remain outside this mapping.
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.
DynamoDB · DynamoDB read units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB read units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.
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
  • Writes and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Spanner bills compute capacity in processing units (100 PU minimum and steps, 1,000 PU per node) whose price includes the three replicas of a regional configuration, plus SSD storage including all replicas. Capacity is sized from planning-peak reads and writes against Google’s per-node throughput; replication is built in, so the standby selection adds no copy. Enterprise (USD 1.23) and Enterprise Plus (1.71 per node-hour) editions, dual- and multi-region configurations and per-node storage limits are not selected.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • Spanner pricing: https://cloud.google.com/spanner/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.
  • 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-1f7602bf670b04f3676190fd832f3a586a145caa / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Spanner pricing.
DynamoDB · DynamoDB write units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB write units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.
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
  • Reads and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Spanner bills compute capacity in processing units (100 PU minimum and steps, 1,000 PU per node) whose price includes the three replicas of a regional configuration, plus SSD storage including all replicas. Capacity is sized from planning-peak reads and writes against Google’s per-node throughput; replication is built in, so the standby selection adds no copy. Enterprise (USD 1.23) and Enterprise Plus (1.71 per node-hour) editions, dual- and multi-region configurations and per-node storage limits are not selected.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • Spanner pricing: https://cloud.google.com/spanner/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.
  • 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-1f7602bf670b04f3676190fd832f3a586a145caa / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Spanner pricing.
DynamoDB · Stored data
Feature: DynamoDB. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.
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
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Spanner bills compute capacity in processing units (100 PU minimum and steps, 1,000 PU per node) whose price includes the three replicas of a regional configuration, plus SSD storage including all replicas. Capacity is sized from planning-peak reads and writes against Google’s per-node throughput; replication is built in, so the standby selection adds no copy. Enterprise (USD 1.23) and Enterprise Plus (1.71 per node-hour) editions, dual- and multi-region configurations and per-node storage limits are not selected.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • Spanner pricing: https://cloud.google.com/spanner/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.
  • 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-1f7602bf670b04f3676190fd832f3a586a145caa / 2026-10-22.planning.2. Curve: workload-3. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Spanner pricing. DynamoDB → Cloud Spanner: 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. 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.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Spanner bills compute capacity in processing units (100 PU minimum and steps, 1,000 PU per node) whose price includes the three replicas of a regional configuration, plus SSD storage including all replicas. Capacity is sized from planning-peak reads and writes against Google’s per-node throughput; replication is built in, so the standby selection adds no copy. Enterprise (USD 1.23) and Enterprise Plus (1.71 per node-hour) editions, dual- and multi-region configurations and per-node storage limits are not selected.
List prices read: 2026-10-22. Model: plan-1f7602bf670b04f3676190fd832f3a586a145caa / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Spanner pricing.

​
Via Cloud Bigtable

Table lifecycle
The DynamoDB adapter manages logical tables inside an existing Bigtable table. CreateTable records the table name and key schema; it does not create a Bigtable instance or allocate a separate cluster. DescribeTable and ListTables return the adapter’s table catalog. Provision the Bigtable instance, physical table, column families and single-cluster app profile before using these APIs.
Capacity and supported configuration
Bigtable cluster capacity is shared by the logical tables. Changing DynamoDB billing-mode metadata does not add Bigtable nodes or enforce provisioned read and write units. The adapter rejects secondary indexes, DynamoDB Streams and per-item TTL; selecting those options cannot make the underlying row store provide those DynamoDB behaviors.
Deletion and storage cleanup
DeleteTable removes a logical table’s visibility through the DynamoDB API. A table generation separates a recreated name from its predecessor’s rows. Logical deletion does not delete the Bigtable cluster or its shared physical table; the provisioned store remains. Plan storage cleanup and account for retained storage costs after deleting a logical table.
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.
DynamoDB · DynamoDB read units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB read units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.
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
  • Writes and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Bigtable bills whole provisioned nodes per hour, not vCPU or RAM, plus SSD storage of the compressed physical data. Nodes are sized from planning-peak reads and writes against Google’s per-node SSD throughput, with a one-node minimum. A replicated instance bills every cluster’s nodes and its own copy of the data; this profile prices one cluster, so the standby selection does not add a cluster.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • Bigtable pricing: https://cloud.google.com/bigtable/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.
  • 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-54c656ab4ad36cede3d0182c3bf9faef6669d51d / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Bigtable pricing.
DynamoDB · DynamoDB write units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB write units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.
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
  • Reads and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Bigtable bills whole provisioned nodes per hour, not vCPU or RAM, plus SSD storage of the compressed physical data. Nodes are sized from planning-peak reads and writes against Google’s per-node SSD throughput, with a one-node minimum. A replicated instance bills every cluster’s nodes and its own copy of the data; this profile prices one cluster, so the standby selection does not add a cluster.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • Bigtable pricing: https://cloud.google.com/bigtable/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.
  • 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-54c656ab4ad36cede3d0182c3bf9faef6669d51d / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Bigtable pricing.
DynamoDB · Stored data
Feature: DynamoDB. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.
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
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Bigtable bills whole provisioned nodes per hour, not vCPU or RAM, plus SSD storage of the compressed physical data. Nodes are sized from planning-peak reads and writes against Google’s per-node SSD throughput, with a one-node minimum. A replicated instance bills every cluster’s nodes and its own copy of the data; this profile prices one cluster, so the standby selection does not add a cluster.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • Bigtable pricing: https://cloud.google.com/bigtable/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.
  • 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-54c656ab4ad36cede3d0182c3bf9faef6669d51d / 2026-10-22.planning.2. Curve: workload-3. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Bigtable pricing. DynamoDB → Cloud Bigtable: 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. 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.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Bigtable bills whole provisioned nodes per hour, not vCPU or RAM, plus SSD storage of the compressed physical data. Nodes are sized from planning-peak reads and writes against Google’s per-node SSD throughput, with a one-node minimum. A replicated instance bills every cluster’s nodes and its own copy of the data; this profile prices one cluster, so the standby selection does not add a cluster.
List prices read: 2026-10-22. Model: plan-54c656ab4ad36cede3d0182c3bf9faef6669d51d / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Bigtable pricing.

​
Via Cloud SQL for PostgreSQL

Table administration on Google Cloud SQL for PostgreSQL
The application’s DynamoDB client sends table-management requests to the Tensor9 adapter in the customer environment. The control endpoint and the table endpoint use the same backend database. CreateTable creates a PostgreSQL table, its declared secondary indexes and a registry entry. A stream-enabled table also receives a change-log table. The DynamoDB endpoint serves both table administration and item requests against this same database.
Capacity settings
Cloud SQL instance size, storage and availability settings determine capacity. UpdateTable records DynamoDB billing settings without resizing the Cloud SQL instance. The adapter applies a 500-table guardrail per namespace; this is an adapter limit rather than a PostgreSQL service quota.
Deletion and durable state
Table creation writes the schema and registry in a database transaction. DeleteTable drops the item table and its change log and removes the registry and stream-owner records in the same transaction. Recreating the name therefore does not expose the deleted table’s records.
Configuration and retry constraints
Enabling time to live builds the needed PostgreSQL index before advertising the setting as enabled. The API waits for that index work while normal item reads and writes remain available. Plan schema changes with enough database capacity and request timeout allowance.
Operating the backend
Google operates the Cloud SQL database; Tensor9 operates the DynamoDB adapter and uses Cloud SQL IAM database authentication. Configure database backups and availability through Cloud SQL. The table page describes transaction behavior and stream-related restrictions.
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.
DynamoDB · DynamoDB read units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB read units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.
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 per second to 32 vCPU, 128 GiB memory and 100 GiB SSD at 10,000 per second. Curve assumptions
  • Writes and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • 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 operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-f1008577e0cf5d5cb82de2bf437390d5c3a08962 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Cloud SQL pricing.
DynamoDB · DynamoDB write units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB write units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.
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 per second to 32 vCPU, 128 GiB memory and 100 GiB SSD at 10,000 per second. Curve assumptions
  • Reads and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • 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 operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-f1008577e0cf5d5cb82de2bf437390d5c3a08962 / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Cloud SQL pricing.
DynamoDB · Stored data
Feature: DynamoDB. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.
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 96 vCPU, 624 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • 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 operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-f1008577e0cf5d5cb82de2bf437390d5c3a08962 / 2026-10-22.planning.2. Curve: workload-3. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Cloud SQL pricing. DynamoDB → Cloud SQL for PostgreSQL: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD. 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.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • 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 operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
List prices read: 2026-10-22. Model: plan-f1008577e0cf5d5cb82de2bf437390d5c3a08962 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Cloud SQL pricing.

​
On Azure

​
Via Azure Cosmos DB (provisioned)

Table administration on Azure Cosmos DB (provisioned throughput)
The application’s DynamoDB client sends table-management requests to the Tensor9 adapter in the customer environment. The control endpoint and the table endpoint use the same backend database. The deployed table uses a Cosmos DB container with an autoscale range of request units. Runtime CreateTable records logical table metadata in the configured container; it does not create another Cosmos account or a new independently sized container for every request.
Capacity settings
The provisioned backend uses an autoscale range of request units, or RUs, sized for the declared table. UpdateTable retains DynamoDB billing settings in the table registry. Change the Cosmos throughput configuration to change the actual capacity available to the container.
Deletion and durable state
The registry stores table names, key definitions and lifecycle state. DeleteTable marks the logical table deleted and advances its generation; a recreated name uses the new generation so older items are no longer reachable through it. Physical cleanup is separate from this logical deletion.
Configuration and retry constraints
Runtime CreateTable index definitions must match the deployed secondary-index configuration. The stream specification must also match the deployed configuration. Provisioned throughput can support Azure-managed global secondary indexes; plan those indexes with the deployment rather than treating runtime table creation as an unrestricted container-design API.
Operating the backend
Microsoft operates database durability, backups and availability. Tensor9 translates DynamoDB control requests and maintains the logical table registry. Native Cosmos account and container management remain separate from this endpoint; numeric precision, transactions and stream ownership are covered with the item APIs above.
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.
DynamoDB · DynamoDB read units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB read units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.
DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.
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
  • Writes and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Provisioned Cosmos DB bills reserved throughput in 100 RU/s blocks per hour, not consumed operations: planning-peak reads at 1 RU and writes at about 5.5 RU each are summed and rounded up to whole 100 RU/s blocks, with the documented 400 RU/s manual minimum (https://learn.microsoft.com/en-us/azure/cosmos-db/set-throughput). The blocks are a hard throughput limit, so they are planned at full utilization of the planning peak. Autoscale (USD 0.012 per 100 RU/s-hour, 100-1,000 RU/s entry) and the free tier (1,000 RU/s and 25 GB on one account) are not selected. Each additional region bills its own RU/s and storage.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-c920be7e617e9f0a40743bb26db180c9036769e6 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Azure Retail Prices API.
DynamoDB · DynamoDB write units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB write units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.
DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.
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
  • Reads and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Provisioned Cosmos DB bills reserved throughput in 100 RU/s blocks per hour, not consumed operations: planning-peak reads at 1 RU and writes at about 5.5 RU each are summed and rounded up to whole 100 RU/s blocks, with the documented 400 RU/s manual minimum (https://learn.microsoft.com/en-us/azure/cosmos-db/set-throughput). The blocks are a hard throughput limit, so they are planned at full utilization of the planning peak. Autoscale (USD 0.012 per 100 RU/s-hour, 100-1,000 RU/s entry) and the free tier (1,000 RU/s and 25 GB on one account) are not selected. Each additional region bills its own RU/s and storage.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-c920be7e617e9f0a40743bb26db180c9036769e6 / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Azure Retail Prices API.
DynamoDB · Stored data
Feature: DynamoDB. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.
DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.
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
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Provisioned Cosmos DB bills reserved throughput in 100 RU/s blocks per hour, not consumed operations: planning-peak reads at 1 RU and writes at about 5.5 RU each are summed and rounded up to whole 100 RU/s blocks, with the documented 400 RU/s manual minimum (https://learn.microsoft.com/en-us/azure/cosmos-db/set-throughput). The blocks are a hard throughput limit, so they are planned at full utilization of the planning peak. Autoscale (USD 0.012 per 100 RU/s-hour, 100-1,000 RU/s entry) and the free tier (1,000 RU/s and 25 GB on one account) are not selected. Each additional region bills its own RU/s and storage.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-c920be7e617e9f0a40743bb26db180c9036769e6 / 2026-10-22.planning.2. Curve: workload-3. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Azure Retail Prices API. DynamoDB → Azure Cosmos DB (provisioned): 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. 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.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Provisioned Cosmos DB bills reserved throughput in 100 RU/s blocks per hour, not consumed operations: planning-peak reads at 1 RU and writes at about 5.5 RU each are summed and rounded up to whole 100 RU/s blocks, with the documented 400 RU/s manual minimum (https://learn.microsoft.com/en-us/azure/cosmos-db/set-throughput). The blocks are a hard throughput limit, so they are planned at full utilization of the planning peak. Autoscale (USD 0.012 per 100 RU/s-hour, 100-1,000 RU/s entry) and the free tier (1,000 RU/s and 25 GB on one account) are not selected. Each additional region bills its own RU/s and storage.
List prices read: 2026-10-22. Model: plan-c920be7e617e9f0a40743bb26db180c9036769e6 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Azure Retail Prices API.

​
Via Azure Cosmos DB (serverless)

Table administration on Azure Cosmos DB (serverless)
The application’s DynamoDB client sends table-management requests to the Tensor9 adapter in the customer environment. The control endpoint and the table endpoint use the same backend database. The adapter serves table administration over a configured serverless Cosmos DB container. CreateTable registers a logical table and its key schema in that container. ListTables and DescribeTable read the stored registry rather than discovering a separate Azure resource for each logical name.
Capacity settings
Cosmos DB charges for consumed request units and storage in this backend. DynamoDB billing settings are retained as metadata; UpdateTable cannot switch the Cosmos account from serverless to provisioned throughput. Choose that operating mode when selecting the backend.
Deletion and durable state
DeleteTable hides a table by changing its registry state and advancing its generation. Recreating the same name starts a new logical generation, with old items excluded from reads and listings. Cleanup of old documents can continue after the logical deletion.
Configuration and retry constraints
Azure-managed global secondary indexes require the provisioned backend and are not offered on this serverless backend. Runtime index definitions and stream settings must match the deployed configuration. A table that needs managed global secondary indexes should select provisioned Cosmos DB before deployment.
Operating the backend
Microsoft operates the Cosmos database while Tensor9 operates the adapter. Configure native backup and account access separately. Serverless consumption billing does not remove the documented Cosmos limits on numeric precision, multi-item transactions or stream ownership.
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.
DynamoDB · DynamoDB read units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB read units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.
DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.
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
  • Writes and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Cosmos DB serverless bills consumed Request Units (USD 0.25 per million) and stored GB. Per-operation rates assume Microsoft’s published 1 KB costs: a point read is 1 RU and an unindexed insert about 5.5 RU (https://learn.microsoft.com/en-us/azure/cosmos-db/optimize-cost-reads-writes). Larger items, default indexing of every property, replaces (2x an insert) and strong or bounded-staleness reads (2x) cost more RU than these rates assume.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-193a4d8c9f7cdd8a1e2cad0fae8d95ed44aad86e / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Azure Retail Prices API.
DynamoDB · DynamoDB write units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB write units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.
DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.
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
  • Reads and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Cosmos DB serverless bills consumed Request Units (USD 0.25 per million) and stored GB. Per-operation rates assume Microsoft’s published 1 KB costs: a point read is 1 RU and an unindexed insert about 5.5 RU (https://learn.microsoft.com/en-us/azure/cosmos-db/optimize-cost-reads-writes). Larger items, default indexing of every property, replaces (2x an insert) and strong or bounded-staleness reads (2x) cost more RU than these rates assume.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-193a4d8c9f7cdd8a1e2cad0fae8d95ed44aad86e / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Azure Retail Prices API.
DynamoDB · Stored data
Feature: DynamoDB. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.
DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.
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
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Cosmos DB serverless bills consumed Request Units (USD 0.25 per million) and stored GB. Per-operation rates assume Microsoft’s published 1 KB costs: a point read is 1 RU and an unindexed insert about 5.5 RU (https://learn.microsoft.com/en-us/azure/cosmos-db/optimize-cost-reads-writes). Larger items, default indexing of every property, replaces (2x an insert) and strong or bounded-staleness reads (2x) cost more RU than these rates assume.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-193a4d8c9f7cdd8a1e2cad0fae8d95ed44aad86e / 2026-10-22.planning.2. Curve: workload-3. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Azure Retail Prices API. DynamoDB → Azure Cosmos DB (serverless): 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. 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.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Cosmos DB serverless bills consumed Request Units (USD 0.25 per million) and stored GB. Per-operation rates assume Microsoft’s published 1 KB costs: a point read is 1 RU and an unindexed insert about 5.5 RU (https://learn.microsoft.com/en-us/azure/cosmos-db/optimize-cost-reads-writes). Larger items, default indexing of every property, replaces (2x an insert) and strong or bounded-staleness reads (2x) cost more RU than these rates assume.
List prices read: 2026-10-22. Model: plan-193a4d8c9f7cdd8a1e2cad0fae8d95ed44aad86e / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Azure Retail Prices API.

​
On OCI

Infrastructure mapping
Tensor9 converts the declared aws_dynamodb_table to an oci_nosql_table in the customer’s OCI compartment. This is the infrastructure-only adaptation: it provisions storage but does not provide an AWS DynamoDB endpoint. Application reads, writes, queries and runtime table administration use OCI NoSQL APIs. The table and control pages describe this same backend choice.
Keys and item data
The DynamoDB partition key becomes the OCI SHARD key. An optional sort key becomes the second primary-key column. String, number and binary key types become corresponding OCI column types; other item attributes occupy a value JSON column. Adapt queries and serialization to that layout rather than sending DynamoDB attribute documents directly.
Capacity and storage
PAY_PER_REQUEST selects OCI ON_DEMAND; provisioned DynamoDB capacity selects OCI PROVISIONED settings. OCI read and write units differ from DynamoDB units, so validate them against the workload. OCI also requires an explicit storage cap. Increase that cap before data reaches it; the source DynamoDB table had no equivalent fixed cap.
Indexes, expiry and integrations
The current infrastructure mapping does not create declared GSIs or LSIs. Configure native OCI indexes and update the application’s access patterns. A source TTL declaration produces a no-expiry default; its per-item epoch attribute is not translated into automatic expiry. DynamoDB Streams, AWS PITR configuration, source KMS key references and replica settings are not reproduced by this table resource. Configure the corresponding backend data-protection and event requirements separately.
Migration and operation
The new table starts empty. Convert application access, load the data, and test key lookups, queries, expiry and recovery before switching traffic. Oracle operates the NoSQL service; the customer manages compartment access, capacity, storage limits and the chosen recovery procedures. Use a different listed adaptation when the application must keep runtime DynamoDB API calls.
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. Native or deployment mapping. The mapping provisions OCI NoSQL tables without exposing a DynamoDB management endpoint. There is no DynamoDB request-serving fabric on this path. Cost estimates describe the selected service resources; operation coverage remains separate.
DynamoDB · DynamoDB read units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB read units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1 (global list); currency: USD.
DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.
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
  • Writes and storage remain independent. 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.
  • Native/deployment comparison scope: The mapping provisions OCI NoSQL tables without exposing a DynamoDB management endpoint. There is no DynamoDB request-serving fabric on this path.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Oracle NoSQL Database Cloud on-demand capacity bills consumed 1 KB read and write units and stored GB. Absolute-consistency reads cost two read units; larger records cost one unit per KB. Provisioned capacity (USD 0.0064 per read unit-month and 0.1254 per write unit-month, parts B89738 and B89737) and the Always Free tables are not selected.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • OCI price list API: https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/
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.
  • 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-a45d0e6d8b183b039aefa956c723cea5c9269d3d / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, OCI price list API.
DynamoDB · DynamoDB write units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB write units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1 (global list); currency: USD.
DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.
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
  • Reads and storage remain independent. 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.
  • Native/deployment comparison scope: The mapping provisions OCI NoSQL tables without exposing a DynamoDB management endpoint. There is no DynamoDB request-serving fabric on this path.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Oracle NoSQL Database Cloud on-demand capacity bills consumed 1 KB read and write units and stored GB. Absolute-consistency reads cost two read units; larger records cost one unit per KB. Provisioned capacity (USD 0.0064 per read unit-month and 0.1254 per write unit-month, parts B89738 and B89737) and the Always Free tables are not selected.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • OCI price list API: https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/
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.
  • 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-a45d0e6d8b183b039aefa956c723cea5c9269d3d / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, OCI price list API.
DynamoDB · Stored data
Feature: DynamoDB. 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.
DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.
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
  • 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.
  • Native/deployment comparison scope: The mapping provisions OCI NoSQL tables without exposing a DynamoDB management endpoint. There is no DynamoDB request-serving fabric on this path.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Oracle NoSQL Database Cloud on-demand capacity bills consumed 1 KB read and write units and stored GB. Absolute-consistency reads cost two read units; larger records cost one unit per KB. Provisioned capacity (USD 0.0064 per read unit-month and 0.1254 per write unit-month, parts B89738 and B89737) and the Always Free tables are not selected.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • OCI price list API: https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/
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.
  • 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-a45d0e6d8b183b039aefa956c723cea5c9269d3d / 2026-10-22.planning.2. Curve: workload-3. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, OCI price list API. DynamoDB → OCI NoSQL Database: 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. 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.
  • 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.
  • Native/deployment comparison scope: The mapping provisions OCI NoSQL tables without exposing a DynamoDB management endpoint. There is no DynamoDB request-serving fabric on this path.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Oracle NoSQL Database Cloud on-demand capacity bills consumed 1 KB read and write units and stored GB. Absolute-consistency reads cost two read units; larger records cost one unit per KB. Provisioned capacity (USD 0.0064 per read unit-month and 0.1254 per write unit-month, parts B89738 and B89737) and the Always Free tables are not selected.
List prices read: 2026-10-22. Model: plan-a45d0e6d8b183b039aefa956c723cea5c9269d3d / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, OCI price list API.

​
On Private Kubernetes

Table administration on Tensor9-managed PostgreSQL
The application’s DynamoDB client sends table-management requests to the Tensor9 adapter in the customer environment. The control endpoint and the table endpoint use the same backend database. Tensor9 deploys PostgreSQL with the appliance and serves the DynamoDB control API through the adapter. CreateTable creates the item table, secondary indexes and registry metadata inside that database. Applications continue to use DynamoDB table names and key definitions.
Capacity settings
Capacity comes from the database resources allocated in the customer environment. DynamoDB billing-mode changes remain table metadata and do not resize the deployment. The adapter applies a 500-table guardrail per namespace, so deployments with larger table fleets need a different layout or backend.
Deletion and durable state
Creation writes the table schema and registry together in a PostgreSQL transaction. Deletion drops the item table and its stream change log and removes table metadata and stream-owner records in the same transaction. ListTables reports the surviving registry entries.
Configuration and retry constraints
Time-to-live configuration builds the required index before enabling expiry. Table creation, deletion and index work consume the same database resources used by item requests. Size the deployment for both schema changes and steady application traffic.
Operating the backend
Tensor9 operates this database within the appliance, including disconnected deployments, rather than relying on a cloud-managed PostgreSQL service. Storage durability, backup and recovery depend on the appliance configuration and available customer infrastructure. The DynamoDB table contract remains the same PostgreSQL-backed contract described for the managed backend. Registry version 1.0.0 is not the database version. Qualify the selected PostgreSQL image/version, DynamoDB SIP revision, schema and coupled control/table configuration; this profile does not establish an installed version or Kubernetes readiness, and SQS qualification does not qualify DynamoDB.
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.
DynamoDB · DynamoDB read units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB read units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.DynamoDB · DynamoDB read units: monthly service charges by DynamoDB read units. Exact values are in the following table.
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 per second to 32 vCPU, 128 GiB memory and 100 GiB SSD at 10,000 per second. Curve assumptions
  • Writes and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Self-hosted target: PostgreSQL (PostgreSQL License, https://www.postgresql.org/about/licence/). 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 operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-67ab648398db063f54620ef99fe9513d4263793e / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.
DynamoDB · DynamoDB write units
Feature: DynamoDB. Estimated monthly service charges by DynamoDB write units. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.DynamoDB · DynamoDB write units: monthly service charges by DynamoDB write units. Exact values are in the following table.
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 per second to 32 vCPU, 128 GiB memory and 100 GiB SSD at 10,000 per second. Curve assumptions
  • Reads and storage remain independent. 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Self-hosted target: PostgreSQL (PostgreSQL License, https://www.postgresql.org/about/licence/). 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 operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-67ab648398db063f54620ef99fe9513d4263793e / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.
DynamoDB · Stored data
Feature: DynamoDB. Estimated monthly service charges by Stored data. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.DynamoDB · Stored data: monthly service charges by Stored data. Exact values are in the following table.
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 128 vCPU, 864 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Self-hosted target: PostgreSQL (PostgreSQL License, https://www.postgresql.org/about/licence/). 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 operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • AWS Price List API, AmazonDynamoDB offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonDynamoDB/current/us-east-1/index.json
  • Amazon DynamoDB pricing: https://aws.amazon.com/dynamodb/pricing/
  • 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.
  • 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-67ab648398db063f54620ef99fe9513d4263793e / 2026-10-22.planning.2. Curve: workload-3. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing. DynamoDB → PostgreSQL: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD. 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.
  • 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.
  • The control plane and table facet describe the same family workload; allocate shared capacity once, not once per catalog facet.
  • No transactional, global-table, Streams or scan pricing is inferred from ordinary on-demand point units.
  • Self-hosted target: PostgreSQL (PostgreSQL License, https://www.postgresql.org/about/licence/). 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 operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
List prices read: 2026-10-22. Model: plan-67ab648398db063f54620ef99fe9513d4263793e / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonDynamoDB offer, Amazon DynamoDB pricing, 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 DynamoDB costs.

​
Service level agreements

These tables show Tensor9’s standard service levels and adapters whose standard terms are still being defined. Your signed agreement determines the SLAs, covered adapters and operations, limits, remedies and support terms that apply to your deployment.
Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider’s own SLA. Each origin-to-target pair has its own terms or an explicit pending status. See the SLA tables, measurement rules, and scaling conditions.

​
DynamoDB to Azure Cosmos DB (provisioned)

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::cosmosdb::provisioned, Cosmos stores typed items in documents. Updates may use conditional PATCH, a partition-scoped stored procedure, or an ETag-guarded read/modify/write. Query windows and partition boundaries matter. Provisioned and serverless accounts retain their distinct throughput and index restrictions. The 1 ms point-operation objective is deliberately narrow. A conditional write, scanned page, transaction or control-plane request uses its own row. Stored procedures or SQL that implement the application operation are target execution; adapter catalog, coordination and retry work must not be mislabeled as application-database wait.

​
How the latency targets were chosen

Table and configuration API responses: +20 ms monthly p99 (adapter-added). CreateTable, DeleteTable, DescribeTable, ListTables, UpdateTable. Logical-table catalogs and lifecycle state must be persisted and validated. Their storage latency is adapter work even when the catalog uses the same database as application items. 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

Watch adapter CPU and allocation rate alongside target read/write capacity, partition hot spots and connection/session limits. Scale adapter replicas on outstanding work, not QPS alone: a 100-item scan and a GetItem differ substantially. Tensor9 is responsible for autoscaling within the agreed per-operation concurrency, item-size, page and burst limits. The customer selects and sizes the target, including Cosmos RU/s, Spanner capacity or SQL connections; scaling the adapter cannot remove a hot partition or a database quota. 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

Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.

​
Example and diagnosis

In orders, GetItem for a 3 KiB item uses the point-read row. Query that examines 90 items but returns only two still uses the page row. An UpdateItem with a version condition uses the conditional-write row. In Explain, compare adapter expression/planning/serialization work with the measured target operation; a rise in Cosmos throttling or Spanner execution time is different from a rise in adapter queueing or catalog lookups. 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.

​
DynamoDB to Azure Cosmos DB (serverless)

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::cosmosdb::serverless, Cosmos stores typed items in documents. Updates may use conditional PATCH, a partition-scoped stored procedure, or an ETag-guarded read/modify/write. Query windows and partition boundaries matter. Provisioned and serverless accounts retain their distinct throughput and index restrictions. The 1 ms point-operation objective is deliberately narrow. A conditional write, scanned page, transaction or control-plane request uses its own row. Stored procedures or SQL that implement the application operation are target execution; adapter catalog, coordination and retry work must not be mislabeled as application-database wait.

​
How the latency targets were chosen

Table and configuration API responses: +20 ms monthly p99 (adapter-added). CreateTable, DeleteTable, DescribeTable, ListTables, UpdateTable. Logical-table catalogs and lifecycle state must be persisted and validated. Their storage latency is adapter work even when the catalog uses the same database as application items. 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

Watch adapter CPU and allocation rate alongside target read/write capacity, partition hot spots and connection/session limits. Scale adapter replicas on outstanding work, not QPS alone: a 100-item scan and a GetItem differ substantially. Tensor9 is responsible for autoscaling within the agreed per-operation concurrency, item-size, page and burst limits. The customer selects and sizes the target, including Cosmos RU/s, Spanner capacity or SQL connections; scaling the adapter cannot remove a hot partition or a database quota. 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

Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.

​
Example and diagnosis

In orders, GetItem for a 3 KiB item uses the point-read row. Query that examines 90 items but returns only two still uses the page row. An UpdateItem with a version condition uses the conditional-write row. In Explain, compare adapter expression/planning/serialization work with the measured target operation; a rise in Cosmos throttling or Spanner execution time is different from a rise in adapter queueing or catalog lookups. 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.

​
DynamoDB to Cloud Bigtable

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::bigtable, Items use row-atomic Bigtable storage. Multi-item transactions and unsupported secondary-index/stream semantics do not become covered merely because point reads are covered. The 1 ms point-operation objective is deliberately narrow. A conditional write, scanned page, transaction or control-plane request uses its own row. Stored procedures or SQL that implement the application operation are target execution; adapter catalog, coordination and retry work must not be mislabeled as application-database wait.

​
How the latency targets were chosen

Table and configuration API responses: +20 ms monthly p99 (adapter-added). CreateTable, DeleteTable, DescribeTable, ListTables, UpdateTable. Logical-table catalogs and lifecycle state must be persisted and validated. Their storage latency is adapter work even when the catalog uses the same database as application items. 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

Watch adapter CPU and allocation rate alongside target read/write capacity, partition hot spots and connection/session limits. Scale adapter replicas on outstanding work, not QPS alone: a 100-item scan and a GetItem differ substantially. Tensor9 is responsible for autoscaling within the agreed per-operation concurrency, item-size, page and burst limits. The customer selects and sizes the target, including Cosmos RU/s, Spanner capacity or SQL connections; scaling the adapter cannot remove a hot partition or a database quota. 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

Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.

​
Example and diagnosis

In orders, GetItem for a 3 KiB item uses the point-read row. Query that examines 90 items but returns only two still uses the page row. An UpdateItem with a version condition uses the conditional-write row. In Explain, compare adapter expression/planning/serialization work with the measured target operation; a rise in Cosmos throttling or Spanner execution time is different from a rise in adapter queueing or catalog lookups. 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.

​
DynamoDB 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, The SQL-backed adapter maps items, expressions and indexes onto relational rows and transactions. Row locks, index maintenance, stream outboxes and transaction conflict handling can add work beyond a single statement. The 1 ms point-operation objective is deliberately narrow. A conditional write, scanned page, transaction or control-plane request uses its own row. Stored procedures or SQL that implement the application operation are target execution; adapter catalog, coordination and retry work must not be mislabeled as application-database wait.

​
How the latency targets were chosen

Table and configuration API responses: +20 ms monthly p99 (adapter-added). CreateTable, DeleteTable, DescribeTable, ListTables, UpdateTable. Logical-table catalogs and lifecycle state must be persisted and validated. Their storage latency is adapter work even when the catalog uses the same database as application items. 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

Watch adapter CPU and allocation rate alongside target read/write capacity, partition hot spots and connection/session limits. Scale adapter replicas on outstanding work, not QPS alone: a 100-item scan and a GetItem differ substantially. Tensor9 is responsible for autoscaling within the agreed per-operation concurrency, item-size, page and burst limits. The customer selects and sizes the target, including Cosmos RU/s, Spanner capacity or SQL connections; scaling the adapter cannot remove a hot partition or a database quota. 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

Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.

​
Example and diagnosis

In orders, GetItem for a 3 KiB item uses the point-read row. Query that examines 90 items but returns only two still uses the page row. An UpdateItem with a version condition uses the conditional-write row. In Explain, compare adapter expression/planning/serialization work with the measured target operation; a rise in Cosmos throttling or Spanner execution time is different from a rise in adapter queueing or catalog lookups. 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.

​
DynamoDB to Firestore

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::firestore, The adapter translates typed items to Firestore documents and uses the documented transactional behavior. Residual filtering, pagination and index choices determine how many documents the adapter must inspect for one DynamoDB response. The 1 ms point-operation objective is deliberately narrow. A conditional write, scanned page, transaction or control-plane request uses its own row. Stored procedures or SQL that implement the application operation are target execution; adapter catalog, coordination and retry work must not be mislabeled as application-database wait.

​
How the latency targets were chosen

Table and configuration API responses: +20 ms monthly p99 (adapter-added). CreateTable, DeleteTable, DescribeTable, ListTables, UpdateTable. Logical-table catalogs and lifecycle state must be persisted and validated. Their storage latency is adapter work even when the catalog uses the same database as application items. 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

Watch adapter CPU and allocation rate alongside target read/write capacity, partition hot spots and connection/session limits. Scale adapter replicas on outstanding work, not QPS alone: a 100-item scan and a GetItem differ substantially. Tensor9 is responsible for autoscaling within the agreed per-operation concurrency, item-size, page and burst limits. The customer selects and sizes the target, including Cosmos RU/s, Spanner capacity or SQL connections; scaling the adapter cannot remove a hot partition or a database quota. 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

Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.

​
Example and diagnosis

In orders, GetItem for a 3 KiB item uses the point-read row. Query that examines 90 items but returns only two still uses the page row. An UpdateItem with a version condition uses the conditional-write row. In Explain, compare adapter expression/planning/serialization work with the measured target operation; a rise in Cosmos throttling or Spanner execution time is different from a rise in adapter queueing or catalog lookups. 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.

​
DynamoDB to Cloud Spanner

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::spanner, The adapter lowers DynamoDB reads and writes into GoogleSQL and Spanner physical plans. Simple point calls differ from expression evaluation, secondary-index maintenance and transaction planning. Table DDL is asynchronous and has a separate control-plane path. The 1 ms point-operation objective is deliberately narrow. A conditional write, scanned page, transaction or control-plane request uses its own row. Stored procedures or SQL that implement the application operation are target execution; adapter catalog, coordination and retry work must not be mislabeled as application-database wait.

​
How the latency targets were chosen

Table and configuration API responses: +20 ms monthly p99 (adapter-added). CreateTable, DeleteTable, DescribeTable, ListTables, UpdateTable. Logical-table catalogs and lifecycle state must be persisted and validated. Their storage latency is adapter work even when the catalog uses the same database as application items. 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

Watch adapter CPU and allocation rate alongside target read/write capacity, partition hot spots and connection/session limits. Scale adapter replicas on outstanding work, not QPS alone: a 100-item scan and a GetItem differ substantially. Tensor9 is responsible for autoscaling within the agreed per-operation concurrency, item-size, page and burst limits. The customer selects and sizes the target, including Cosmos RU/s, Spanner capacity or SQL connections; scaling the adapter cannot remove a hot partition or a database quota. 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

Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.

​
Example and diagnosis

In orders, GetItem for a 3 KiB item uses the point-read row. Query that examines 90 items but returns only two still uses the page row. An UpdateItem with a version condition uses the conditional-write row. In Explain, compare adapter expression/planning/serialization work with the measured target operation; a rise in Cosmos throttling or Spanner execution time is different from a rise in adapter queueing or catalog lookups. 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.

​
DynamoDB to OCI NoSQL Database

SLA status: Not applicable The mapping provisions OCI NoSQL tables without exposing a DynamoDB management endpoint. There is no DynamoDB request-serving fabric on this path.

​
DynamoDB to 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 postgres::1.0.0::database, The SQL-backed adapter maps items, expressions and indexes onto relational rows and transactions. Row locks, index maintenance, stream outboxes and transaction conflict handling can add work beyond a single statement. The 1 ms point-operation objective is deliberately narrow. A conditional write, scanned page, transaction or control-plane request uses its own row. Stored procedures or SQL that implement the application operation are target execution; adapter catalog, coordination and retry work must not be mislabeled as application-database wait.

​
How the latency targets were chosen

Table and configuration API responses: +20 ms monthly p99 (adapter-added). CreateTable, DeleteTable, DescribeTable, ListTables, UpdateTable. Logical-table catalogs and lifecycle state must be persisted and validated. Their storage latency is adapter work even when the catalog uses the same database as application items. 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

Watch adapter CPU and allocation rate alongside target read/write capacity, partition hot spots and connection/session limits. Scale adapter replicas on outstanding work, not QPS alone: a 100-item scan and a GetItem differ substantially. Tensor9 is responsible for autoscaling within the agreed per-operation concurrency, item-size, page and burst limits. The customer selects and sizes the target, including Cosmos RU/s, Spanner capacity or SQL connections; scaling the adapter cannot remove a hot partition or a database quota. 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

Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.

​
Example and diagnosis

In orders, GetItem for a 3 KiB item uses the point-read row. Query that examines 90 items but returns only two still uses the page row. An UpdateItem with a version condition uses the conditional-write row. In Explain, compare adapter expression/planning/serialization work with the measured target operation; a rise in Cosmos throttling or Spanner execution time is different from a rise in adapter queueing or catalog lookups. 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.

​
DynamoDB to Provisioned Cosmos DB

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. Latency targets measure the time Tensor9’s adapter adds to backend processing, not the application’s total elapsed time. They do not replace the backend provider’s SLA. Adapter time covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the backend service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Correct data and authorization behavior is required for every supported request; endpoint reachability does not excuse incorrect results. DynamoDB write limits. A plain write has no ConditionExpression or legacy Expected, no returned old item (ReturnValues absent or NONE), and streams disabled. The index configuration must be covered by your agreement. Size limits include the full current item and any previous item the adapter must read. For a delete that does not read the old item, count the key and request size. Writes with streams enabled need a separate latency agreement. Table management, PartiQL and Streams operations are not covered here. Any smaller API limit still applies. Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, backend configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for backend-service capacity; failures caused independently by the provider are outside this SLA. Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment.

​
Why these latency targets differ

Plain GetItem, PutItem and DeleteItem have a 1 ms target for the small-item shape. Plain writes exclude conditions, old-value returns, secondary-index maintenance and streams. Update/conditional requests have 5 ms because the implementation may select PATCH, a partition-scoped stored procedure or an ETag-guarded read/modify/write path. Expressions are bounded to 2 KiB and 20 clauses, with at most two maintained indexes. Query/Scan has 10 ms for a page of at most 100 examined items and 400 KiB; item batches have 20 ms for at most 100 items, subject to each API’s smaller limit. Native Cosmos document execution is measured separately. Residual filtering, retries, response conversion and adapter-owned metadata remain fabric work. The adapter target does not imply Cosmos returns in 1 ms or that provisioned-account terms apply to a serverless account. Conditional conflicts and throttling still require correct handling, even when they move a request outside a tightly bounded latency class.

​
Adapter and scope

These standard terms cover the DynamoDB table API adapted to provisioned Azure Cosmos DB. They do not apply interchangeably to a serverless Cosmos DB backend or the Cosmos DB queue adapter. Your signed agreement determines the Cosmos DB consistency setting, capacity and partition configuration, deployment requirements, and covered request sizes and traffic levels.

​
Operations and latency

The operation terms below concern GetItem, PutItem, DeleteItem, UpdateItem, Query, Scan, BatchGetItem and BatchWriteItem, with the request options supported by the adapter. Larger supported requests retain their documented behavior without inheriting the latency rows’ size limits or targets. TransactWriteItems, TransactGetItems and ExecuteTransaction are outside this adapter’s supported transaction scope and have no SLA here. Table lifecycle, PartiQL and DynamoDB Streams operations are not covered by these terms. A supported ExecuteStatement or BatchExecuteStatement does not inherit another operation’s SLA because it performs related item work.
Which writes are covered
A plain write has no ConditionExpression or legacy Expected condition, ReturnValues absent or NONE, streams disabled, and the indexes specified in the agreement. Conditional writes and writes requesting supported previous-item values use the conditional-update class. UpdateItem uses that class regardless of how short its update expression looks. Count the full items the adapter reads or changes, including previous items loaded to check conditions or return old values. Returning only a few fields through a DynamoDB projection does not make a larger item meet the size limit. For a plain delete that does not read the old item, the 4 KiB limit applies to the key and request. Writes with streams enabled, and other supported request options outside these limits, need separately agreed latency targets. Sharing an operation name does not give them the same guarantee.
Which queries and batches are covered
To check whether a query meets the latency limits, record whether it reads the base table, an LSI or a GSI, its consistency mode, the items examined, and the data the adapter loaded. Filtering can discard many items before returning a small page. A small result does not prove that the request met those limits. Each batch API retains its own smaller item and payload limits. Preserve per-item outcomes and unprocessed entries. A batch response is one API result, not proof that every submitted read or write succeeded.

​
Timing and responsibility

Adapter processing time includes authorization, encoding, expression processing, local queues, retries, coordination and response transformation. Native stored-procedure execution and attributable provider waits are measured separately. That timing separation does not remove responsibility for Tensor9-authored behavior executing at the backend. An incorrect stored procedure, bad mapping or unnecessary expensive request remains an adapter issue even when Azure reports the resulting error or execution time. A correctly reported failed condition is healthy request handling. Returning success too early, losing a response, or making the wrong change is an adapter failure. After a timeout, the write may have succeeded. Do not claim it failed unless that has been established.

​
Durability and consistency

The adapter may return success only after Cosmos DB has committed the change within its partition and the adapter has saved the required metadata or pending follow-up work. A supported condition check and its change must succeed or fail together within the scope the adapter supports. Keeping changes within one partition atomic does not imply support for DynamoDB multi-item transactions. The adapter must never silently weaken a condition, lose adapter state already reported as saved or corrupt an item. GSI replication and adapter-owned stream state are different mechanisms. Ordinary eventual GSI lag does not excuse an incorrect index mapping or lost committed stream state. Table deletion and recreation do not acquire an instantaneous cleanup guarantee from the item-operation terms.

​
Scaling and backend sizing

The standard production model automatically adds adapter capacity within the agreement’s workload limits. Delays in adding capacity within those limits still count toward adapter latency. Provisioned Cosmos DB still needs an appropriate RU allocation, consistency mode and partition distribution. Record whether capacity uses manual or provider autoscale RU/s and which logical tables share a container. The same RU allocation does not guarantee the same origin-operation rate for every workload. Independent partitions can support parallel work. Hot partitions, shared container consumers, local expression processing, retry amplification and stream-writer ownership can constrain completed operations. More adapter instances cannot create more backend RUs or remove per-key serialization. No numerical maximum request rate is assigned here. A supported limit needs the exact mix, item and expression sizes, index and stream settings, key distribution, backend capacity and partition configuration, allowed traffic bursts and spare capacity for failures. It must measure useful completed origin operations, not a growing number of native retry attempts.

​
Worked example: update an order

The orders table receives an UpdateItem with a condition on its current version. The full item and expression fit the conditional-update class.
  1. The adapter interprets the condition and prepares the supported partition-local mutation. This preparation is adapter work.
  2. Cosmos DB executes the native mutation. Native execution time and request charge help explain backend cost and delay.
  3. The adapter returns the origin-shaped result. Local retry and response handling remain part of the conditional-update adapter latency target.
A subsequent GSI query may observe the change later under the eventual index contract. That delay does not by itself establish corruption or failure of the item update.

​
Worked example: throttling during a traffic increase

Suppose 429 responses increase. Inspect RU consumption, partition pressure and competing workloads in the shared container. Then compare native calls per completed update, local retry delays and the selected mutation path. Backend undersizing can require a capacity or workload change. If the adapter issues unnecessary requests or ignores supported tuning, the resulting pressure remains a Tensor9 issue. An Azure 429 response alone does not tell you whether Azure capacity or adapter behavior caused the problem. If a base read sees the committed item but a GSI does not, inspect index lag and mapping separately from throttling. Do not blindly repeat the write to make the index catch up.

​
Evidence for support

Keep the operation, table and index path, account consistency, configured RU mode, full item and expression sizes, request charge where available, status, identifiers and incident timestamps. Include relevant shared-container and hot-partition observations, with recent tuning changes. Use tensor9 explain for profile behavior and a safely captured request report for observed mapping. x-t9-explain: true executes the operation; do not replay a conditional mutation just to gather a report. An explanation is not proof that a write committed, or a continuous measurement of SLA compliance. Remove tokens, keys, credentials and sensitive item values before sharing evidence. Tensor9 helps separate backend pressure, mapping behavior and adapter processing without requiring you to prove fault first.

​
DynamoDB to Azure Cosmos DB (serverless)

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::cosmosdb::serverless, Cosmos stores typed items in documents. Updates may use conditional PATCH, a partition-scoped stored procedure, or an ETag-guarded read/modify/write. Query windows and partition boundaries matter. Provisioned and serverless accounts retain their distinct throughput and index restrictions. The 1 ms point-operation objective is deliberately narrow. A conditional write, scanned page, transaction or control-plane request uses its own row. Stored procedures or SQL that implement the application operation are target execution; adapter catalog, coordination and retry work must not be mislabeled as application-database wait.

​
How the latency targets were chosen

Small point reads: +1 ms monthly p99 (adapter-added). GetItem. Key decoding, one physical-plan construction and bounded item conversion. The target database’s own response time is separate. Plain small-item writes: +1 ms monthly p99 (adapter-added). DeleteItem, PutItem. The simple write avoids expression evaluation, read/modify/write and index/outbox amplification. Conditional writes and updates: +5 ms monthly p99 (adapter-added). DeleteItem, PutItem, UpdateItem. Expression parsing, update evaluation and result construction add CPU work; guarded updates can repeat local work after target conflicts. Bounded query and scan pages: +10 ms monthly p99 (adapter-added). Query, Scan. Physical query planning, item decoding, filters, ordering and cursor generation scale with the examined page, including rows the response omits. Bounded item batches: +10 ms monthly p99 (adapter-added). BatchGetItem, BatchWriteItem. The adapter builds and schedules item plans and assembles partial results; target-call fan-out is not free even when target waits are excluded. Bounded PartiQL statements: +10 ms monthly p99 (adapter-added). BatchExecuteStatement, ExecuteStatement. PartiQL adds parse, validate and lowering stages before ordinary item execution; a statement is not automatically a point lookup. DynamoDB Streams reads: +10 ms monthly p99 (adapter-added). DescribeStream, GetRecords, GetShardIterator, ListStreams. The adapter reads its stream/outbox representation and converts records, versions and cursors. Adapter-owned stream metadata waits remain on the clock. Table and configuration API responses: +20 ms monthly p99 (adapter-added). CreateTable, DeleteTable, DescribeContinuousBackups, DescribeEndpoints, DescribeLimits, DescribeTable, DescribeTimeToLive, ListTables, ListTagsOfResource, TagResource, UntagResource, UpdateContinuousBackups, UpdateTable, UpdateTimeToLive. Logical-table catalogs and lifecycle state must be persisted and validated. Their storage latency is adapter work even when the catalog uses the same database as application items. 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

Watch adapter CPU and allocation rate alongside target read/write capacity, partition hot spots and connection/session limits. Scale adapter replicas on outstanding work, not QPS alone: a 100-item scan and a GetItem differ substantially. Tensor9 is responsible for autoscaling within the agreed per-operation concurrency, item-size, page and burst limits. The customer selects and sizes the target, including Cosmos RU/s, Spanner capacity or SQL connections; scaling the adapter cannot remove a hot partition or a database quota. 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

Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.

​
Example and diagnosis

In orders, GetItem for a 3 KiB item uses the point-read row. Query that examines 90 items but returns only two still uses the page row. An UpdateItem with a version condition uses the conditional-write row. In Explain, compare adapter expression/planning/serialization work with the measured target operation; a rise in Cosmos throttling or Spanner execution time is different from a rise in adapter queueing or catalog lookups. 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.

​
DynamoDB to Cloud Bigtable

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::bigtable, Items use row-atomic Bigtable storage. Multi-item transactions and unsupported secondary-index/stream semantics do not become covered merely because point reads are covered. The 1 ms point-operation objective is deliberately narrow. A conditional write, scanned page, transaction or control-plane request uses its own row. Stored procedures or SQL that implement the application operation are target execution; adapter catalog, coordination and retry work must not be mislabeled as application-database wait.

​
How the latency targets were chosen

Small point reads: +1 ms monthly p99 (adapter-added). GetItem. Key decoding, one physical-plan construction and bounded item conversion. The target database’s own response time is separate. Plain small-item writes: +1 ms monthly p99 (adapter-added). DeleteItem, PutItem. The simple write avoids expression evaluation, read/modify/write and index/outbox amplification. Conditional writes and updates: +3 ms monthly p99 (adapter-added). DeleteItem, PutItem, UpdateItem. Expression parsing, update evaluation and result construction add CPU work; guarded updates can repeat local work after target conflicts. Bounded query and scan pages: +5 ms monthly p99 (adapter-added). Query, Scan. Physical query planning, item decoding, filters, ordering and cursor generation scale with the examined page, including rows the response omits. Bounded item batches: +10 ms monthly p99 (adapter-added). BatchGetItem, BatchWriteItem. The adapter builds and schedules item plans and assembles partial results; target-call fan-out is not free even when target waits are excluded. Table and configuration API responses: +20 ms monthly p99 (adapter-added). CreateTable, DeleteTable, DescribeTable, ListTables, UpdateTable. Logical-table catalogs and lifecycle state must be persisted and validated. Their storage latency is adapter work even when the catalog uses the same database as application items. 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

Watch adapter CPU and allocation rate alongside target read/write capacity, partition hot spots and connection/session limits. Scale adapter replicas on outstanding work, not QPS alone: a 100-item scan and a GetItem differ substantially. Tensor9 is responsible for autoscaling within the agreed per-operation concurrency, item-size, page and burst limits. The customer selects and sizes the target, including Cosmos RU/s, Spanner capacity or SQL connections; scaling the adapter cannot remove a hot partition or a database quota. 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

Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.

​
Example and diagnosis

In orders, GetItem for a 3 KiB item uses the point-read row. Query that examines 90 items but returns only two still uses the page row. An UpdateItem with a version condition uses the conditional-write row. In Explain, compare adapter expression/planning/serialization work with the measured target operation; a rise in Cosmos throttling or Spanner execution time is different from a rise in adapter queueing or catalog lookups. 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.

​
DynamoDB 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, The SQL-backed adapter maps items, expressions and indexes onto relational rows and transactions. Row locks, index maintenance, stream outboxes and transaction conflict handling can add work beyond a single statement. The 1 ms point-operation objective is deliberately narrow. A conditional write, scanned page, transaction or control-plane request uses its own row. Stored procedures or SQL that implement the application operation are target execution; adapter catalog, coordination and retry work must not be mislabeled as application-database wait.

​
How the latency targets were chosen

Small point reads: +1 ms monthly p99 (adapter-added). GetItem. Key decoding, one physical-plan construction and bounded item conversion. The target database’s own response time is separate. Plain small-item writes: +1 ms monthly p99 (adapter-added). DeleteItem, PutItem. The simple write avoids expression evaluation, read/modify/write and index/outbox amplification. Conditional writes and updates: +3 ms monthly p99 (adapter-added). DeleteItem, PutItem, UpdateItem. Expression parsing, update evaluation and result construction add CPU work; guarded updates can repeat local work after target conflicts. Bounded query and scan pages: +5 ms monthly p99 (adapter-added). Query, Scan. Physical query planning, item decoding, filters, ordering and cursor generation scale with the examined page, including rows the response omits. Bounded item batches: +10 ms monthly p99 (adapter-added). BatchGetItem, BatchWriteItem. The adapter builds and schedules item plans and assembles partial results; target-call fan-out is not free even when target waits are excluded. Bounded transactions: +10 ms monthly p99 (adapter-added). ExecuteTransaction, TransactGetItems, TransactWriteItems. Transaction validation, conditional plans, idempotency checks and commit-result assembly cost more than independent point operations. Bounded PartiQL statements: +10 ms monthly p99 (adapter-added). BatchExecuteStatement, ExecuteStatement. PartiQL adds parse, validate and lowering stages before ordinary item execution; a statement is not automatically a point lookup. DynamoDB Streams reads: +10 ms monthly p99 (adapter-added). DescribeStream, GetRecords, GetShardIterator, ListStreams. The adapter reads its stream/outbox representation and converts records, versions and cursors. Adapter-owned stream metadata waits remain on the clock. Table and configuration API responses: +20 ms monthly p99 (adapter-added). CreateTable, DeleteTable, DescribeTable, DescribeTimeToLive, ListTables, ListTagsOfResource, TagResource, UntagResource, UpdateTable, UpdateTimeToLive. Logical-table catalogs and lifecycle state must be persisted and validated. Their storage latency is adapter work even when the catalog uses the same database as application items. 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

Watch adapter CPU and allocation rate alongside target read/write capacity, partition hot spots and connection/session limits. Scale adapter replicas on outstanding work, not QPS alone: a 100-item scan and a GetItem differ substantially. Tensor9 is responsible for autoscaling within the agreed per-operation concurrency, item-size, page and burst limits. The customer selects and sizes the target, including Cosmos RU/s, Spanner capacity or SQL connections; scaling the adapter cannot remove a hot partition or a database quota. 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

Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.

​
Example and diagnosis

In orders, GetItem for a 3 KiB item uses the point-read row. Query that examines 90 items but returns only two still uses the page row. An UpdateItem with a version condition uses the conditional-write row. In Explain, compare adapter expression/planning/serialization work with the measured target operation; a rise in Cosmos throttling or Spanner execution time is different from a rise in adapter queueing or catalog lookups. 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.

​
DynamoDB to Firestore

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. Latency targets measure the time Tensor9’s adapter adds to backend processing, not the application’s total elapsed time. They do not replace the backend provider’s SLA. Adapter time covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the backend service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Correct data and authorization behavior is required for every supported request; endpoint reachability does not excuse incorrect results. DynamoDB write limits. A plain write has no ConditionExpression or legacy Expected, no returned old item (ReturnValues absent or NONE), and streams disabled. The index configuration must be covered by your agreement. Size limits include the full current item and any previous item the adapter must read. For a delete that does not read the old item, count the key and request size. Writes with streams enabled need a separate latency agreement. Table management, PartiQL and Streams operations are not covered here. Any smaller API limit still applies. Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, backend configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for backend-service capacity; failures caused independently by the provider are outside this SLA. Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment.

​
Why these latency targets differ

Plain point requests have a 1 ms target for items up to 4 KiB, with at most 64 attributes and nesting depth 8. Plain writes have no condition, old-value return, secondary-index maintenance or stream work. The 3 ms conditional/update class adds expression parsing and bounded item manipulation; it permits at most 20 expression clauses and two maintained indexes. The 10 ms page class accounts for decoding and filtering up to 100 examined items, including discarded items. A transaction with up to 100 actions has a separate 20 ms budget for validation, planning and result handling. Backend document execution is measured separately; adapter-owned catalog, coordination, retry and response work remains included. Changing the request shape changes its class rather than quietly raising the point-request limit.

​
Adapter and scope

These standard terms cover the DynamoDB table API adapted to Google Cloud Firestore. They distinguish the adapter’s processing from Firestore execution, while keeping the adapter responsible for correct translation, acknowledgment and response handling. Your signed agreement determines which deployment is covered, where timing starts and stops, and which request sizes and traffic levels are covered.

​
Operations and latency

The operation terms below concern GetItem, PutItem, DeleteItem, UpdateItem, Query, Scan and TransactWriteItems, with the request options supported by the adapter. Larger supported requests retain their documented behavior without inheriting the small-request latency targets. BatchGetItem, BatchWriteItem and TransactGetItems are not covered by these standard terms. Table lifecycle, PartiQL and DynamoDB Streams operations are also outside these terms. Absence from this SLA is not a statement that an operation is unsupported; consult the directed service profile for support.
Plain writes and conditional updates
A plain PutItem or DeleteItem has no ConditionExpression or legacy Expected condition, has ReturnValues absent or NONE, uses the index configuration specified in the agreement, and has streams disabled. A request that checks a supported condition or asks for supported values from the previous item needs more work. It belongs in the conditional-update class, not the plain-write class. UpdateItem always belongs in the update class, even when it only changes one small attribute. The item-size limit includes the complete item the adapter reads or changes, including any previous item needed to evaluate a condition. A DynamoDB projection returning 100 bytes does not bring a larger item the adapter loaded within that limit. For a plain delete that does not read the old item, the 4 KiB bound applies to the key and request instead. Writes with streams enabled, and other supported request options outside these limits, need separately agreed latency targets. They do not inherit these latency values merely because the operation name is the same.
Queries and transactions
Record whether a query reads the base table, an LSI or a GSI, along with its consistency mode and declared indexes. A filter returning five results after examining thousands of candidates does not meet the query row’s limits. The transaction class covers only the combinations described by this adapter’s profile. The performance-class limit does not extend API limits or add support for stream-enabled transactions. A supported request that exceeds these limits has no latency target from this row. The adapter must not truncate its result to meet that target.

​
What the latency includes

Included work covers permission checks, reading the request, processing expressions, accepting or queueing the request, local retries, coordination, and preparing the response. Firestore transaction and commit waits are separately measured when measurements reliably show how long Firestore took. Local retry delays remain adapter time even when contention triggered them. A timing span named after Firestore is not sufficient evidence that all time inside it was spent waiting on Firestore. A correct ConditionalCheckFailedException is a valid result. Evaluating the condition incorrectly, losing the response, or returning success for a failed write is an adapter failure.

​
Durability and consistency

The adapter must handle every supported request correctly:
  • Return success for a write only after the required Firestore commit and adapter-state updates.
  • Keep a supported condition check and its write together, and ensure supported transactions either complete all their changes or make none.
  • Preserve the profile’s supported numeric domain and reject unsupported numeric values rather than silently rounding them.
  • Enforce the 400 KiB item limit. This API limit is separate from the smaller 4 KiB limit for the latency target.
  • Honor the declared base-table and index behavior rather than substituting an unrestricted scan or an unchecked write.
Exact supported signed 64-bit integers do not imply support for every DynamoDB decimal. Check the profile when workloads depend on wider numeric precision. Item durability is not a promise of immediate physical erasure after table deletion. Table lifecycle and cleanup behavior have separate semantics and are not assigned a deletion deadline here.

​
Scaling and limits

In the standard production model, Tensor9 automatically adds adapter capacity within the agreement’s workload limits. Your team is not responsible for routinely adjusting the number of adapter instances. Delays in adding capacity within those limits still count toward adapter latency. Independent keys can supply parallel work. A heavily contended document, shared coordination stage or table-scoped stream-writer ownership can limit scale even when more workers are available. Firestore quotas and backend contention are distinct from time spent processing expressions, queueing requests, and retrying. The standard terms do not set a numerical maximum request rate. A useful agreed limit must identify the operation mix, item and expression sizes, indexes, consistency, streams, key distribution, allowed traffic bursts and spare capacity for failures. It measures completed origin operations while preserving latency and correctness, not just requests sent toward Firestore. Do not add separately measured read and update maxima together. Both operations can share workers and state, while conditional updates do substantially more work per request.

​
Worked example: conditional order update

The orders table stores a small order with a version attribute. An application uses UpdateItem to change its status only if the stored version matches the version it read.
  1. The adapter decodes the expression and prepares the supported Firestore operation. This is adapter work.
  2. Firestore evaluates the native transaction and commits the change, or reports a conflict. The separately measured time spent waiting for the backend is recorded separately.
  3. The adapter returns the DynamoDB-shaped success or conditional failure. Local retry and response work remain covered.
A competing update can make the condition false. Returning the expected conditional-check failure satisfies the request’s semantics; the SLA does not promise that every requested mutation succeeds.

​
Worked example: one hot order

Suppose many workers update the same order and p99 response time rises. Compare Firestore contention, key distribution, local queueing and retries for the same interval. If native contention increases while local processing stays stable, changing the workload’s contention pattern can be more effective than adding adapter instances. If retries multiply native calls or a local queue grows while Firestore has headroom, Tensor9 investigates the adapter behavior. Both conditions can occur together; a backend conflict is not a blanket exclusion.

​
Evidence for support

Keep the operation, table and index selection, consistency mode, full item and expression sizes, examined candidate count, status, timestamps and request identifiers. Record index or stream configuration changes that preceded the incident. Use tensor9 explain to inspect the directed profile. A request-level Explain report can help relate selected behavior to observed calls; it is not a continuous measurement of SLA compliance. x-t9-explain: true executes the request while recording an explanation, so do not replay an order mutation merely to obtain a report. Share sanitized evidence through the agreed support channel. Remove credentials, tokens and sensitive item values while preserving the shape, sizes and identifiers needed to correlate the incident. Tensor9 helps investigate both adapter and backend behavior; you do not need to prove fault before contacting support.

​
DynamoDB to Spanner

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. Latency targets measure the time Tensor9’s adapter adds to backend processing, not the application’s total elapsed time. They do not replace the backend provider’s SLA. Adapter time covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the backend service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Correct data and authorization behavior is required for every supported request; endpoint reachability does not excuse incorrect results. DynamoDB write limits. A plain write has no ConditionExpression or legacy Expected, no returned old item (ReturnValues absent or NONE), and streams disabled. The index configuration must be covered by your agreement. Size limits include the full current item and any previous item the adapter must read. For a delete that does not read the old item, count the key and request size. Writes with streams enabled need a separate latency agreement. Table management, PartiQL and Streams operations are not covered here. Any smaller API limit still applies. Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, backend configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for backend-service capacity; failures caused independently by the provider are outside this SLA. Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment.

​
Why these latency targets differ

GetItem and plain small writes each have a 1 ms target. A plain write avoids conditions, old-value returns, secondary-index maintenance and streams. The conditional/update class has 3 ms for bounded expression work and physical-plan construction; a bounded query/scan page has 5 ms for up to 100 examined items and 400 KiB decoded data. Batches and transactions retain a separate 20 ms budget for up to 100 actions/items, subject to the smaller limit of each API. Only separately measured Spanner application-operation waits are candidates for exclusion. Adapter metadata and coordination stored in Spanner remain adapter work.

​
Adapter and scope

These standard terms cover the DynamoDB table API adapted to Google Cloud Spanner. The adapter commitment concerns correct handling and the processing it adds; it is not a guarantee that a complete Spanner transaction finishes within the adapter’s latency budget. Your signed agreement determines the deployment requirements and the request sizes, traffic levels, and traffic bursts it covers.

​
Operations and latency

The operation terms concern the operations in the table with the request options supported by the adapter. Supported requests outside a latency row’s size and count limits retain their documented behavior without inheriting that row’s latency target. Table lifecycle, PartiQL and DynamoDB Streams operations are not covered by these terms. This profile does not provide DynamoDB Streams support. An equal threshold does not combine measurements: report TransactGetItems and TransactWriteItems separately, just as successful high-volume reads must not hide failing writes.
Which write class applies?
The plain-write class requires no ConditionExpression or legacy Expected condition, ReturnValues absent or NONE, streams disabled, and the index configuration specified in the agreement. A supported condition or supported previous-item return puts PutItem and DeleteItem in the conditional-update class. UpdateItem always uses that class. The request determines which row applies. A faster execution path does not let the adapter choose a different row afterward. The 4 KiB limit applies to the full items the adapter reads, loads, or changes, including any previous item needed for a condition or response. Returning only a few fields through a DynamoDB projection does not make a larger item qualify. For a plain delete that does not load the old item, measure the key and request size instead.
Pages, batches and transactions
For a query, record the base-table or index path, consistency choice and examined data. A page returning ten items does not meet the query limit if the adapter had to scan many more items before filtering them. A batch’s API-specific item limit still applies even though the shared performance class says “at most 100.” Preserve individual item outcomes and unprocessed items rather than treating an HTTP success as proof that every item completed. The transaction performance class is narrower than some supported API maxima. Supported combinations and idempotency-token behavior remain part of correctness; a request is not allowed to lose atomicity to fit the latency class.

​
What counts toward adapter latency

Include authorization, decoding, expression evaluation, mutation preparation, local queueing, connection or session acquisition, coordination, retry scheduling and response handling. These costs remain adapter work even when they occur inside a function that calls Spanner. Time spent waiting for Spanner to execute and commit a request is reported separately when it can be measured. Measure the adapter and backend portions of the same request. Subtracting the p99 of one benchmark from the p99 of another does not tell you how much time the adapter added. Correctly reporting a failed condition is a valid result. If the write commits but the adapter loses the response, the caller did not receive a successful response. Check whether repeating the operation is safe before retrying.

​
Durability and consistency

The standard obligations include:
  • Return success for writes only after the required Spanner and adapter commits.
  • Preserve data reported as successfully saved when the adapter recovers its state.
  • Preserve supported decimal values exactly and enforce the 400 KiB item limit.
  • Keep supported multi-item transactions atomic and preserve documented idempotency behavior.
  • Provide the documented strong reads from the base table and update native indexes as part of the same commit.
Spanner’s native capabilities do not broaden the origin API. In particular, a DynamoDB GSI request cannot acquire support for ConsistentRead=true simply because Spanner can perform strong reads. The adapter must preserve the supported origin request rules. These correctness obligations apply to every supported request. Native storage durability remains a separate provider responsibility.

​
Scaling and limits

The standard production model automatically adds adapter capacity. The agreed limits must describe how many application operations can complete for the actual workload, including adapter work before and between backend calls. Independent transactions and keys can supply parallel work. Shared connection and session budgets, hot rows, local expression processing and repeated conflicts can limit useful completions. Adding replicas without a fleet-wide connection budget can move the bottleneck or make contention worse. The standard terms do not assign a numerical maximum request rate. A point-read limit cannot be multiplied by the number of actions in a transaction to establish transaction capacity. Qualify the transaction mix, action count, item sizes, indexes, conflict distribution, traffic growth and spare capacity for failures separately. The customer’s Spanner sizing affects native execution capacity. Tensor9 remains responsible for unnecessary repeated work and local queueing within the agreed adapter workload limits; “increase Spanner capacity” is not an adequate answer when the delay is in a local pool.

​
Worked example: order and inventory transaction

The application uses TransactWriteItems to create an order and decrement its inventory item. The action count and all data loaded by the adapter meet the transaction row’s limits.
  1. The adapter validates the supported actions and prepares their native transaction. Authorization, expression and encoding work count as adapter processing time.
  2. Spanner executes and commits the transaction. Separately measured backend wait is measured separately.
  3. The adapter constructs the origin response. The response must reflect the transaction’s atomic outcome.
The adapter latency target does not cap total transaction duration. Atomicity applies regardless of whether a particular request meets that performance class.

​
Worked example: slow requests with spare backend capacity

Suppose requests slow down while Spanner metrics show available capacity. Local session acquisition grows, and retries occupy workers for longer. Tensor9 investigates waits for a connection or session, total connections, retry scheduling and traffic mix. Increasing backend capacity may not reduce those delays. Conversely, if native contention dominates after local queues are ruled out, support helps examine hot rows, transaction scope and backend sizing. If a transaction times out, it may already have committed. Check what happened before retrying. Do not repeat it with a new identity on the assumption that the first attempt did nothing.

​
Evidence for support

Capture operation names, transaction action counts, full item and expression sizes, indexes, consistency, result classes, request identifiers and the incident interval. Keep local queue, pool, retry and native execution observations together. An Explain report can help identify the selected path and captured calls, but it does not prove a commit that the report did not observe, and it does not continuously measure SLA compliance. x-t9-explain: true executes the requested operation; use it only when repeating that operation is safe, or capture it on an already intended request. Remove tokens, credentials and sensitive item values from support material. Preserve sizes, conditions’ structure and correlation identifiers so Tensor9 can investigate without needing sensitive customer data or requiring you to prove who caused the problem.

​
DynamoDB to OCI NoSQL Database

SLA status: Not applicable The application uses the OCI NoSQL API on this mapping. It does not provide a DynamoDB request translator, so DynamoDB fabric latency does not apply.

​
DynamoDB to 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 postgres::1.0.0::database, The SQL-backed adapter maps items, expressions and indexes onto relational rows and transactions. Row locks, index maintenance, stream outboxes and transaction conflict handling can add work beyond a single statement. The 1 ms point-operation objective is deliberately narrow. A conditional write, scanned page, transaction or control-plane request uses its own row. Stored procedures or SQL that implement the application operation are target execution; adapter catalog, coordination and retry work must not be mislabeled as application-database wait.

​
How the latency targets were chosen

Small point reads: +1 ms monthly p99 (adapter-added). GetItem. Key decoding, one physical-plan construction and bounded item conversion. The target database’s own response time is separate. Plain small-item writes: +1 ms monthly p99 (adapter-added). DeleteItem, PutItem. The simple write avoids expression evaluation, read/modify/write and index/outbox amplification. Conditional writes and updates: +3 ms monthly p99 (adapter-added). DeleteItem, PutItem, UpdateItem. Expression parsing, update evaluation and result construction add CPU work; guarded updates can repeat local work after target conflicts. Bounded query and scan pages: +5 ms monthly p99 (adapter-added). Query, Scan. Physical query planning, item decoding, filters, ordering and cursor generation scale with the examined page, including rows the response omits. Bounded item batches: +10 ms monthly p99 (adapter-added). BatchGetItem, BatchWriteItem. The adapter builds and schedules item plans and assembles partial results; target-call fan-out is not free even when target waits are excluded. Bounded transactions: +10 ms monthly p99 (adapter-added). ExecuteTransaction, TransactGetItems, TransactWriteItems. Transaction validation, conditional plans, idempotency checks and commit-result assembly cost more than independent point operations. Bounded PartiQL statements: +10 ms monthly p99 (adapter-added). BatchExecuteStatement, ExecuteStatement. PartiQL adds parse, validate and lowering stages before ordinary item execution; a statement is not automatically a point lookup. DynamoDB Streams reads: +10 ms monthly p99 (adapter-added). DescribeStream, GetRecords, GetShardIterator, ListStreams. The adapter reads its stream/outbox representation and converts records, versions and cursors. Adapter-owned stream metadata waits remain on the clock. Table and configuration API responses: +20 ms monthly p99 (adapter-added). CreateTable, DeleteTable, DescribeTable, DescribeTimeToLive, ListTables, ListTagsOfResource, TagResource, UntagResource, UpdateTable, UpdateTimeToLive. Logical-table catalogs and lifecycle state must be persisted and validated. Their storage latency is adapter work even when the catalog uses the same database as application items. 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

Watch adapter CPU and allocation rate alongside target read/write capacity, partition hot spots and connection/session limits. Scale adapter replicas on outstanding work, not QPS alone: a 100-item scan and a GetItem differ substantially. Tensor9 is responsible for autoscaling within the agreed per-operation concurrency, item-size, page and burst limits. The customer selects and sizes the target, including Cosmos RU/s, Spanner capacity or SQL connections; scaling the adapter cannot remove a hot partition or a database quota. 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

Conditional writes must not silently lose their condition, and a transaction must not report atomic success after a partial commit. Exact number representation, consistency, secondary-index behavior and stream ordering remain those documented for this target. A request outside that support is rejected or handled as explicitly documented, not made correct by meeting a latency percentile. The underlying database’s durability commitment is not a Tensor9 storage SLA.

​
Example and diagnosis

In orders, GetItem for a 3 KiB item uses the point-read row. Query that examines 90 items but returns only two still uses the page row. An UpdateItem with a version condition uses the conditional-write row. In Explain, compare adapter expression/planning/serialization work with the measured target operation; a rise in Cosmos throttling or Spanner execution time is different from a rise in adapter queueing or catalog lookups. 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.

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