DoltHub gives MongoDB changes a commit history, with one security catch

Why it matters

DumboDB offers a way to inspect MongoDB document changes without first migrating the application. Replication V1's authentication and TLS limits keep that approach out of realistic deployments for now.

Tim Sehn, co-founder and CEO of DoltHub, has spent years trying to make database changes as inspectable as changes to code. On September 22nd, DoltHub announced a way to bring that idea to an existing MongoDB deployment: its DumboDB document database can join a MongoDB replica set, consume its changes and turn them into a commit history. The first version cannot replicate from a deployment with authentication or TLS enabled.

Sehn traced the idea back to a 2013 Amazon Web Services offsite, where he began asking why data could not be shared as readily as computing capacity. He later served as Snap's senior vice president of engineering, according to his public biography. In 2018, co-founders Aaron Son and Brian Hendriks joined him in his basement to work on a data-sharing startup. Hendriks put a Git-style command line on an existing version-controlled data project; the founders recognized the basis for Dolt, their MySQL-compatible database. DumboDB extends that founding idea to documents, and this week's release lets it receive changes from MongoDB rather than requiring users to start with a new database.

DumboDB engineer Neil Macneale wrote the replication announcement. In an April account of starting the project, Macneale said DoltHub had been discussing a MongoDB clone built on Dolt's storage technology before he took it on as a project. DoltHub released DumboDB 0.1 in May; in September, Macneale described the first phase of its clone, push and pull workflow. Replication gives those version-control features a new route into data that already lives in MongoDB.

A replica that records, rather than takes over

DoltHub's design keeps the MongoDB replica set in charge. DumboDB must join as a hidden, non-voting member with priority zero. It reads MongoDB's oplog, but cannot become primary, does not participate in elections and does not count toward a majority write acknowledgment. DumboDB refuses to replicate unless all three settings are in place, according to Macneale's walkthrough. MongoDB's own documentation confirms the distinct roles of hidden, priority-zero and non-voting members.

That constraint defines the product's immediate use. DumboDB is a change sink, not a replacement for MongoDB's failover machinery. In DoltHub's demonstration, two documents are inserted into MongoDB and one document's qty field changes from 10 to 99. After replication, a query against DumboDB returns the updated document. Its dumboLog command also shows a separate commit for the update, including the field-level path $.qty and the old and new values. Macneale says each replication event becomes a commit; the example shows what that means for one small sequence of writes, rather than establishing performance under sustained traffic.

The distinction matters because a conventional replica maintains another copy of the database's state. DoltHub is trying to make the path to that state inspectable. Its earlier MySQL binlog replication guide describes a similar approach for Dolt, recording source transactions as commits. DumboDB applies the idea to MongoDB's replication stream and document-level diffs.

Other databases pursue auditable history through different interfaces. TerminusDB offers branching and merging for documents and knowledge graphs; XTDB emphasizes immutable records and time-travel queries. DoltHub's particular bet is that operators will find a versioned view of their existing MongoDB writes useful before they are willing to move an application to a different database. That is an inference from the replica design, not a customer-adoption claim.

The deployment boundary

DoltHub's demonstration uses MongoDB 8.0.28 and DumboDB 0.6.4 on local addresses without authentication. Macneale writes that replication V1 does not work when MongoDB's --auth setting is enabled or over TLS, and calls authentication and authorization support a blocker for a realistic setup. DoltHub's repository documentation describes authentication for DumboDB's ordinary, single-node mode; that does not remove the limitation on the new replication path. The repository also labels DumboDB pre-1.0 and not ready for production use.

DoltHub has not presented this release as full MongoDB replica-set support. Macneale says that is not currently planned. He raises the possibility of applying a change made in DumboDB back to MongoDB, which would make offline work more useful, but describes it as something DoltHub could consider, not a shipped feature. For now, writes go to the MongoDB primary and the DumboDB member is read-only.

The sequence also puts a useful boundary around DoltHub's broader pitch. RuntimeWire reported on the September clone, push and pull release, when DoltHub's announcement and roadmap gave different impressions of how complete that workflow was. Macneale's release post called it phase one and said DoltHub could store a DumboDB repository without yet offering a native query experience for it on the website. Replication V1 adds a concrete way to collect document history, while leaving the work of securing and operating that collector ahead.

The effort sits within a funded, longer-running database business. CB Insights lists $21 million raised across three financings, including a $16 million Series A in October 2021, and names Alpha Edison as an investor. The figure is a funding-database tally, not a measure of DumboDB's traction. For Sehn's team, the next test of the MongoDB integration is practical: making the change history available on the authenticated, encrypted deployments where operators would need it.