AWS Database Blog
Introducing ExtendDB: An open source DynamoDB-compatible adapter with pluggable storage backends
Today, we are announcing ExtendDB, an open source Amazon DynamoDB-compatible adapter with pluggable storage backends, released under the Apache 2.0 License. ExtendDB implements the DynamoDB wire protocol and ships with PostgreSQL as its first backend, so any AWS SDK, CLI, or tool that works with DynamoDB works with ExtendDB unchanged.
In this post, we introduce ExtendDB, walk through getting started, and explain the architecture. This is a v0.1 release for development, testing, and experimentation.
Background
Amazon DynamoDB is a serverless, fully managed NoSQL database with single-digit millisecond performance at any scale. Teams building on DynamoDB develop deep expertise in its data modeling patterns, condition expressions, transactions, and streams. They build CI pipelines around it, write operational runbooks for it, and train their engineers on it. As these teams expand into edge, on-premises, and disconnected environments, they want to bring the same API and developer experience with them.
A major airline runs most of its applications on AWS with DynamoDB as their primary data store. But gate and onboard systems must keep operating through network outages and cannot tolerate cloud round-trip latency for boarding, baggage reconciliation, and onboard sales. These systems need the same access patterns, the same conditional writes, the same transactional guarantees. Without a compatible runtime, this team maintains two separate application stacks with different data access layers, different operational procedures, and different expertise requirements.
Running DynamoDB workloads outside of AWS today means rewriting your data access layer. DynamoDB Local is a single-process tool intended for unit testing. ExtendDB targets a broader set of local development and on-premises scenarios as an early-stage project.
Use cases
ExtendDB addresses scenarios where the managed DynamoDB service is not available or practical.
Local development and CI/CD. Run DynamoDB workloads on your laptop or in continuous integration and continuous delivery (CI/CD) pipelines with zero cloud dependency. Integration tests start in seconds, run deterministically, and tear down cleanly.
On-premises and air-gapped environments. Developers without cloud connectivity, teams running on-premises workloads, and operators at the edge can run DynamoDB access patterns on their own infrastructure.
Multi-cloud and hybrid. Teams experimenting with portability across infrastructure providers can use the DynamoDB API anywhere PostgreSQL is available. The following diagram shows how migrating from ExtendDB to DynamoDB requires only an endpoint URL change:
What is ExtendDB
ExtendDB is a clean-room implementation of the DynamoDB wire protocol, written in Rust and developed by AWS engineers. It is not a fork of DynamoDB and contains no DynamoDB source code. Think of it as a translator sitting between your application and your storage backend. If you use the PostgreSQL reference backend, your application speaks DynamoDB, ExtendDB translates to SQL, and PostgreSQL handles the storage.
It implements the DynamoDB JSON protocol at the wire level. Your existing application code, SDKs, and tooling connect without modification. All data is stored in PostgreSQL, so you get the operational tooling you already know: pg_dump, replication, point-in-time recovery, and standard monitoring.
The storage layer is defined as a Rust trait. Additional backends like Apache Cassandra for horizontal scale can be implemented without modifying the core.
ExtendDB compiles to a single binary with no external runtime dependencies. TLS is mandatory and auto-generates a self-signed certificate on first run. SigV4 authentication with a local IAM-like credential store means your application code uses the same signing logic it uses against the DynamoDB service.
Supported operations
| Category | Operations |
| Table | CreateTable, DeleteTable, DescribeTable, ListTables, UpdateTable |
| Item | PutItem, GetItem, DeleteItem, UpdateItem (SET, REMOVE, ADD, DELETE with condition expressions) |
| Query and Scan | Key conditions, filter expressions, projections, pagination, secondary index selection |
| Batch and Transactions | BatchGetItem, BatchWriteItem, TransactGetItems, TransactWriteItems |
| Streams | ListStreams, DescribeStream, GetShardIterator, GetRecords |
| TTL | UpdateTimeToLive, DescribeTimeToLive |
| Import/Export | ImportTable, ExportTableToPointInTime |
| Tags | TagResource, UntagResource, ListTagsOfResource |
Account and credential administration can be done through command line or a web management console at https://127.0.0.1:8000/console/.
Getting started
ExtendDB runs on Linux and macOS. You need Rust 1.85+ and PostgreSQL 14+.
The init command connects to your running PostgreSQL instance, creates the required databases and schemas, generates an admin credential, provisions a TLS certificate, and writes a configuration file:
Next, create an IAM user with DynamoDB access. The init command outputs an admin password and a default account id that you use with extenddb manage:
This returns an access key ID and secret. Export them along with the CA bundle:
ExtendDB is now listening on https://127.0.0.1:8000. Use standard DynamoDB commands:
AWS SDKs support endpoint URL configuration. You change the endpoint URL and keep everything else unchanged.
Architecture
ExtendDB separates concerns into Rust crates. The core crate handles types, validation, and expression evaluation as pure synchronous Rust. The engine crate implements DynamoDB API semantics. The storage-postgres crate is the PostgreSQL backend, built against a storage trait that defines the interface any backend must implement. The server crate ties it together with an HTTP server, management API, and web console.
The following architecture diagram shows a high-level overview of ExtendDB:
Limitations
ExtendDB is not DynamoDB. It is a compatible implementation, not a replacement for the managed service. Performance characteristics, scaling behavior, and operational properties differ. Use DynamoDB when you need the managed service guarantees.
A database is required, and you are responsible for its availability, backups, and maintenance. TLS is mandatory. ExtendDB includes its own IAM-like implementation with SigV4 signature verification and policy evaluation. This is a standalone system. Credentials and policies created in ExtendDB are entirely separate from AWS IAM and cannot be shared between the two. Global tables and cross-Region replication are not implemented, because these are DynamoDB-specific managed features.
Get involved
In this post, we introduced ExtendDB, an open source DynamoDB-compatible adapter backed by PostgreSQL. If your workloads require DynamoDB access patterns outside of AWS, whether for local development, CI/CD testing, on-premises deployments, or air-gapped environments, ExtendDB provides a compatible implementation that works with your existing application code and SDKs.
ExtendDB is at an early stage, and we are building in the open. Clone the GitHub repository, follow the Getting Started guide, and have a DynamoDB-compatible endpoint running locally in minutes. For details on how you can contribute, see the Contribution Guide. If you find a gap or want to contribute a storage backend, open an issue or submit a pull request.