Dgraph

Open-source graph database, honestly reviewed. No marketing fluff, just what you get when you self-host a distributed system.

TL;DR

• What it is: Open-source (Apache-2.0) distributed graph database with native GraphQL support and its own query language (DQL). Built for terabyte-scale, relationship-heavy data with ACID transactions [README].
• Who it’s for: Engineering teams building applications where data relationships are the core product — social graphs, recommendation engines, fraud detection, knowledge graphs. Not for non-technical founders and definitely not as a general-purpose database [README][2].
• Cost savings: Amazon Neptune (AWS’s managed graph database) bills by the hour plus storage plus I/O; at modest scale you’re looking at $300–$800+/month. Dgraph self-hosted is free software on whatever Linux VPS you can afford [README].
• Key strength: Genuinely native GraphQL API and horizontal scalability via predicate-based sharding. Real ACID transactions across a distributed cluster, which most graph databases don’t offer [README][3].
• Key weakness: Unpredictable CPU consumption in production, a long history of design pivots leaving features half-finished, and at least one real-world product team migrated away to PostgreSQL specifically because of resource usage problems [2][1].

---

What is Dgraph

Dgraph is a distributed graph database written in Go. The pitch in the README is technical and direct: “horizontally scalable and distributed GraphQL database with a graph backend” providing ACID transactions, consistent replication, and linearizable reads [README].

The architecture is built around a clean separation of concerns. Zero nodes manage cluster membership and transaction coordination. Alpha nodes store the actual data. This split allows horizontal scaling by adding Alpha nodes when data or query load grows, without redesigning your schema [3][4].

What makes Dgraph unusual in the graph database space is that GraphQL isn’t an API layer bolted on top — it’s the primary interface to the database. The schema you write in GraphQL becomes the database schema directly, and queries are served as GraphQL responses over HTTP [3][4]. For teams already building GraphQL APIs, the mental model is tight.

Alongside GraphQL, Dgraph ships DQL (Dgraph Query Language, formerly called GraphQL±), which is a superset of GraphQL syntax designed to handle queries that standard GraphQL can’t express — variable binding, aggregations, recursive traversals. You communicate over either HTTP or gRPC; gRPC is faster for high-throughput applications [4].

The project is production-ready at version v25 and is running at multiple Fortune 500 companies according to the README [README]. GitHub star count sits at 21,634. License is Apache-2.0, which means you can self-host, embed, and build commercial products on top of it without a commercial agreement.

One important operational note: official support covers Linux/amd64 and Linux/arm64 only. Windows and Mac support was dropped in 2021. The stated reason was memory performance gains specific to Linux. You can technically build from source on other platforms, but you’re on your own [README].

---

Why people choose it (and why some leave)

The honest synthesis from available articles is mixed in a way that most review sites paper over.

The case for choosing Dgraph rests on a genuine architectural fit for certain problems. The PuppyGraph comparison piece [3] frames it well: if your data is fundamentally relational — social connections, linked knowledge graphs, fraud networks — then forcing it into SQL tables with foreign key joins creates real performance problems as the graph grows deep. Dgraph’s distributed joins and traversals are designed to handle that load natively. The same review notes that DQL and the GraphQL API together give you a flexible interface without forcing all queries through a translation layer (unlike using Cypher via Neo4j or Hasura in front of a relational store) [3][4].

The Kubernetes tutorial [4] is a good signal: the Helm-based deployment story is coherent enough that people are writing “getting started” guides for production-ish setups on managed Kubernetes. That means the deployment infrastructure exists and works, even if it requires real engineering judgment to tune.

The case against is harder to ignore because it comes from a team that actually built a product on Dgraph and migrated away.

The Capacities app — a “tool for thought” with notes connected in webs — chose Dgraph precisely because the graph model fit the user’s mental model. After operating it in production, their primary complaint was unpredictable CPU consumption [2]. From their post-mortem: “Dgraph’s resource usage was unpredictably high, even with modest datasets. We found ourselves at a crossroads: horizontally scale a complex cluster (without the traffic to justify it) or vertically scale our servers to much more expensive machines.” They cite GitHub Issue #1938 and community discussions as confirmation they weren’t alone [2]. Their migration destination was PostgreSQL, using recursive CTEs for graph traversal — a boring solution that turned out to be operationally more predictable.

