Push and clone are cheap in this storage model, and the reason bounds what the demo proves. DumboDB runs on Dolt's storage engine, which organizes content-addressed chunks in a Merkle directed acyclic graph [7]. Structural sharing lets a commit reuse unchanged data instead of storing an independent copy of every database state, and the same addressing yields stable identifiers for comparing and transferring versions [8]. For remotes, that is the whole trick: you move chunks by address rather than copying database states. It is also why the cloned copy in the walkthrough arrives with its branch and commit history attached rather than as a flat dump [5].
A `file://` remote on the same server exercises the chunk transfer and the command surface [5]. What the published demonstration does not show is a network transport, or two writers moving the same branch. Those are the parts that usually decide whether a data-sharing feature survives contact with a second team. And for a remote that is genuinely off the box, you supply the storage: DoltHub's hosted documentation as of August 7 covers Dolt, Doltgres and DoltLite, and lists no DumboDB workspace or storage endpoint [11].
The fetch design is the part I would keep. According to DoltHub engineer Neil Macneale, `dumboFetch` returns the branches that appeared or moved along with their previous and current commit identifiers [9], so a caller can gate a merge on identifiers instead of parsing a diff. That matches DoltHub's stated effort to expose database operations to software agents as explicit, reversible actions [10].
Then the ledger problem. The announcement went out September 1 [2]; runtimewire.com reports that the roadmap read on September 2, one day later, still filed clone, push and pull as future work and did not list fetch at all [3][17]. Of the four Git verbs in the announcement, three sit under future work and the fourth appears on the roadmap nowhere [18]. Both documents are published by the same company. A roadmap is the file no CI job checks, which is why it drifts, and pre-1.0 projects drift fastest [12].
This is a rule about pre-1.0 databases rather than a complaint about DumboDB. Bind the evaluation to a version tag and a test you ran, not to a repository page. DumboDB already let users commit and branch documents; sharing a database between server instances was the outstanding item [16], and eight years of Git for Data positioning [14] rests on that item existing. So it is worth exercising rather than reading about. My acceptance test would be 0.6.2, two hosts, a remote I control, and a fetch that names the branch plus both commit ids.
