How We Used AI to Bring MongoDB to DynamoDB

Amazon has a history of favoring customer choice, and ExtendDB is another signal of that: an open source, pluggable adapter built specifically so DynamoDB workloads can run in more environments. At MongoDB, we also believe that everything starts with serving the customer well, so we work backwards from there. This is why we built a MongoDB storage backend for ExtendDB, AWS's open source DynamoDB-compatible adapter, which is ready for use today.

Here's why it matters, and how it came about.

Why a MongoDB backend matters: Run anywhere

Until ExtendDB, running DynamoDB has meant running it on AWS. There's been no way to run DynamoDB workloads on another cloud, on-prem, or in an air-gapped environment. ExtendDB solves this: it speaks the same wire protocol as DynamoDB but stores data through a pluggable backend, so your DynamoDB workload runs wherever that backend lives while your existing application code works against it unchanged.

MongoDB runs anywhere—as a managed service across all three major clouds (including cross-cloud clusters), or self-hosted in data centers, air-gapped environments, or laptops. Put MongoDB behind ExtendDB, and you can run your DynamoDB workload anywhere MongoDB can run (which is anywhere). Teams get more options to choose where their workloads live, without changing a line of application code.

Any organization that needs its DynamoDB access patterns to keep working through network outages or in disconnected environments—not just cloud-native teams, but airlines, factories, retailers, hospitals, or anyone running critical systems—can now run those workloads on MongoDB, which was built for exactly that kind of resilience.

What we built

AWS released ExtendDB, an open source adapter that enables applications written for DynamoDB to use different storage backends without migrating application code. We implemented a pluggable MongoDB backend that allows users to use MongoDB as the storage layer for DynamoDB workloads. Your application speaks DynamoDB, and that data is stored in MongoDB under the hood.

MongoDB is a natural fit because both MongoDB and DynamoDB support flexible, document-like data models. A DynamoDB item is a collection of attributes, and items in the same table can vary in shape. MongoDB’s flexible JSON-like document model provides a similar foundation, so many DynamoDB items can map naturally to MongoDB documents without any relational translation. That overlap is what made this a good candidate since the backend didn't need to invent a translation layer between two fundamentally different data models.

Here’s how we translated DynamoDB behavior into MongoDB primitives:

• Item keys and queries: DynamoDB partition and sort keys map to typed MongoDB document fields. Query and Scan operations map to MongoDB filters, sorts, and pagination.
• Secondary indexes: DynamoDB indexes map to separate MongoDB collections that are updated with the base item.
• Conditional writes and transactions: DynamoDB condition expressions map to backend condition checks. Transactional writes map to MongoDB session transactions that keep item, index, and stream changes atomic.
• Streams: DynamoDB stream events map to MongoDB stream-record documents, with sequence numbers assigned in the same transaction as the data change.
• Conflicts and consistency: DynamoDB retryable conflicts map to MongoDB conflict retries. Supported consistent reads use primary reads and majority writes, while strong reads on global secondary indexes are rejected.

Having said that, some DynamoDB concepts don't map cleanly to MongoDB, and we’ve had to adjust the implementation. For example:

• Numeric precision: DynamoDB numbers support up to 38 digits of precision, while MongoDB's Decimal128 supports 34. DynamoDB also stores numbers as strings under the hood, which breaks numeric comparisons if we push them down as-is. So for queries that involve number comparisons, we do the comparison in the Rust layer instead of pushing it down to MongoDB.

More detail on tradeoffs and design decisions in the RFC and design doc — we'd love feedback and bug reports!

How this project started

This started as a fun experiment during our “Skunkworks” week, MongoDB's company-wide hackathon where people across our Product and Engineering orgs step away from quarterly priorities to build something that wouldn't otherwise get built.

One of our engineers had watched AWS launch ExtendDB earlier this year and wondered: could Claude Code one-shot a MongoDB backend for it? A pluggable storage layer with a well-defined contract is exactly the kind of problem shape that makes a good one-shottable prompt.

The answer turned out to be no. But Claude got remarkably far, and what it built shows how naturally DynamoDB's functionality can be served by MongoDB. Items became documents, keyed the same way. Secondary indexes became their own kept-in-sync structures. Streams became an ordered record of changes, and DynamoDB's all-or-nothing transactions mapped onto MongoDB's own. By lunchtime, an initial prompt had become a real component with real product and business value.

From there, landing it meant the actual work: several weeks partnering with the AWS team, going through their RFC process, working through multiple rounds of review feedback so the PR was ready to merge. The AWS team was genuinely great to work with throughout—they were thorough, generous with context on how DynamoDB is supposed to behave, and quick to help us understand and fix issues.

Without AI, this wouldn't have been built

The code is only part of the story. This began with a developer's Monday-morning question, room to pursue it, and a willingness to see this through.

AI changed the economics of that experiment. A MongoDB backend for ExtendDB is meaningful product work, far too large to casually pick up between planned priorities under a conventional development model. With Claude, the idea could move from "interesting thought" to a working implementation quickly enough to justify the cost. Without AI, this wouldn't have been built.

That's the kind of iteration we want more of: Developers or PMs spotting an opportunity, iterating and testing at the speed of thought, and producing something concrete that users can evaluate. MongoDB’s mission has always been about giving builders tools that let them move quickly from idea to application. Agentic coding tools extend that same principle to the development process itself, as the cost of finding out whether an idea is worthwhile has dropped dramatically.

Organizations don't need to trade focus for experimentation. They need to create space for small, high-conviction experiments, and give engineers tools that can turn the promising ones into real code before the opportunity disappears. In this case, the evidence arrived before lunch.