There’s also a longer-running concern from the community itself. A detailed post on the Dgraph discussion forum [1] documents a pattern of design pivots across the project’s history — GraphQL to DQL, no schema to schema, RocksDB to Badger (Dgraph’s own key-value store), Windows/Mac support then dropped, vector support evolving through multiple iterations. The author’s observation: nearly every pivot maintains backward compatibility, but tends to leave the previous solution “80% complete.” DQL is missing features that were promised before the team shifted focus to GraphQL spec compliance. Auth limitations went largely unaddressed when lambda hooks were introduced. The pattern described is half-finished infrastructure that keeps accumulating [1].

This doesn’t mean Dgraph is broken. It means you’re betting on a database with genuine architectural ambition, meaningful production deployments, and an open question about whether the team can close the last 20% on any given feature before the next pivot.

---

Features

Based on the README and documentation:

Core database:

• ACID transactions across a distributed cluster [README]
• Consistent replication and linearizable reads [README]
• Predicate-based sharding — data is distributed by predicate (field), not by node. This enables parallel query execution across shards [3]
• Native GraphQL schema-to-database mapping — write a GraphQL SDL schema, get a working graph database with generated CRUD operations [README][3]
• DQL for queries that GraphQL can’t express: aggregations, variable bindings, recursive graph traversals [3][4]
• HTTP and gRPC interfaces [README][4]
• JSON and Protocol Buffers response formats [README]

Query capabilities:

• Multi-hop graph traversals [3][4]
• Filtering, ordering, pagination at query time [README]
• Full-text search, geospatial indexing, facets on edges [docs]
• Vector search support (native, after previous lambda-based approach) [1]

Deployment:

• Docker (recommended path) [README]
• Helm charts for Kubernetes [4]
• Standalone single-node Docker image for development [README]
• Zero + Alpha node architecture for horizontal scaling

What’s missing or limited:

• GraphQL subscriptions (real-time) — support exists but community reports it’s incomplete [1]
• Auth/authorization within the GraphQL spec layer — has Lambda hooks but limitations that haven’t been addressed [1]
• No Windows or Mac native support [README]

---

Pricing: SaaS vs self-hosted math

Dgraph self-hosted:

• Software: $0 (Apache-2.0) [README]
• Infrastructure: depends heavily on cluster size. A single-node development setup runs fine on a modest VPS. A production HA cluster needs multiple Alpha nodes plus Zero nodes, each needing SSD storage for acceptable I/O performance [4]
• Rough floor for a production-capable cluster on cloud VMs: $100–200/month depending on instance sizes and storage

Amazon Neptune (the SaaS comparison point):

• Neptune charges per instance-hour, per storage GB, per million I/O requests
• A db.r5.large instance runs approximately $0.348/hour (~$250/month) before storage and I/O
• For a highly available cluster with Multi-AZ: closer to $500–$1,000+/month
• No free tier for sustained workloads

Neo4j Cloud (another comparison):

• AuraDB Free: limited instance, not production-grade
• AuraDB Professional: starts around $65/month for minimal instances, scales steeply
• AuraDB Enterprise: custom pricing

The math for a startup: A team running a graph workload on Neptune spending $500/month saves $400–$500/month by self-hosting Dgraph on equivalent cloud VMs. Over a year that’s $5,000–$6,000. But: Dgraph requires engineering time to operate. The Capacities team’s experience [2] suggests that “operational complexity” can easily consume those savings in engineering hours if your team doesn’t have distributed systems experience.

---

Deployment reality check

The recommended deployment path is Docker, with Docker Compose for multi-component setups and Helm for Kubernetes. The Kubernetes tutorial [4] covers a full HA setup including Zero and Alpha nodes, storage class configuration (SSD required for acceptable performance), and gRPC testing.

What you actually need for production:

