AWS DynamoDB Team Released ExtendDB, a DynamoDB Protocol Server Backed by Postgres

A DynamoDB endpoint backed by Postgres

On May 20, 2026, two engineers on AWS's DynamoDB team published ExtendDB, an open-source server that implements the DynamoDB wire protocol and keeps every item in PostgreSQL. The account comes from a hands-on walkthrough on dev.to, which notes the project is written in Rust, licensed under Apache 2.0 and maintained by AWS. To a client nothing looks unusual: the AWS CLI or any SDK behaves as though it is talking to DynamoDB. The difference is that the storage layer is a Postgres database you can open with psql.

What it covers, and what it admits it does not

According to the dev.to post, ExtendDB arrived as a v0.1, and the project's releases page listed v0.1.13, published October 1. Reported feature coverage includes tables and items, Query and Scan, batch and transactional writes, streams, item expiry and vector search built on pgvector. PostgreSQL 14 and newer is the reference backend; the README also documents MongoDB and mentions SQLite.

Security is handled AWS-style: TLS is required on every connection, and each request must carry a SigV4 signature computed with credentials ExtendDB issues itself. Those access keys begin with AKIAEXTENDDB, which the post notes makes a leaked key easy to distinguish from a genuine AWS credential.

The team is candid about maturity. The launch announcement frames the release as one for development, testing and experimentation, and states plainly that ExtendDB is not DynamoDB.

One environment variable to switch over

The repository ships a Docker Compose setup that runs Postgres 16 beside the server and bootstraps itself on first start. A default admin password can be overridden through an environment variable, and a manage subcommand creates users, attaches IAM-style JSON policies and mints access keys, showing the secret exactly once.

Client integration is deliberately thin. Export the server's self-signed certificate as a CA bundle, set the usual AWS credential variables, and either pass an endpoint flag or set AWS_ENDPOINT_URL_DYNAMODB. Standard dynamodb commands then run unchanged, and the same commands work against real DynamoDB — the post walks through table creation, a batch write and two Query patterns, one of them through a global secondary index.

The server even imitates DynamoDB's rough edges. New tables sit in CREATING for five seconds by default — a delay the project's differences document lists as configurable — and the internal catalog stores a per-index propagation delay in milliseconds.

What the data actually looks like

The schema is the interesting part. The Postgres side keeps two databases: a catalog that maps DynamoDB table names to internal UUIDs, and a separate data database that holds the items. Every DynamoDB table, and every secondary index, becomes its own SQL table named ddb followed by an identifier.

The post reconstructs the DDL from the project's source. Each such table has a pk text column that cannot be null, three sort-key columns typed by key type — text, numeric and binary — and an item_data column holding the complete item as JSONB. The text columns use the C collation, which orders strings by raw byte value rather than locale rules. A query selecting pk, the text sort key and jsonb_pretty(item_data) renders an item human-readable, so anyone who has sketched a single-table design on a whiteboard can finally see what it physically amounts to.

Why it matters

DynamoDB has never exposed its storage. ExtendDB has no choice, because Postgres is the storage, and that turns an opaque NoSQL abstraction into something you can inspect with \d and query with SQL. For teams, it promises a DynamoDB-compatible endpoint for local development and CI that runs on ordinary Postgres and inherits pgvector along the way. The caveats are just as clear: this is a 0.1-line project whose creators say outright that it is not a DynamoDB replacement. The broader signal is that the DynamoDB team itself is shipping an open-source compatibility layer for one of AWS's most closed services — and showing, in plain SQL, how the abstraction maps onto a relational core.