[LeeroyHannigan]

Closes #462.

Summary

Since Terraform AWS provider 6.13.0 (September 2025), aws_dynamodb_table waits for WarmThroughput.Status to read ACTIVE after every table and index create or update, and treats a DescribeTable without the member as not found. ExtendDB omitted the member, so every terraform apply against it polled until couldn't find resource (21 retries). The same hang against DynamoDB Local is hashicorp/terraform-provider-aws#44344, closed by the provider team as an emulator-side fix; the current provider is 6.70.0 and the only workaround was pinning 6.12.0.

ExtendDB now stores and reports WarmThroughput on tables and global secondary indexes on all four backends, with the shape, defaults, lifecycle and validation measured on Amazon DynamoDB.

Nothing acts on the values. There is no pre-warming and no scaling at the database level, and the stored numbers have no effect on throughput, throttling or storage. They exist so clients that read the member work. This is stated in docs/differences-from-dynamodb.md (Capacity and Throttling), in docs/getting-started.md, and at the storage field.

What the service does, and what ExtendDB now does

Every rule below was measured on live DynamoDB (us-east-1, 2026-10-23) before it was written; the raw observations are in the dual-target wire tests' docstrings as row ids.

Shape	Service, now matched
CreateTable without the member	absent while CREATING; once ACTIVE {12000, 4000, ACTIVE} on an on-demand table and its GSIs, the provisioned units on a provisioned table and its GSIs; LSIs carry none
CreateTable with the member	echoed as sent with Status: UPDATING while CREATING; filled once ACTIVE (a read-only {20000} becomes {20000, 4000})
UpdateTable changing it	the previous values with UPDATING, then the new values ACTIVE; a decrease is validated against the reported values
Below minimum, below provisioned units, decrease	ValidationException with the service's sentence, naming table or index <name>
Switch to PAY_PER_REQUEST	a stored value below the on-demand minimum is raised to it
Capacity change on a never-set provisioned table	the reported default follows the new units
Companions beside a table-level WarmThroughput	refused in the measured order: Server-Side Encryption, TableClass, DeletionProtection (each its own sentence), OnDemandThroughput (needs BillingMode), a GSI Delete, then BillingMode, ProvisionedThroughput, StreamSpecification or vector updates (WarmThroughput must be the only operation in the request); a GSI Update beside it is accepted
GlobalSecondaryIndexUpdates	one action per element; one update per index; on an on-demand table an index Update may only carry OnDemandThroughput or WarmThroughput; a Create with WarmThroughput reports it on the CREATING index
Restore from backup	the restored table starts with the defaults; a GSI override carrying WarmThroughput is refused

ExtendDB differs in timing only: it returns to ACTIVE after control_plane_delay_seconds where the service takes minutes, and it does not enforce the account maximum (LimitExceededException on the service).

Storage

One nullable warm_throughput column on tables and indexes: SQLite (schema plus shape convergence on existing catalogs), PostgreSQL (001_schema.sql plus two shape steps applied at serve time), Cassandra (migration V006; catalog version 0.0.5 so extenddb migrate applies it and the backup gate stops refusing). MongoDB uses a document field. Each backend stores one JSON record; the wire member is derived in one place, TableDescription::prepare_for_response, on every response path.

UpdateTableInput now reads SSESpecification so the member can be refused instead of silently dropped.

Tests

• Unit tests for the record, defaults and every rule (core, engine, storage, SQLite, MongoDB).
• Three dual-target wire files under tests/python/: lifecycle and validation (12), update shapes and billing changes (13), backup and restore (1). They pass against the service and against SQLite, PostgreSQL, MongoDB and Cassandra.
• tests/terraform/warm-throughput/: the configuration from the provider issue plus a table with a GSI, applied with Terraform 1.17.0 and provider 6.70.0 (both pinned, the Terraform zip checksum-asserted against the published sums) on every backend in CI via devtools/run-tests --terraform; asserts a clean apply, a second plan with no changes, and destroys.
• Cassandra: a test for a catalog that has not run V006 (operations work, the member needs the migration, run_catalog_migrations applies it in place).

Negative controls: with the member removed the Terraform apply fails with the provider's couldn't find resource (21 retries) after about three and a half minutes, which is the hang from the issue; with the validation removed the refusal rows fail; five further built mutants (table member, index member, UPDATING deadline, only-operation rule, swapped defaults) each fail the wire file.

Also run on the final tree: Cassandra lib (61) and direct_integration (151, including the V006 test) suites; MongoDB and Cassandra comprehensive runs (69 each); fmt, clippy 1.97 -D warnings, MSRV 1.88; no dependency change.

Out of scope, filed separately

Measured on main while working this issue, not touched here: the service's per-member "must be the only operation" rules for TableClass, DeletionProtection and Server-Side Encryption when WarmThroughput is absent (ExtendDB accepts those pairs); a GSI reporting IndexStatus: ACTIVE while its table is CREATING; TableStatus: ACTIVE in the response to a capacity change where the service says UPDATING; UpdateTable with an empty WarmThroughput: {} or an Update naming a missing index, where the service answers its own InternalFailure.

[LeeroyHannigan]

Rebased on main at abf8082; conflicts in crates/storage-postgres/src/update_table.rs, crates/storage-sqlite/src/update_table.rs and crates/storage/src/util/mod.rs, resolved by keeping #401's GSI build flow (the new index is inserted CREATING) with this branch's warm_throughput column and bind, and both sides' imports and util exports.

The branch's commit also returned six files from #214 to their state before it: it deleted docs/rfcs/0003-backend-acceptance-criteria.md and removed the links to it from CONTRIBUTING.md, README.md, docs/design/04-component-storage.md, docs/rfcs/0002-backend-plugin-policy.md and docs/rfcs/README.md. Each of those files was byte-identical to its version before #214, and neither the commit message nor this PR mentions them, so they now match main and this PR no longer touches them.

On PostgreSQL, UpdateTable now builds the new GSI before it answers (#401), which takes longer than the 0.25 s UPDATING window, so test_gsi_create_with_warm_throughput_in_update_table failed with Status ACTIVE in the response. restart_created_gsi_warm_throughput in crates/storage-postgres/src/warm_throughput.rs starts that window again after the build. A DescribeTable during the build reads IndexStatus CREATING with WarmThroughput UPDATING; the response to UpdateTable then starts the window again, so the ACTIVE flip of the index and the UPDATING window of its WarmThroughput are observed in that order.

tests/python/test_warm_throughput*.py (26) and tests/test_gsi_online_backfill.py pass on PostgreSQL.