• Linux (amd64 or arm64 — no exceptions) [README]
• Docker or Kubernetes
• SSD storage — spinning disk performance is unacceptable for Dgraph’s I/O patterns [4]
• Properly configured whitelist (default allows all IPs — you need to restrict this in production) [4]
• Enough RAM to hold working indexes in memory — the CPU/RAM demands are real [2]

What can go sideways:

• CPU consumption can be unpredictably high even with modest data volumes. The Capacities team hit this in production with what they describe as a non-trivially sized but not extraordinary dataset [2]. No reliable formula for capacity planning before you run it.
• The Zero/Alpha separation means a minimum viable production cluster is multiple containers. Single-node development is easy; real HA deployment is an infrastructure project [4].
• DQL has a learning curve separate from GraphQL. If you come in expecting standard GraphQL to cover everything, you’ll hit the edges quickly [1][3].
• Dropped Windows/Mac support means your development team works on Linux or uses Docker exclusively [README].

Realistic estimate: a developer familiar with Docker and Kubernetes can have a working Dgraph cluster running in an afternoon. Tuning it for production performance under real load is a longer project.

---

Pros and cons

Pros

• Apache-2.0 license. Genuinely free to use, embed, and build commercial products on. No “Fair-code” restrictions, no usage limits in the license [README].
• Native GraphQL interface. If your team is already building GraphQL APIs, Dgraph is a natural fit — the schema is the database schema. No ORM, no translation layer [README][3].
• Real ACID transactions across a distributed cluster. Most graph databases either sacrifice consistency for availability or require you to handle conflicts in application code. Dgraph offers both horizontal scale and strong consistency [README][3].
• Horizontal scalability by design. Predicate-based sharding means you can add Alpha nodes as data grows without a schema migration [3].
• DQL for complex traversals. When GraphQL’s query model isn’t enough, DQL handles recursive traversals, variable bindings, and aggregations that would be impractical in standard GraphQL [3][4].
• gRPC support. For high-throughput pipelines, gRPC is meaningfully faster than HTTP [4].
• Fortune 500 production use. The README claims real production deployments at that scale, which at minimum means the software has been stressed [README].

Cons

