We have DynamoDB at home.

[quinnypig]

Forward

This is the third time.

#54 argued that Route 53 is a database and proved it by force, packing base64 into 255-byte TXT strings until DNS confessed.

#174 argued that S3 Object Annotations was already a database, because AWS had built the Iceberg index, SQL query path, and change journal and merely declined to use the noun.

Neither merged. No review comment arrived, but I can reconstruct one from the shape of the silence:

Stop inventing storage engines and just use DynamoDB.

Done.

This PR adds a DynamoDB backend to the DynamoDB-compatible database. It stores its DynamoDB data in DynamoDB.

Run ExtendDB yourself, on infrastructure you administer, pointed at us-east-1. When the executive who read one cloud-repatriation post asks whether the database is in-house, you can truthfully say the database server is. No follow-up question they know how to ask will surface the rest.

We have DynamoDB at home.

A note from the intervening architecture committee

This PR waited long enough for 79 upstream commits to land. During that interval, upstream did not reject the premise. It did something more revealing: it redesigned the entire backend system.

Inventory registration is gone. The name-keyed registry that replaced it is also gone. The CLI moved into a backend-agnostic app crate. Feature flags were declared vestigial. The official architecture is now one backend per binary.

This is either excellent type-safe design or a containment protocol.

The backend complied. It now ships as a dedicated executable:

$ cargo build --release --bin extenddb-dynamodb
$ ./target/release/extenddb-dynamodb version
extenddb 0.1.2
catalog 0.0.2 (dynamodb)

Runtime backend selection has been eliminated. To choose the wrong database, an operator must now install the wrong database server. This is progress.

The plugin-model refactor did not kill the backend. It gave the backend its own executable. The bit has incorporated.

The anti-joke

The meme format requires the thing at home to be worse.

Route 53 honored the format: items shredded across TXT records are worse.

S3 Object Annotations honored it: 1,000 items per table, with the query path billed by the scanned terabyte, is worse.

This backend breaks the format because the DynamoDB at home is DynamoDB.

The failure is clearest in encoding.rs. Route 53 needed actual encoding because DNS was never intended to hold database items. S3 Annotations needed base64 chunking. DynamoDB already speaks the exact DynamoDB type system, so this backend's encoding is structurally the identity function.

The file exists because ExtendDB's AttributeValue and the AWS SDK's AttributeValue are two Rust enums holding the same data. It is round-trip tested across every type anyway, because the identity function is the one function you cannot afford to get wrong.

What is actually in here

Unlike its siblings, this backend works.

The new extenddb-storage-dynamodb crate implements the storage-engine trait surface:

• Real DynamoDB table lifecycle, CRUD, Query, Scan, and transactions.
• Parsed condition, key-condition, and update ASTs rendered back into DynamoDB expressions. The request crosses the abstraction boundary, is understood, and is then carefully made opaque again.
• Account-scoped idempotency tokens forwarded as ClientRequestToken.
• Native DynamoDB TTL and tags.
• DynamoDB failures mapped back into ExtendDB errors with wire fidelity, so an AWS SDK client can remain unaware of how many times its request has encountered DynamoDB.
• GSI and LSI metadata sourced from DescribeTable for upstream's new capacity-accounting cache, because the upstream optimization is also, unhelpfully, exactly a DynamoDB API.

The bureaucracy database

The data plane maps naturally to DynamoDB. The management plane does not.

Accounts, users, roles, policies, settings, metrics, rate limits, encryption keys, and admin credentials are relational bureaucracy. Rebuilding them on DynamoDB would require months of responsible engineering and bury the punchline.

So this is a hybrid:

• Data plane: DynamoDB.
• Catalog, IAM, settings, and administration: PostgreSQL.
• Front door: ExtendDB.
• Back door: also AWS.
• Deployment classification: on-prem, if nobody asks a second question.

Your data is on-prem. The bureaucracy that proves it is on-prem still needs a real database.

The result is two databases in a trench coat standing in your data center, presenting a config file as identification.

Table namespacing

ExtendDB is multi-tenant; DynamoDB's table namespace is flat. Physical tables are named:

<table_prefix><account_id>_<table_name>

The default prefix is athome_, producing names such as athome_123456789012_Orders.

This is not merely namespacing. It is a statement of deployment intent embedded in every CloudTrail event.

Why this is not as deranged as it sounds

• Point endpoint_url at DynamoDB Local and ExtendDB becomes the TLS, mandatory SigV4, IAM, multi-account, rate-limiting front end DynamoDB Local never had.
• It is a migration ramp in either direction. The application does not move. The invoice does.
• It validates the storage seam against a genuinely different backend instead of another PostgreSQL wrapper with different nouns.
• DynamoDB owns table lifecycle, TTL deletion, transaction idempotency, and index state. Several workers become no-ops, the most reliable state a worker can achieve.

These are defensible reasons to merge this PR, which is frankly damaging to the artistic intent.

Why it is exactly as deranged as it sounds

• I have taken a serverless database and given it a server.
• The server has its own PostgreSQL database.
• Each request is SigV4-authenticated and authorized by ExtendDB, translated into the same data model it arrived in, signed with SigV4 again, and sent to the service the client could have called directly.
• Two IAM systems inspect the request in series. The second has no idea the first exists. This is zero trust implemented as interpersonal distrust between databases.
• You pay for DynamoDB, ExtendDB compute, and PostgreSQL. We removed the middleman by hiring two middlemen.
• If ExtendDB dies, DynamoDB remains healthy through every endpoint except the one applications have been instructed to use.
• The dedicated binary gives a joke its own deployable artifact, release lifecycle, SBOM, and eventual CVE history.

I will not be taking questions about the unit economics.

Recursion is a feature

endpoint_url may point at DynamoDB Local. It may also point at another ExtendDB.

There is no loop guard. Every layer adds TLS termination, SigV4 verification, IAM evaluation, and another opportunity to claim the request is closer to home.

Compliance calls this defense in depth. I call it on-prem twice.

With enough layers, the request eventually times out, at which point no data has left the perimeter because no data has arrived anywhere.

Honest acts of cowardice

Streams and backups are explicit v1 stubs. Every method errors with the DynamoDB API it should call: DescribeStream, GetRecords, CreateBackup, RestoreTableFromBackup, and friends.

A passthrough backend must reconcile ExtendDB streams with DynamoDB Streams. That deserves another PR, partly for architecture and mostly because a trilogy should not become a box set in one diff.

index_info_by_table_id is unsupported because DynamoDB cannot reverse a TableId into a name. Even DynamoDB has limits, and one is answering questions designed by ExtendDB.

Enterprise software calls this a roadmap.

Testing

• Full Rust workspace suite passes.
• Clippy passes across all targets with warnings denied.
• Formatting and diff checks are clean.
• 31 backend unit tests cover encoding, errors, expression rendering, config, and namespacing.
• DynamoDB Local integration tests cover lifecycle, CRUD, conditions, and queries.
• The dedicated binary reports catalog 0.0.2 (dynamodb), which is correct and an alarming sentence.

The branch is rebased onto current upstream/main. The working tree is clean. The bit compiles.

Conclusion

Route 53 was an argument.

S3 Object Annotations was an accusation.

This is compliance.

Merge it or do not. Either way, the data ends up in DynamoDB.