DefraDB: a peer-to-peer database where every write is verifiable

Merkle CRDTs over content-addressed data

The architecture is defined by two technologies and it is worth being precise about what each contributes. DefraDB is described as a zero-trust database that prioritises data verifiability, privacy and information security, and its data model is powered by the convergence of MerkleCRDTs and the content-addressability of IPLD. Merkle CRDTs are what make concurrent writes merge without a coordinator, since a conflict-free replicated data type gives every replica the same result regardless of the order updates arrive in. IPLD is the content addressing layer, meaning the identifier of a piece of data is derived from its content, so a peer can prove that what it holds is what everyone else holds without trusting the node that sent it. Put together, those two give the project its headline property, a multi-write-master architecture, which is the point. A conventional replicated database solves concurrency by electing a leader and making the others read-only, and this design instead lets every node write and then reconciles. The repository topics list crdt, database, distributed, documentdb, edge-ai, edge-compute, edge-first, graphql, linked-data, local-first-software, nosql, peer-to-peer and semantic-web, which is a fair summary of the design space it sits in.

DQL is GraphQL-shaped with convenience on top

The query language is the part a developer touches first, and the positioning is careful. DQL is described as a query language compatible with GraphQL but providing extra convenience, and it has its own reference documentation for the query specification and language overview. GraphQL compatibility is a deliberate choice with a real payoff. Any tool that already speaks GraphQL, including a native GraphQL client as the documentation recommends for experimenting with queries, can drive DefraDB without learning a new wire protocol, and the HTTP API is GraphQL-shaped, which is why the documentation has a section on securing the HTTP API with TLS and another on supporting CORS. The convenience the documentation refers to is not enumerated in what is available here, so the honest way to assess it is to read the query language overview and try your own queries. The repository also carries an explorer directory, which is presumably the browser-based playground for a DefraDB instance, and the documentation points to a separate Explorer in its table of contents, so there is at least one place where you can try the language without setting anything up.

Access control is a policy language over relationships

The access control system is the most unusual part of the design and the easiest to misjudge from a distance. Access control is determined by a relationship-based DSL, supporting document-level or field-level policies, secured by the Vera network. A document store that can express field-level policies natively is doing something most databases leave to the application, and the fact that the policy language is relationship-based rather than role-based matters for a distributed system, since the relationships between a subject, a document and an action are the things that can be evaluated identically on every node without a central policy service. Securing those policies with the Vera network is the part that ties it to the Source ecosystem, and the README describes DefraDB as a core part of the Source technologies that enable new paradigms of decentralised data and access-control management. The examples directory has a policy folder alongside the collection and request examples, so the working shape of a policy is something you can read rather than only imagine. The cost of this model is that policy evaluation is part of the data path, and a deployment has to be tested against the specific policies it will enforce, not against a generic role matrix.

Keys, keyring and the peer identity every node needs

Every node holds cryptographic keys, and the documentation is specific about what and why. DefraDB has a built-in keyring that can be used to store private keys securely, and three keys are loaded from it on start. The peer-key is an Ed25519 private key and it is required. The encryption-key is AES-128, AES-192 or AES-256 and is optional. The node-identity-key is a Secp256k1 private key and is optional, and it is used for the node's identity, which is described as an identity assigned to the node and used to exchange encryption keys with other nodes. A secret to open the keyring is required on start and must be provided through the DEFRA_KEYRING_SECRET environment variable, or through a .env file in the working directory, or through a file at a path given by the secret-file flag. The keys are randomly generated on the initial start of the node if they are not found, and there is a command to do that explicitly, plus a command to import externally generated keys by name and hex. Three curves for three purposes is a fair amount of key management for an operator, and the fact that a missing keyring secret stops the node from starting is worth knowing before a deployment rather than during one.

Building it needs more memory than you would expect

The build requirements section is unusually candid, and it is the first thing to read if you plan to compile rather than download a release. Go 1.26 or later is required, along with Git and a Rust toolchain for WASM lens compilation if you are running the tests. The resource table gives a minimum of 2 GB of RAM and 3 GB of disk, with 4 GB or more of RAM and 5 GB or more of disk recommended, and the stated reason is that the Go compiler requires substantial memory during compilation and that builds with less than 2 GB of available RAM will likely fail with out-of-memory errors. The troubleshooting guidance for constrained systems is concrete. For out of memory, ensure at least 2 GB is available, add swap if physical RAM is limited, or limit compiler parallelism with the -p 1 flag on the build. If /tmp is a small tmpfs, the Go compiler can exhaust the space, and the fix is to redirect the temp, build cache and module cache directories to a location with more room. For extremely constrained environments the documentation suggests disabling optimisations, which produces a slower binary. The install route itself is a clone and a make install:

git clone https://github.com/sourcenetwork/defradb.git
cd defradb
make install

If you built it with the Go toolchain rather than downloading a release executable, the documentation asks you to put the binary on your path:

export PATH=$PATH:$(go env GOPATH)/bin

Once the binary is reachable you start a node with defradb start, keep it running, and check the local connection from a second terminal with defradb client collection describe.

The build tooling, the ecosystem packages and the licensing gap

The repository shows a project with several front ends over one core. There is a cli directory, a client directory, a node directory, an http directory, a keyring directory, a crypto directory, a clock directory, an event directory, a js directory, an explorer directory, an acp directory, a cbindings directory for C bindings, an internal directory and a tools directory, alongside version, errors, license and test directories. The dependency list confirms the shape of the ecosystem. The peer-to-peer layer is libp2p with the multiaddr, multibase, multihash and multicodec packages, and the content addressing layer is the IPLD stack with go-cid, go-ipld-format, go-ipld-prime and the boxo and go-datastore packages. The Cosmos SDK appears with gogoproto, and the Badger key-value store is present through the corekv packages. The HTTP layer is chi with a CORS middleware, and the OpenAPI tooling is kin-openapi. The build Makefile detects the operating system and its package manager, and passes the git commit, commit date and release into the version package through linker flags, with the release derived from a tag on master and a dev prefix otherwise. The licence field for the repository is not identified, although the repository carries a licenses directory, so the terms have to be read from the files rather than assumed, and the project states the software is provided as is and is not guaranteed to be stable, secure or error-free.

Editorial conclusion

DefraDB is a good fit for a team building a local-first or peer-to-peer application where several nodes must write to the same data and where the requirement is that each peer can verify what it holds rather than trust a central authority. It is the wrong tool for a conventional server-side application, since a single-writer relational store is simpler and faster, and it is the wrong tool if you need a stable query language or a mature operational story today, because the project ships a disclaimer that the software is provided as is and is not guaranteed to be stable, secure or error-free. Before adopting it, read the disclaimer and the key management section, because the peer key is required and the keyring secret has to be supplied on every start, and check the build requirements, since compiling it needs Go 1.26 or later and 4 GB of RAM is recommended. The last push was on 2026-10-19 and the most recent release is v1.1.0 from 2026-09-08.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. sourcenetwork/defradb on GitHub