• Unpredictable CPU consumption. Documented by real teams in production [2] and by community reports (GitHub Issue #1938) [2]. Not an edge case — it’s a known enough problem to show up in migration post-mortems.
• History of half-finished features. The community’s own account describes a pattern of pivots that leave prior capabilities at 80% [1]. DQL missing promised features, auth limitations unaddressed after lambda hooks landed — these aren’t speculative, they’re documented.
• Linux only. Dropped Mac and Windows support in 2021 [README]. Fine for production, annoying for development teams on mixed OS environments.
• Not a starter database. The architecture is complex enough that non-technical founders can’t operate it. Requires real engineering judgment for capacity planning and tuning [2][4].
• Operational overhead isn’t free. The Capacities team’s conclusion after migrating to PostgreSQL was that the operational complexity of Dgraph consumed more resources than the graph model saved in query simplicity [2].
• DQL is a custom language. It looks like GraphQL but diverges from the spec. New team members have to learn it, and the divergence has its own history of design debt [1][3].
• Community concerns about project direction. The history post [1] raises questions about whether each new development priority leaves the previous one properly finished.

---

Who should use this / who shouldn’t

Use Dgraph if:

• Relationships between entities are the core of your application — not a feature, the product itself. Think: recommendation graphs, fraud detection networks, knowledge bases where traversal depth matters.
• You have engineers who understand distributed systems and can operate a multi-node cluster.
• You’re currently paying $500+/month for Neptune or a commercial graph database and want to eliminate that bill.
• Your team is already building GraphQL APIs and wants the schema to double as the database schema.
• You have the engineering capacity to benchmark and tune for your specific workload before committing.

Skip Dgraph (use PostgreSQL with recursive CTEs) if:

• You have a moderately connected dataset that you’ve been told “really needs a graph database.” The Capacities experience [2] suggests that PostgreSQL with proper indexing and recursive CTEs handles most workloads that teams initially reach for graph databases for.
• You’re a non-technical founder. The operational requirements are real and the debugging experience is not friendly.
• You need Mac or Windows native development environments [README].
• You can’t afford unpredictable CPU scaling costs in production [2].

Skip Dgraph (use Neo4j) if:

• You need Cypher — the most widely documented graph query language with the largest community of tutorials and examples.
• Your team is running analytics workloads rather than real-time queries.
• You want a single-vendor support contract.

Skip Dgraph (use ArangoDB) if:

• You need to mix document, key-value, and graph access patterns in one database [3].
• You want one query language (AQL) across all data models — though note ArangoDB shifted to BSL 1.1 licensing in 2024, which restricts commercial use [3].

---

Alternatives worth considering

• Neo4j — the incumbent. Cypher is the most-documented graph query language, large community, but commercial licensing for production features and closed-source at scale. Community Edition is free but limited.
• ArangoDB — multi-model (document + graph + key-value), AQL as a unified query language. More flexible if your data mixes graph and document patterns. Note: moved to Business Source License 1.1 in 2024, restricting commercial use [3].
• PostgreSQL with recursive CTEs — the boring answer that the Capacities team chose [2]. For graphs with moderate depth (under 5–6 hops), PostgreSQL with good indexing is operationally far simpler and performance is predictable. No specialized knowledge required.
• Amazon Neptune — managed service, no ops, but expensive and locked to AWS. GraphML and Sparql if you need standards compliance.
• PuppyGraph — zero-ETL graph query layer that sits on top of existing data stores (PostgreSQL, Snowflake, S3). Worth evaluating if you want graph traversal without migrating your data into a graph database at all [3].
• TigerGraph — enterprise-focused, MPP graph engine. Heavy commercial licensing but designed for very large-scale analytics graphs.

---

Bottom line

Dgraph is technically serious. The architecture — native GraphQL, ACID-compliant distributed transactions, predicate-based horizontal sharding — solves real problems that most databases don’t address at all. The Apache-2.0 license is clean, the GitHub star count reflects genuine interest, and Fortune 500 production deployments mean it’s been stress-tested at real scale.

But the honest summary is this: Dgraph rewards teams who go in with clear eyes about what they’re taking on. The CPU consumption issues that drove Capacities to PostgreSQL [2] aren’t a fringe complaint — they’re corroborated by community discussion and GitHub issues. The pattern of design pivots leaving features half-finished [1] means you should verify current feature status against the actual codebase, not the documentation. And “Linux only” isn’t a footnote, it’s an infrastructure constraint.

If you have a genuinely relationship-heavy workload, engineers who can operate distributed systems, and a $500+/month managed database bill you want to eliminate — Dgraph is worth evaluating seriously, with a proper benchmark on your own data before committing. If you’re looking for a simpler path to self-hosted graph queries, start with PostgreSQL recursive CTEs and only reach for a dedicated graph database when you’ve proven you actually need one.

---

Sources

1. amaster507, Discuss Dgraph — “A History Lesson and Challenge for Dgraph Users, Developers, and Management team” (Dec 2023). https://discuss.dgraph.io/t/a-history-lesson-and-challenge-for-dgraph-users-developers-and-management-team/19111
2. The Tech Noob — “Scaling Capacities: Why we swapped Dgraph for PostgreSQL”. https://the-tech-noob.com/blog/migrating-dgraph-to-rds
3. Matt Tanner, PuppyGraph — “Choosing Between ArangoDB and Dgraph: A Developer’s Guide” (Dec 12, 2025). https://www.puppygraph.com/blog/arangodb-vs-dgraph
4. Joaquín Menchaca, Medium — “Dgraph on Kubernetes: Getting Started with Dgraph on Kubernetes” (Dec 9, 2023). https://joachim8675309.medium.com/dgraph-on-kubernetes-1ed0a646947e

Primary sources:

• GitHub repository and README: https://github.com/dgraph-io/dgraph (21,634 stars, Apache-2.0 license)
• Official documentation: https://docs.dgraph.io
• Official website: https://dgraph.io