OrbitDB ships version 4.0.0 with no releases, and its make build runs your tests first

The package says 4.0.0 and the repository has published no releases

The package manifest declares the current version:

  "version": "4.0.0",

There is no release series behind it. The repository publishes no GitHub releases, so there is no release asset to download and no release notes on GitHub. What exists instead is a changelog file in the tree and a version string inside the manifest. Consequence: the only way to pin OrbitDB is to pin an npm version, and the only way to reproduce a specific build is to record the resolved dependency tree, because a checkout of the default branch gives you whatever the manifest said that day. That is a thinner release trail than the version number suggests.

The published entry point is the source directory, not the bundle

Three fields in the manifest decide what an installed copy actually is. The package ships two directories, the source directory and the distribution directory. The module type is set to module. And the main entry is declared as:

  "main": "src/index.js",

So the file Node resolves when someone imports the package is a source file, not the webpack output. The distribution directory exists for the browser path, where the built file is loaded through a script tag. Consequence: consumers compile OrbitDB as part of their own build, which means the declared Node floor becomes their constraint rather than yours, and two projects on different bundlers can end up resolving the same source differently. It also means the bundle the project builds in its own pipeline is not what a Node application runs.

Building from the Makefile requires the test suite to pass first

The Makefile is short and its dependency chain runs backwards from what you would expect. The default target is build. The test target depends on a dependency step that runs the install, and the build target depends on test. So building implies installing, testing and only then building. The clean target removes the dependency directory, the generated API documentation, the distribution directory and the browser test bundle in one sweep, and a separate target removes the lockfile on top of that. Consequence: you cannot produce a distribution build on a machine where the tests do not pass, which couples your release to someone else's test run. The npm scripts offer the same work without the gate, so the two entry points behave differently, and the rebuild target deletes the lockfile before rebuilding.

The quick start example switches off a pubsub safety check

The usage snippet wires libp2p by hand, and the pubsub service is configured with one non-default option:

    pubsub: gossipsub({
      // neccessary to run a single peer
      allowPublishToZeroTopicPeers: true
    }),

The comment states the reason plainly, it is necessary to run a single peer. Consequence: the documented starting example deliberately relaxes a rule that stops a node publishing into a topic with no subscribers, which is the normal case for a database nobody has joined yet. That is the right trade for a first run and the wrong one to copy into a deployment, because the same line lets a node publish into a topic that has lost its subscribers, so a partition looks like success rather than like an error. Set it for the first peer and reconsider it once there are more.

The browser path hands you a global namespace and a bundled IPFS

There are two supported ways to load the library. One is as a module, paired with a JavaScript IPFS instance, which is what the usage example does. The other is a script tag pointing at the distributed file:

<script>/path/to/orbitdb.min.js</script>

The description of that path says OrbitDB becomes the global namespace and every external function is reachable through it. Consequence: the browser route exposes everything through one global rather than through module imports. The same global also means a page that loads the file twice, or loads it next to another library with the same names, has no isolation to fall back on.

One of the four database names hides a different storage engine

Four data models are offered. Events is an immutable append-only log with traversable history, positioned for latest-N queries or as a message queue. Documents stores JSON documents indexed by a key you name, positioned for search indices and version control. Keyvalue is the plain one. The fourth is keyvalue-indexed, described as key-value data indexed in a Level key-value database. Consequence: the fourth keeps its key-value data indexed in a Level database, which the plain keyvalue description does not mention. More importantly all four sit on the same operation log, an immutable, cryptographically verifiable, operation-based structure, so even a plain key-value write is an operation appended to a log rather than an in-place update.

The Python entry point is a client, not a second implementation

The README lists other implementations, and there are two. The Go one is developed and maintained by another project entirely, and this repository does not carry it. The Python one is a client library with an HTTP client in its name. Consequence: a Python deployment is a consumer of a running OrbitDB node, not a host of one, so a stack written entirely in Python still needs a JavaScript node somewhere holding the database and serving requests. The same split applies to Go, where this repository points outward for maintenance rather than shipping the code. That also means cross-language work goes through the network boundary rather than through shared on-disk state, which is the cost of the split.

Node 22 is the floor and the browser tests need a downloaded browser

The manifest constrains the runtime:

    "node": ">=22.0.0"

There is also a Node version file at the top of the repository, and the browser test script does not run mocha directly. It builds a test bundle first, then invokes the Playwright test runner against that bundle with mocha as the runner. Consequence: contributing needs a current Node and, for the browser suite, a browser binary fetched on first use, so the first run of that suite is slow and network-dependent. Because the bundle is a build step in front of the test step, a bundling failure shows up as a test failure, and the browser path and the Node path can disagree about what passed even though both are described as the same suite.

Editorial conclusion

OrbitDB fits a local-first or decentralised application where every participant can hold a replica, where conflict resolution has to be automatic rather than negotiated, and where you are willing to run IPFS and libp2p in every node. It does not fit a workload that needs a server to be the single point of truth, because the whole design is serverless and eventually consistent, and it does not fit a team that installs from GitHub releases, because the repository publishes none. Before adopting it, pin the npm version rather than a branch, read the access controller documentation before deciding who may write, and check the encryption documentation before assuming a database's contents are private to its members, since that is a separate layer from storage.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. orbitdb/orbitdb on GitHub
4. README