ExtendDB: Run the DynamoDB API on Your Own Database

Say a hospital records system has to stay inside the building — patient data can never leave the on-prem network, an auditor signs off on every dependency, and the dev laptops have no internet at all. The team already wrote the application against the DynamoDB API and likes it: single-digit-millisecond key lookups, a clean item model, no schema migrations to babysit. But managed DynamoDB is a cloud service, and "send the data to AWS" is a non-starter here.

ExtendDB is built for exactly that gap. It speaks the DynamoDB wire protocol but stores the data in a database you run.

What ExtendDB is

ExtendDB is an open-source adapter from AWS — written by AWS DynamoDB engineers and announced on the AWS Database Blog — that implements the DynamoDB JSON wire protocol in Rust. Because it answers the same HTTP API the managed service does, your existing AWS SDKs and the AWS CLI work unchanged. The only thing that moves is the endpoint URL — no code rewrite, no new client library.

The interesting part is what sits behind that API. ExtendDB has pluggable storage backends: PostgreSQL is the reference implementation, and Cassandra is cited as another possible backend. New backends are implemented without modifying the core, so the DynamoDB-compatibility layer and the storage layer evolve independently.

So a request flows like this:

What it supports — and what it doesn't

Per the getting-started docs and the announcement, ExtendDB (v0.1) covers the operations most applications actually call:

• Tables — Create, Delete, Describe, List, Update.
• Items — Put, Get, Delete, Update (including the SET / REMOVE / ADD / DELETE update actions).
• Query and Scan — key conditions, filter expressions, projections, pagination, and secondary indexes.
• Batch — BatchGetItem and BatchWriteItem.
• Transactions — TransactGetItems and TransactWriteItems.
• Streams, TTL, Import/Export, and Tags.

What it deliberately does not implement is the set of DynamoDB-specific managed features — most notably Global Tables and cross-Region replication. Those are properties of the managed service's global infrastructure, not of the API surface, so they don't carry over to an adapter you host yourself.

vs DynamoDB Local

You may already use DynamoDB Local for offline development. That's a single JAR (or amazon/dynamodb-local Docker image) meant for unit tests on one machine. ExtendDB aims broader than that single-process tool: local development, on-prem deployments, edge and air-gapped environments, and hybrid / multi-cloud setups where you want the DynamoDB API but the data lives in infrastructure you control.

vs managed DynamoDB

This is the line AWS draws explicitly, and it matters:

ExtendDB is not DynamoDB. It is a compatible implementation, not a replacement for the managed service. Performance characteristics, scaling behavior, and operational properties differ.

Concretely, when you run ExtendDB:

• You own the database's availability and backups. There's no managed multi-AZ durability or point-in-time recovery doing it for you — that's on you and your PostgreSQL operations.
• TLS is mandatory on the endpoint.
• Credentials are IAM-like but separate from AWS IAM — ExtendDB has its own credential model; it does not authenticate against your AWS account.

It's v0.1 and licensed Apache 2.0. Treat it as early software: great for the environments above, not a drop-in swap for production-scale managed DynamoDB.

Setup

ExtendDB runs on Linux and macOS and needs Rust 1.85+ and PostgreSQL 14+. The flow is two commands:

extenddb init
extenddb serve

init provisions the schema in your PostgreSQL database; serve starts the wire-protocol server, which listens on an endpoint like https://127.0.0.1:8000 (TLS is required, hence https).

Point the AWS SDK at it the same way you would any custom endpoint — only the URL and the credentials change:

import {DynamoDBClient} from '@aws-sdk/client-dynamodb';

const client = new DynamoDBClient({
  endpoint: 'https://127.0.0.1:8000',
  region: 'local',
  credentials: {accessKeyId: '<extenddb-key>', secretAccessKey: '<extenddb-secret>'}
});

Everything past the client config — PutItem, Query, TransactWriteItems — is identical to the code you'd write against managed DynamoDB. A single-table item layout works exactly as it does in the cloud:

Do it in DynoTable

Because ExtendDB speaks the DynamoDB wire protocol, you don't need a separate admin tool for it — point DynoTable at the ExtendDB endpoint the same way you'd connect it to DynamoDB Local: create an offline (local) profile with the ExtendDB port and throwaway credentials, and DynoTable will browse, query, and edit the items — except now they're backed by PostgreSQL on your own disk instead of a JAR's in-memory store.

This is the payoff of wire-protocol compatibility: the SQL Workbench, the visual query builder, and item editing all work against ExtendDB unchanged, so you get a real GUI over your self-hosted data without writing scan scripts.

One caveat to plan for: ExtendDB's endpoint is HTTPS-only, while DynoTable's offline profile (like most DynamoDB-Local setups) targets a loopback host:port. If your client or tooling needs a plaintext loopback listener, terminate TLS in front of ExtendDB (or run a local reverse proxy) and point the GUI at that — the protocol on the wire is still DynamoDB JSON either way.

Pitfalls

• Don't treat v0.1 as production DynamoDB. Scaling, latency, and durability are your PostgreSQL's, not AWS's. Benchmark for your workload before you depend on it.
• No Global Tables / cross-Region replication. If your design relies on multi-Region active-active, ExtendDB isn't the path — that's a managed-service feature.
• Back up the underlying database yourself. There's no managed PITR; a dropped PostgreSQL volume is gone. Wire up pg_dump / WAL archiving like any other PostgreSQL.
• Credentials are ExtendDB's own, not AWS IAM. Don't expect IAM policies, roles, or condition keys to govern access — that authorization model doesn't carry over.

Next steps

• Model your access patterns first — the same single-table design discipline applies whether the backend is DynamoDB or PostgreSQL-via-ExtendDB.
• Build and inspect your reads and writes with the DynamoDB Expression Builder, then convert fixtures between plain JSON and the wire format with the DynamoDB-JSON converter.
• When you're ready to poke at a live ExtendDB instance, connect DynoTable and browse it like any other table.