By ByteBot
AWS just open-sourced ExtendDB — a DynamoDB-compatible adapter that stores data in PostgreSQL instead of the managed cloud service. Your existing Python, JavaScript, or Java SDK code connects unchanged. Just point your endpoint at localhost. No AWS account. No Java runtime. No mocking required.
The Problem With DynamoDB Local Development
DynamoDB has always been an awkward database to develop against. The official tool — dynamodb-local — is a Java JAR that AWS ships but does not love. It has real gaps: no DynamoDB Streams support, no parallel scans, and incomplete expression handling in edge cases. CI/CD pipelines typically work around it by mocking DynamoDB entirely (unreliable), spinning up real AWS resources in test environments (expensive and slow), or accepting the known incompatibilities.
Air-gapped environments and on-premises teams do not even have these options. If your network cannot reach AWS endpoints, you have no DynamoDB.
What ExtendDB Does
ExtendDB implements the DynamoDB wire protocol in Rust and routes requests to PostgreSQL instead of the managed service. To your application code, it looks identical to real DynamoDB. To your database, it is just SQL.
The architecture is four Rust crates: core handles DynamoDB types and expression evaluation, engine implements API semantics, storage-postgres is the PostgreSQL backend, and server exposes the HTTP endpoint and management UI. The storage layer is defined as a Rust trait — pluggable by design. Apache Cassandra and MySQL backends are on the community roadmap.
ExtendDB covers the full data plane: GetItem, PutItem, UpdateItem, DeleteItem, batch operations, transactions, Query, Scan, Streams, and TTL. Everything dynamodb-local left out is supported here.
Getting Started in Two Minutes
Pull the Docker image and you are running:
docker run --name extenddb -p 8000:8000 public.ecr.aws/aws/extenddb:latestPoint your SDK at localhost and nothing else changes:
import boto3
client = boto3.client(
'dynamodb',
endpoint_url='http://localhost:8000',
region_name='us-east-1',
)# AWS CLI — no flags, no changes
aws dynamodb list-tables --endpoint-url http://localhost:8000 --region us-east-1The AWS CLI, all official SDKs, and NoSQL Workbench connect without modification. ExtendDB speaks the DynamoDB wire protocol at the HTTP level — your code never knows the difference.
How It Compares to dynamodb-local
| dynamodb-local | ExtendDB | |
|---|---|---|
| Language | Java | Rust |
| DynamoDB Streams | Not supported | Supported |
| Parallel scan | Not supported | Supported |
| Pluggable backends | No | Yes (trait-based) |
| License | Proprietary | Apache 2.0 |
Be Honest About the Limits
ExtendDB is v0.1. AWS labels it explicitly for development and CI use only — not production. Early community testing found p90 write latencies around 300ms under write load. Global tables, point-in-time recovery, DAX, and auto-scaling are absent — those are managed-service concerns that do not map to a self-hosted deployment.
The honest framing: ExtendDB solves the local dev and CI problem cleanly. It is not yet a path to running DynamoDB workloads in production outside AWS.
The Bigger Picture: PostgreSQL Absorbs Everything
ExtendDB is one more data point in a 2026 trend that is hard to ignore: PostgreSQL is becoming the universal backend. Neon runs serverless Postgres. Azure HorizonDB is managed Postgres for agentic apps. pg_durable brings durable execution to Postgres. Databricks Lakebase centers the data lakehouse on Postgres. Now DynamoDB’s API runs on Postgres too.
AWS releasing ExtendDB is strategic, not altruistic. Making DynamoDB easier to develop against locally removes friction from adoption. No one replaces production DynamoDB with a self-hosted ExtendDB instance — AWS knows this. But it gives developers a reason to stay in the DynamoDB programming model rather than switching to a Postgres-native database from the start.
Community engagement has been real. Corey Quinn — AWS’s sharpest satirist — opened a pull request to add a Route53 backend, which says something about the energy around the project.
Should You Use It?
If you are already building on DynamoDB: switch your local and CI environments to ExtendDB now. You get Streams, full expression support, PostgreSQL tooling for data inspection and backups, and zero cloud dependency in your test suite.
If you are evaluating databases and wondering whether DynamoDB’s lock-in is worth it: ExtendDB improves the development story but does not change the production story. DynamoDB is still AWS-only in production. Watch for v1.0 and whether serious backend contributors show up.
The ExtendDB GitHub repository is the right starting point. The AWS Database Blog announcement covers the architecture in depth. InfoQ’s writeup has the community context worth reading.
