DynamoDB (control)

This page covers table management and configuration. For item reads and writes, conditional writes, transactions and index queries, see DynamoDB item API coverage. The two pages describe distinct operation scopes; support for one does not imply support for the other. On this page

• Coverage by target cloud
• How the targets compare
  • Infrastructure-only adaptation
• On Google Cloud
  • Via Firestore
  • Via Cloud Spanner
  • Via Cloud Bigtable
  • Via Cloud SQL for PostgreSQL
• On Azure
  • Via Azure Cosmos DB (provisioned)
  • Via Azure Cosmos DB (serverless)
• On OCI
• On Private Kubernetes

​

Coverage by target cloud

​

How the targets compare

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

​

Infrastructure-only adaptation

​

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

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 on the DynamoDB table page.

​

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

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.

​

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.

​

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

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.

​

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

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; use the table page to assess numeric precision, transactions and stream ownership.

​

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

​

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 target and are not offered on this serverless target. 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 target

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.

​

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

​

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

​

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 target

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 target. Service Catalog.