EloqDoc: a MongoDB compatible database built on object storage

Object storage is the durable tier, not a backup

The architectural bet is stated in the overview and it is the thing to understand first. Unlike MongoDB, which relies on three replica-set nodes for durability, EloqDoc treats cloud object storage as a first-class citizen. Durable, cross-availability-zone object storage serves as the persistent foundation, while local NVMe caching accelerates reads, and recent updates are written to a decoupled redo log component. The stated result is that this architecture minimises write latency while maintaining strong consistency and durability. The tiered storage section adds the important constraint that makes the design coherent: NVMe storage is ephemeral and lost when a node crashes, so it is used strictly as a cache for object storage, and all data remains safe and durable in cross-AZ object storage while still getting NVMe-level performance for frequently accessed data. That is a different durability story from a replica set. In a replica set the data is copied three times and the copies are the availability story, here the data is written once durably to object storage and the NVMe copy is disposable. Any capacity planning or failure model you build has to be written for that shape.

One compute replica, with storage doing the availability work

The deployment model is the other structural difference, and it follows from the storage story. EloqDoc typically runs a single compute replica with storage-level high availability, orchestrated by Kubernetes for automatic failover. The documentation gives the reasons as cutting infrastructure costs, avoiding redundant CPU and memory overhead, and delivering higher throughput across mixed read/write workloads. This is a genuinely different cost profile from MongoDB, where three nodes is the baseline for durability and the CPU and memory on the other two are, for a write-light workload, largely idle. It also means the failure domain moves. A replica set fails by losing a node and failing over to a replica, whereas here the compute layer fails over and the data layer is what survives. The elastic scalability section states the consequence as scaling compute and memory 100x faster than traditional databases by avoiding data movement on disk, scaling storage independently so that CPU resources remain constant when data volume grows but traffic stays the same, and scaling redo logs independently to optimise write throughput. Those are separate scaling axes, and the third one, the redo log, is the component that has to keep up with write-heavy ingestion.

MongoDB compatibility is the reason to look at it

The compatibility claim is the practical entry point. The overview describes EloqDoc as a high-performance, distributed transactional document database with MongoDB API compatibility, and the key features section says it integrates with MongoDB clients, drivers and tools, enabling existing MongoDB workflows to run against a distributed backend. The use cases named are web applications, document stores and content platforms, anywhere you need MongoDB API compatibility and expect distributed performance and elasticity. Two caveats belong alongside that. The first is that this repository contains the code for the pluggable MongoDB compatible API layer, sitting on top of EloqData's Data Substrate modular database foundation, with the dependencies included as submodules. So the artefact you can read here is the protocol frontend, not the whole database, and the storage foundation lives in a separate repository. The second is that the source in this repository is C++ and the build system is a mix of CMake, SCons and cmake directories, with a src directory, a tests directory, an etc directory and a scripts directory. A driver compatibility test is not the same as a compatibility guarantee for every MongoDB behaviour, and a project evaluating this should treat the compatibility claim as a starting point to test rather than a settled fact.

Three services, one instance, and the log that carries the writes

The architecture section names the components, and the naming tells you how the responsibilities are split. Each EloqDoc instance includes a frontend, compatible with the MongoDB protocol, deployed together with the core TxService to handle data operations. A logically independent LogService handles Write Ahead Logging to ensure persistence, while a Storage Service manages memory state checkpoints and cold data storage. Three processes with three scaling dimensions is the shape that produces the elasticity claims. The frontend and TxService are the request path, the LogService is the write path, and the Storage Service is the checkpoint and cold data path. The features this produces are listed as fast scaling, since compute and memory scale independently without disk data movement, storage flexibility, since storage scales separately from compute, write optimisation from the independently scaled redo log, and no sharding overhead, since data is distributed natively across the cluster without an additional sharding component. The sharding point deserves emphasis, because mongos is a piece of infrastructure that every MongoDB cluster at scale carries and that has to be operated, and a design that removes it is removing a failure domain and a configuration surface.

