Summary
ExtendDB's core value: a DynamoDB-compatible API over multiple storage backends. The implementation covers all mandatory and optional traits defined in RFC-0002, uses the existing inventory-based plugin registration system without modifying the server or engine layers, and is maintained by the MongoDB team who commit to ongoing ownership of the backend crate. A feature-complete implementation already exists at mongodb-forks/extenddb (branch extenddb-on-mongo) and is ready for review.
Motivation
ExtendDB's core premise is DynamoDB API compatibility over multiple storage backends. MongoDB is a natural fit as an additional target: DynamoDB items are schema less JSON-like documents and MongoDB's native document model maps to this directly with no impedance mismatch. Organizations already running MongoDB do not want to operate a PostgreSQL instance solely for DynamoDB compatibility. MongoDB replica sets also offer a horizontal scaling story that complements PostgreSQL's vertical scaling story.
Proposed design
Full design is in the RFC PR (linked below). In brief:
- New optional crate extenddb-storage-mongodb at crates/storage-mongodb/, selected via a mongodb Cargo feature flag
- Two MongoDB databases: extenddb_catalog (17 collections for table definitions, IAM, settings, metrics) and extenddb_data (one collection per DynamoDB table, one per index)
- DynamoDB items stored as BSON documents with typed sort key fields and full item data in item_data
- Condition expressions compiled to MongoDB filters and executed via atomic findOneAndReplace / findOneAndDelete — no separate fetch, no race window
- Global and Local Secondary Indexes updated synchronously inline with a DashMap cache to avoid catalog lookups on tables with no indexes
- TransactWriteItems backed by MongoDB multi-document ACID transactions (requires replica set)
- DynamoDB Streams implemented via explicit stream_records collection with CRC32 shard assignment and atomic sequence numbers
- Application-level TTL worker emitting stream records with the correct DynamoDB service identity
- New [storage.mongodb] section in extenddb.toml; no changes to extenddb.toml defaults or the PostgreSQL backend
DynamoDB compatibility
How does this relate to the real DynamoDB API? Is this:
Alternatives considered
- MongoDB has a native change data capture feature (Change Streams) that could back DynamoDB Streams. This approach was not fully evaluated. The implementation instead adopted the explicit
stream_records collection approach used by the PostgreSQL backend, which gives ExtendDB full control over sequence number generation, shard assignment, record retention, and iterator behavior — all of which the DynamoDB Streams API contract tightly specifies. Reviewers are invited to weigh in on whether a comparative evaluation of the Change Streams approach should be documented before acceptance.
Breaking changes
None.
Open questions
None. The RFC is complete. See the RFC fork code for the full design implementation.
##Links
Summary
ExtendDB's core value: a DynamoDB-compatible API over multiple storage backends. The implementation covers all mandatory and optional traits defined in RFC-0002, uses the existing inventory-based plugin registration system without modifying the server or engine layers, and is maintained by the MongoDB team who commit to ongoing ownership of the backend crate. A feature-complete implementation already exists at mongodb-forks/extenddb (branch extenddb-on-mongo) and is ready for review.
Motivation
ExtendDB's core premise is DynamoDB API compatibility over multiple storage backends. MongoDB is a natural fit as an additional target: DynamoDB items are schema less JSON-like documents and MongoDB's native document model maps to this directly with no impedance mismatch. Organizations already running MongoDB do not want to operate a PostgreSQL instance solely for DynamoDB compatibility. MongoDB replica sets also offer a horizontal scaling story that complements PostgreSQL's vertical scaling story.
Proposed design
Full design is in the RFC PR (linked below). In brief:
DynamoDB compatibility
How does this relate to the real DynamoDB API? Is this:
Alternatives considered
stream_recordscollection approach used by the PostgreSQL backend, which gives ExtendDB full control over sequence number generation, shard assignment, record retention, and iterator behavior — all of which the DynamoDB Streams API contract tightly specifies. Reviewers are invited to weigh in on whether a comparative evaluation of the Change Streams approach should be documented before acceptance.Breaking changes
None.
Open questions
None. The RFC is complete. See the RFC fork code for the full design implementation.
##Links