dgraph: a sharded graph database with distributed ACID transactions
high-performance graph database for real-time use cases
At a glance
- What is it?
- Dgraph stores data as a graph, spreads it across shards with Raft replication, and exposes it over GraphQL, gRPC and HTTP. The README is explicit about who should reach for it and who should not.
- Who is it for?
- dgraph fits a specific shape of problem: sparse, heavily connected data where joins in SQL are the bottleneck, on Linux hosts you control, reached over GraphQL. It is a poor substitute for a relational database when your data is tabular and your queries are aggregates over columns, and the README's own checklist says so by asking whether you have more than ten tables joined by foreign keys.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 23 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 20, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Starting a standalone node with one docker image
The README recommends Docker as both the testing and the deployment method, and gives two commands. The first pulls the official image:
docker pull dgraph/dgraph:latestThe second runs a complete standalone cluster with two ports published and a host directory mounted for data:
docker run -it -p 8080:8080 -p 9080:9080 -v ~/dgraph:/dgraph dgraph/standalone:latestThe `standalone` tag is the interesting one. A full Dgraph deployment has more than one role, and the standalone image bundles them so you can get a working node without thinking about topology. The `Dockerfile` in the repository shows how: a first stage builds the binary with `CGO_ENABLED=0` from a `golang:1.27.0` base, and a second stage copies that binary and `contrib/standalone/run.sh` into an `ubuntu:24.04` image. The final image carries `jq`, `curl`, `htop` and `sysstat`, so you have something to inspect a running node with.
Ports 8080 and 9080 are the HTTP and gRPC endpoints respectively, which matches the README's claim that Dgraph answers over gRPC and HTTP. That pairing is the first thing to get used to: unlike a database you talk to over a socket, Dgraph is a service you reach over HTTP.
Building from source when you need a specific binary
The README's source path assumes Go 1.27 or later. On Ubuntu the prerequisite is the standard build toolchain:
sudo apt-get update
sudo apt-get install build-essentialThen clone, prepare and install:
git clone https://github.com/dgraph-io/dgraph.git
cd dgraph
make setup
make install`make install` puts the binary in the directory named by `GOBIN`, which the README explains defaults to `$GOPATH/bin`, or `$HOME/go/bin` when `GOPATH` is unset. The `Makefile` in the repository guards against exactly that empty case, erroring out if `GOPATH` resolves to nothing rather than writing to `/bin`.
That `Makefile` also handles a wrinkle worth knowing about if you build on a Mac or on Windows. Cross-compilation is supported for use cases like live and bulk loading, but the Makefile sets up a separate Linux output directory and a cross compiler so that CGO remains available, because CGO is required for plugin support. Supported platforms for actually running Dgraph are Linux amd64 and Linux arm64.
Sharding, Raft writes and how Zero holds the cluster together
The architecture claim in the README is that Dgraph arranges data on disk to fit the queries it expects, which is what lets it cut down disk seeks and network calls. The repository tree shows the pieces that carry that out. `posting/` is the storage layer and the biggest single subsystem, `algo/` holds the index and list algorithms, `xidmap/` maps external identifiers to internal uids, and `raftwal/` is the write ahead log that makes Raft replication durable. `worker/` and `edgraph/` handle distributed calls and the entry point into the graph, `query/` and `dql/` cover the query languages, and `graphql/` is the GraphQL layer.
The `go.mod` file makes the storage choice explicit: Dgraph depends on `github.com/dgraph-io/badger/v4` at v4.9.4 for its key value substrate, `ristretto/v2` for caching, and `bleve/v2` for full-text indexing. Kafka via Sarama, MinIO, Prometheus, Vault's API client and `mcp-go` are also in the dependency list, which hints at the integrations around the database rather than inside the storage path.
On the transactional side the README promises ACID transactions, consistent replication and linearizable reads across shards. Shard rebalancing is automatic, per the comparison table it includes. That is the substantive difference from a single-server graph database, and it is also the source of the operational work.
Reading the v25 release notes for the operational details
The README states that Dgraph is at version v25 and production ready. The recent releases show what that line actually changes. v25.4.1, published 2026-08-24, made rollup failures diagnosable in logs and upgraded Go to 1.27.0. v25.3.8, published 2026-07-09, bumped badger to v4.9.4 and ristretto to v2.4.2.
The one to read carefully is v25.4.0 from 2026-07-30, because it carries a warning. Zero, the component that manages cluster membership, now accepts a `--security` superflag in the form `token=...;whitelist=...` and authorizes its administrative HTTP endpoints against it. The release notes state plainly that those endpoints on the default port 6080 previously had no authentication, and that `/removeNode` and `/moveTablet` are now always guarded, admitting only loopback callers when no token or whitelist is set. Anyone driving those endpoints remotely has to set the flag explicitly.
That is the kind of change that justifies reading release notes rather than pulling `latest` blindly. The repository also carries `upgrade/`, `check_upgrade/`, `CHANGELOG.md`, `TESTING.md` and `SECURITY.md` at the top level, so upgrade behaviour is treated as a first-class concern. The default branch `main` was last pushed on 2026-09-18, and the repository is not archived.
How Dgraph compares to Neo4j and JanusGraph
The README includes a comparison table against Neo4j and Janus Graph, and it is worth reading closely because it is where the trade-offs are stated without marketing. On architecture, Dgraph is sharded and distributed, Neo4j community is a single server with replicas only in the enterprise edition, and Janus Graph is a layer on top of other distributed databases. On replication, Dgraph is consistent, Neo4j community has none, and Janus Graph inherits whatever the underlying database does.
The query side diverges sharply. Dgraph's language is GraphQL inspired, Neo4j uses Cypher, Janus Graph uses Gremlin. Protocols follow: gRPC or HTTP with JSON or RDF for Dgraph, Bolt with Cypher for Neo4j, WebSocket or HTTP for Janus Graph. The transaction row is the one to sit with, because distributed ACID transactions are both Dgraph's strongest claim and its most expensive feature. Neo4j's community edition is single-server ACID, and Janus Graph is not typically ACID at all.
Full-text search, regular expressions and geo search are native in both Dgraph and Neo4j. Janus Graph needs an external indexing system for all three. Licensing is Apache 2.0 for Dgraph and Janus Graph against GPL v3 for Neo4j, which matters if you intend to embed rather than run a service.
Where the README ends and the documentation begins
The README does not teach the query language. It states the architecture claims, the platform support policy, the install paths, the comparison table, and then hands off. Everything else lives on docs.dgraph.io, including the quick start it links as installation to queries in four steps and a YouTube playlist of tutorials.
That split is normal for a project of this size and it does mean the README alone will not settle an adoption question. Schema design, the difference between DQL and GraphQL, ACL setup, backup and restore, and cluster sizing are all documentation topics. The repository does contain a substantial body of example code: `t/` and `systest/` hold system tests, `dgraphtest/` is a test harness, and `compose/` has Docker Compose material. Reading those is a reasonable way to see what a working configuration looks like when the prose docs are not enough.
The honest summary is that Dgraph is a capable distributed database with real depth behind it, aimed at a problem that a relational schema handles badly, and it is only supported on Linux. If your workload is genuinely graph shaped, the README's checklist of more than ten tables joined by foreign keys, sparse data and a need for speed at scale is a reasonable starting filter. If it is not, the distributed transaction cost buys you nothing.
Editorial conclusion
dgraph fits a specific shape of problem: sparse, heavily connected data where joins in SQL are the bottleneck, on Linux hosts you control, reached over GraphQL. It is a poor substitute for a relational database when your data is tabular and your queries are aggregates over columns, and the README's own checklist says so by asking whether you have more than ten tables joined by foreign keys. Two things to verify before committing: the platform question, since official support covers Linux amd64 and arm64 only, and the Zero security flag, because v25.4.0 changed how the admin HTTP endpoints on port 6080 authenticate. Start with the standalone Docker image, load a schema through the quick start on docs.dgraph.io, and only then plan the cluster topology.
Frequently asked questions
What is a dgraph?
Dgraph is a horizontally scalable, distributed graph database with a graph backend, written in Go and licensed under Apache 2.0. It provides ACID transactions, consistent replication and linearizable reads, and it exposes a GraphQL inspired query language plus DQL, responding in JSON or Protocol Buffers over gRPC and HTTP.
Can Dgraph run on macOS or Windows?
You can build and use it there, for live or bulk loading for instance, but it is not supported. Dgraph officially supports Linux amd64 and Linux arm64, and official support for Mac and Windows was dropped in 2021. The README recommends running it in Docker, and the Makefile is set up to cross-compile Linux binaries with CGO available for plugin support.
How does Dgraph store and replicate data across nodes?
Data is sharded across the cluster and replicated consistently, with shard rebalancing handled automatically. Durability comes from a Raft write ahead log in the `raftwal/` directory, and the key value substrate underneath is badger v4, with ristretto for caching. The practical consequence is that you get distributed ACID transactions and linearizable reads rather than the single-server transactions a community edition of a comparable graph database offers.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/dgraph-io-dgraph)