Dgraph is aimed at minimizing network calls. In fact, the network calls are directly proportional to the complexity of the query, not the number of results. Which means the queries would maintain their latency even as you add more machines to the cluster.
https://github.com/dgraph-io/dgraph/blob/master/present/sydn...
In Scaling nodes in a Dgraph clusterdgraph-io
dgraph
Go2015–2024
dgraph-io / dgraph
dgraph
high-performance graph database for real-time use cases
36Distinct people
57Mentions
0Explicit recommenders
21.8KGitHub stars
What to know before exploring
What it is
high-performance graph database for real-time use cases
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 7:02:50 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year57 dated mentions
Observed mentions: 2015-12-01 17:43:10 UTC to 2024-03-12 22:56:47 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 17 | 2 | 15 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 12 | 1 | 11 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 18 | 2 | 16 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 1 | 0 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Dgraph is a horizontally scalable and distributed GraphQL database with a graph backend. It provides
ACID transactions, consistent replication, and linearizable reads. It's built from the ground up to
perform a rich set of queries. Being a native GraphQL database, it tightly controls how the data is
arranged on disk to optimize for query performance and throughput, reducing disk seeks and network
calls in a cluster.
Dgraph's goal is to provide Google production-level scale and throughput, with low enough latency to
serve real-time user queries over terabytes of structured data. Dgraph supports
GraphQL query syntax, and responds in JSON
and Protocol Buffers over
GRPC and HTTP. Dgraph is written using the Go Programming Language.
Status
Dgraph is at version v25 and is production-ready. Apart from the vast open source community,
it is being used in production at multiple Fortune 500 companies.
Supported Platforms
Dgraph officially supports the Linux/amd64 and Linux/arm64 architectures. In order to take advantage
of memory performance gains and other architecture-specific advancements in Linux, we dropped
official support for Mac and Windows in 2021, see
this blog post for more
information. You can still build and use Dgraph on other platforms (for live or bulk loading for
instance), but support for platforms other than Linux/amd64 and Linux/arm64 is not available.
Running Dgraph in a Docker environment is the recommended testing and deployment method.
Install with Docker
If you're using Docker, you can use the
official Dgraph image.
docker pull dgraph/dgraph:latest
For more information on a variety Docker deployment methods including Docker Compose and Kubernetes,
see the docs.
Run a Quick Standalone Cluster
docker run -it -p 8080:8080 -p 9080:9080 -v ~/dgraph:/dgraph dgraph/standalone:latest
Install from Source
If you want to install from source, install Go 1.27+ or later and the following dependencies:
Ubuntu
sudo apt-get update
sudo apt-get install build-essential
Build and Install
Then clone the Dgraph repository and use make install to install the Dgraph binary in the
directory named by the GOBIN environment variable, which defaults to $GOPATH/bin or $HOME/go/bin if
the GOPATH environment variable is not set.
git clone https://github.com/dgraph-io/dgraph.git
cd dgraph
make setup
make install
Get Started
To get started with Dgraph, follow:
Installation to queries in 4 quick steps.
Tutorial and presentation videos on
YouTube channel.
Is Dgraph the right choice for me?
Do you have more than 10 SQL tables connected via foreign keys?
Do you have sparse data, which doesn't elegantly fit into SQL tables?
Do you want a simple and flexible schema, which is readable and maintainable over time?
Do you care about speed and performance at scale?
If the answers to the above are YES, then Dgraph would be a great fit for your application. Dgraph
provides NoSQL like scalability while providing SQL like transactions and the ability to select,
filter, and aggregate data points. It combines that with distributed joins, traversals, and graph
operations, which makes it easy to build applications with it.
Dgraph compared to other graph DBs
Features
Dgraph
Neo4j
Janus Graph
Architecture
Sharded and Distributed
Single server (+ replicas in enterprise)
Layer on top of other distributed DBs
Replication
Consistent
None in community edition (only available in enterprise)
Via underlying DB
Data movement for shard rebalancing
Automatic
Not applicable (all data lies on each server)
Via underlying DB
Language
GraphQL inspired
Cypher
Gremlin
Protocols
Grpc / HTTP + JSON / RDF
Bolt + Cypher
Websocket / HTTP
Transactions
Distributed ACID transactions
Single server ACID transactions
Not typically ACID
Full-Text Search
Native support
Native support
Via External Indexing System
Regular Expressions
Native support
Native support
Via External Indexing System
Geo Search
Native support
External support only
Via External Indexing System
License
Apache 2.0
GPL v3
Apache 2.0
Users
Dgraph official documentation is present at docs.dgraph.io.
For general information and questions, visit
Github discussions.
Please see releases tab to find the latest release
and corresponding release notes.
Developers
Please see Contributing to Dgraph
for guidelines on contributions.
Client Libraries
The Dgraph team maintains several
officially supported client libraries. There are also libraries
contributed by the community
unofficial client libraries.
Contact
Please use Github discussions for questions,
feature requests and discussions.
Please use GitHub Issues for filing bugs or feature
requests.
Read the full README on GitHubWhat Hacker News says
17 sourcesThe writes for Dgraph actually happen in O(log N) time where N = number of subjects for a given predicate; and a background job then syncs the posting lists to disk later. So, that performance wouldn't be any worse than what we observe here.
However, to do writes like you would do them in production would require you to sync a mutation log to disk, before applying it in memory and returning an OK. This particular operation bounded by disk I/O would then become the bottleneck, and not help with doing benchmarking for the database. Which is why we didn't make writes part of this particular benchmark.
Dgraph does concurrent writes very well. To determine that, you can run Dgraph batch loader. It can load up the entire 21M triples from the blog post, in 20mins on an n1-standard GCE instance.
https://github.com/dgraph-io/dgraph#loader-performa
Read the rest
nce
When jumping from 2 to 5 nodes, we did want to ensure that the nodes have to communicate to run the queries, as they would in a real-world scenario; which is why the performance wouldn't just double.
I think you're putting a lot of emphasis on the size of the data. While that is surely important, the size itself isn't the only thing which proves scalability. It's about the concurrency, throughput and latency -- and determining that they do improve when you add more hardware power to the cluster.
We do pretty strict code reviews https://github.com/dgraph-io/dgraph/pulls?utf8=%E2%9C%93&q=i... . Nothing goes into master until it gets LGTMed.
The point was that, if all of your team members are having a conversation, but you're not, you'd feel left out. Of course, you might not care, but a lot of people who feel they're active part of the team do; and discourse allows us to do that very well.
In Show HN: Bot to steer discussions from Slack to DiscourseLots of answers already in this thread. The ones I'd recommend:
https://github.com/dgraph-io/dgraph
http://titan.thinkaurelius.com/
https://www.arangodb.com/
http://orientdb.com/orientdb/
In Cayley – An open-source graph databaseI'm pretty excited about https://github.com/dgraph-io/dgraph
Distributed (yes, really!) graph database, from a guy who was on Google's knowledge graph team.
In Cayley – An open-source graph databasethere is also: https://github.com/dgraph-io/dgraph also a golang project as the title mentions, if this matters to anyone.
In Cayley – An open-source graph databaseDGraph's 0.3 release was a day ago: https://github.com/dgraph-io/dgraph/releases/tag/v0.3
In Ex-Googler forced out of the US due to visa issues, builds startup in AustraliaEx-Googler Startup Dgraph Labs
3 points · Open discussionReleasing Dgraph, distributed graph database: v0.3
6 points · Open discussionDGraph | Remote
What - DGraph(https://github.com/dgraph-io/dgraph) is an open source Scalable, Distributed, Low Latency, High Throughput Graph Database written in Go. We want to build the best Graph database in the world.
Hiring - We are looking for outstanding backend engineers with 3+ years of experience. The process includes 2 technical interviews, followed by 2 months of full time paid Bootcamp program to ensure that you’re a great fit and vice-versa.
Perks
* Our salaries are open and transparent
* Macbook pro
* $2500 towards a workstation and desk of your choice
* Kindle for every team member, read only Fridays and unlimited books.
* Medical coverage for you and your dependents
and many more
For more details see https://dgraph.io/#jobs. If you feel you would be a good match, get in touch with us at https://angel.co/dgraph-labs or joi
Read the rest
n@dgraph.io
We've examples of some pretty deep Graph queries (8 levels), for e.g. the last query here: https://github.com/dgraph-io/dgraph/wiki/Test-Queries
Finding the shortest route between A and B is on the roadmap. This would mean adding a weight to the edge. Navigation adds yet another interesting factor, which means we need to store multiple weights per edge, depending upon time of the day, day of the week, or day of the year etc. This would be an interesting challenge to solve; probably by v1.0.
In DGraph – Scalable, Distributed, Low-Latency, High-Throughput Graph Database1. I wouldn't term anything up until 1.0 as production ready.
2. API doc? Basically, there's only one endpoint, called /query. All the queries just go through that. There's a wiki page with some test queries to get you started.
3a. Yes, with the 2 phase loader. Only RDFs are supported right now, nothing else. https://github.com/dgraph-io/dgraph#distributed-bulk-data-lo...
3b. Yes, with mutations. https://github.com/dgraph-io/dgraph#queries-and-mutations
4. It's truly distributed. The data is actually sharded, with each shard containing part of the data and served by a separate instance. The bulk loader instructions generate 3 instances.
5. To keep the queries, data storage and data transfer efficient, we assign a uint64 ID to all entities. UID assignment is that operation.
In DGraph – Scalable, Distributed, Low-Latency, High-Throughput Graph DatabaseYes, here's the roadmap: https://github.com/dgraph-io/dgraph/issues/1
We do filter by predicates, and have plans to do sort and limit, including count. DGraph is designed to accommodate all these use cases really well.
The idea is that you shouldn't need much on top of DGraph, because the query latency should be low; maybe Memcached. But, in the graph world, a single edge change can affect many queries, and so we've designed DGraph to provide low latency for arbitrarily complex queries.
The schemas would be enforced via GraphQL, i.e. the query language, not via the storage mechanism. This allows you to change the definition of types of entities, without changing the corresponding data. This is incredible for both backwards compatibility, and quick iterations.
In DGraph – Scalable, Distributed, Low-Latency, High-Throughput Graph DatabaseGraph DBs are great for intersection queries (AND queries). In fact, DGraph is designed to do those really fast; and supporting that via GraphQL is in our roadmap.
https://github.com/dgraph-io/dgraph/issues/1
In general Graph DBs are great when you have many "kinds" of things, which would require many many tables in traditional databases, and lots of interlinking. Those scenarios are ideal for Graphs, because many different kinds of things can be interrelated to each other easily, and be queried seamlessly. In other words, the schema for graphs is very fluid.
In DGraph – Scalable, Distributed, Low-Latency, High-Throughput Graph DatabaseShowing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.