ACID transactions without a coordinator, and multiple writers

The transaction and concurrency claims are what a MongoDB user will press hardest, because and this is one of the areas where a newer architecture has an argument. The feature list states multiple writer support and fast distributed transactions, ensuring high concurrency and fault tolerance across a cluster without sharding complexity, and a separate entry claims ACID transaction support with especially fast distributed transactions, making it suitable for mission-critical applications. The simplified distributed design entry says it operates as a distributed database without requiring a sharding coordinator such as mongos, reducing operational complexity and overhead. Multi-writer support is the specific thing to test, since a single-writer replica set with fast failover is a much easier thing to build than a set of nodes that can all accept writes and agree. Whether the implementation meets the claim on a workload with genuine write contention is a question for your own tests, and the benchmark numbers in the documentation are about throughput and latency rather than about transaction isolation behaviour, so they do not settle it.

The benchmark is a vendor comparison with specific assumptions

The benchmark section is worth reading line by line rather than skimming, because the caveats are in the setup. All tests were conducted on AWS EC2 i4i.4xlarge instances with 16 vCPUs, 128 GB of RAM and high-performance local NVMe storage, and EloqDoc was evaluated against MongoDB Atlas across representative deployment scenarios, ranging from fully in-memory workloads to cases where the working set exceeds cache capacity. Both systems were benchmarked using identical client concurrency levels and dataset characteristics to ensure fairness and reproducibility. The headline results are qualified by working set. EloqDoc sustained up to 60% higher throughput than MongoDB Atlas for mixed 1:1 read/write workloads when the active dataset was fully cached, and roughly 60% higher peak throughput for read-heavy applications while maintaining lower latency across the concurrency range. The third result is the one that matters most for the architecture, and it is the one where the comparison is least like for like: when the workload required frequent disk accesses, the local NVMe cache plus object storage design preserved performance and availability, whereas the Atlas EBS-backed tier became IO-bound. Read that as a claim about what happens when the working set does not fit in cache. A comparison of a system whose durability tier is object storage against a system whose durability tier is EBS is measuring the storage products, not only the databases.

Licensing, nightly builds and the shape of the repository

The licence position needs care, and the facts here do not line up neatly. The licence field on the repository says Other, with a note that it is a custom licence GitHub cannot classify and that the LICENSE file is the place to look, while the badge in the README header says AGPL v3 and the repository root carries both a GNU-AGPL-3.0.txt and an APACHE-2.0.txt file. A dual licence file of that kind usually means the project offers the choice, and the choice matters a great deal for a database you intend to embed in a product, so the LICENSE file has to be read before anything else. This review takes no position on the legal terms. On releases, the listing shows a single entry, nightly, dated 2026-10-08, and the last push was on 2026-10-20, so the project is being worked on continuously and published as a rolling build rather than as versioned releases. That is workable for an evaluation and awkward as a production dependency, where you want a known commit and a way to know what changed. The repository also has a .private-modules directory, a .clang-format and a .clangd for C++ development, a .clangd configuration for the editor, a .editorconfig, an etc directory for packaged configuration, an images directory, and a docs directory, and it is hosted alongside a managed cloud offering called EloqCloud and a Discord invite.

Editorial conclusion

EloqDoc is a good fit for a team that has outgrown a single MongoDB replica set, that wants to keep the MongoDB driver and query model, and that is prepared to run a system whose newest release is a nightly build rather than a versioned one. It is the wrong tool for a project that wants a boring database with a long support history, since the release listing here is a nightly and the code is the API layer only, with the storage foundation living in a separate repository pulled in as submodules. Before adopting it, read the benchmark section carefully, because the comparison against MongoDB Atlas is a vendor run on specified hardware and the working set assumptions drive the result, and confirm the licence position yourself, since the licence field on the repository says GitHub cannot classify it while the repository carries both an AGPL and an Apache licence file. The last push was on 2026-10-20.

Frequently asked questions

Official sources

1. eloqdata/eloqdoc on GitHub
2. Issues
3. Project website
4. README
5. Releases