Graph Node: Indexing Blockchain Data Into GraphQL Without Building Your Own Pipeline
Graph Node indexes data from blockchains such as Ethereum and serves it over GraphQL.
At a glance
- What is it?
- Graph Node is a Rust service that turns Ethereum and other chain data into queryable GraphQL endpoints. It is meant for subgraph developers who want to test locally and for contributors who want to modify the indexer itself.
- Who is it for?
- Adopt Graph Node if you are a subgraph developer who wants a local test environment or a contributor who plans to modify the indexer. Do not adopt it if you only need a hosted subgraph service or if you are not willing to manage PostgreSQL, IPFS, and an Ethereum RPC endpoint.
- 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 21 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Graph Node Solves and Who It Is For
Blockchain nodes give you raw blocks and transactions, not answers to questions like 'what is the total value locked in this contract?' Graph Node solves that by indexing blockchain data according to a subgraph definition and exposing the result over GraphQL. The README is explicit about the audience: subgraph developers who want to run graph-node locally to test their subgraphs, and contributors who want to add features or fix bugs in graph-node itself. If you are neither, this project is not aimed at you. The Graph protocol is the decentralized network around it, but this repository is the indexing engine, not the hosted service.
The Mechanism: Subgraphs, PostgreSQL, and IPFS
A subgraph is the central mechanism for extracting and organizing blockchain data. You define what to index, likely in a manifest that specifies data sources and mappings. Graph Node reads that definition, connects to an Ethereum node through the --ethereum-rpc argument, and writes the indexed data into a PostgreSQL database. The README instructs you to create three extensions in that database: pg_trgm, btree_gist, and postgres_fdw. The postgres_fdw extension is notable because it enables foreign data wrappers, which the configuration docs use to split indexing and querying across multiple databases. IPFS is another prerequisite, used to store and retrieve subgraph definitions by hash. The GraphQL server then reads from PostgreSQL and serves queries at routes like /subgraphs/name/<subgraph-name> and /subgraphs/id/<IPFS hash>.
Getting It Running: From Docker or From Source
For subgraph developers, the README strongly recommends prebuilt Docker images, pointing to docker/README.md. For contributors, building from source requires Rust stable, PostgreSQL, IPFS, and the Protobuf compiler. The database setup involves a psql script that creates a user, a database, and three extensions. Then you set an environment variable: export POSTGRES_URL=postgresql://graph:<password>@localhost:5432/graph-node. The build command is cargo run -p graph-node --release -- --postgres-url $POSTGRES_URL --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL --ipfs 127.0.0.1:5001. The capabilities list matters: you declare whether the provider supports archive and traces. If you declare capabilities your provider does not have, indexing will fail or behave incorrectly. The README also shows a file-based log store example with --log-store-backend file and --log-store-file-dir ./graph-logs.
Log Storage: A Feature That Adds Real Complexity
Graph Node can store subgraph logs in four backends: file, Elasticsearch, Loki, or disabled. The default is disabled. The file backend writes JSON Lines files and is recommended for local development. Elasticsearch and Loki are marked as production-grade. You query these logs through a GraphQL endpoint at http://localhost:8000/graphql, using a query like { _logs(subgraphId: "QmYourSubgraphHash", level: ERROR, first: 10) { timestamp level text } }. This is a meaningful feature because it lets you debug subgraph failures without digging through the node's own stdout. But it adds operational weight: running Elasticsearch or Loki is a significant infrastructure decision. The README points to a dedicated log-store guide for performance considerations, which suggests the trade-offs are not trivial.
A Genuine Limitation: It Is Not a Hosted Service
Graph Node is a piece of software you run yourself. That means you must operate PostgreSQL, IPFS, and an Ethereum RPC endpoint. The README says you can use a provider of your choice, but the provider must support the capabilities you pass in the --ethereum-rpc argument. If you only have a light client or a provider without archive data, you cannot index historical state. The configuration file and environment variables exist for large instances, but the README says those are usually only necessary when connecting to multiple chains or splitting work across multiple databases. For a single-chain local test, the command line arguments are enough. The wrong tool would be a team that wants a managed subgraph service and does not want to maintain infrastructure; for them, the hosted Graph Explorer is the obvious alternative.
The Alternative: Hosted Services and Other Indexers
The direct alternative is the hosted service provided by The Graph itself, which runs Graph Node on your behalf. You deploy a subgraph and query it without installing anything. The difference in approach is operational: you trade control over the indexing environment for convenience. You cannot tweak the configuration file or add custom environment variables on the hosted service. Another alternative is building your own indexer with a custom Rust or Go service that reads Ethereum logs directly, but that means reimplementing the mapping and storage logic that Graph Node already provides. The Graph protocol's hosted service is the closest comparison, and the README implicitly points to it by recommending the official quick-start guide for subgraph developers.
Maintenance, Upgrades, and License
The repository is active, with releases v0.43.0, v0.44.0, and v0.45.0 appearing roughly every two months. That cadence means you will need to track updates if you run your own node. The README says the code assumes the latest stable Rust compiler, so building from source requires keeping your toolchain current. The license is dual: MIT and Apache-2.0, with a copyright notice for Graph Protocol, Inc. and contributors. That dual licensing is common in open source and gives you flexibility, but you should check which license applies to any code you copy or modify. The README does not mention a migration path between versions, so upgrading may involve database schema changes that are not documented in the README. You will have to consult the release notes or the docs directory for that.
Editorial conclusion
Adopt Graph Node if you are a subgraph developer who wants a local test environment or a contributor who plans to modify the indexer. Do not adopt it if you only need a hosted subgraph service or if you are not willing to manage PostgreSQL, IPFS, and an Ethereum RPC endpoint. Before you start, verify that your Ethereum provider supports the capabilities you declare (archive and traces) and that your PostgreSQL installation has the three required extensions. The project is dual-licensed under MIT and Apache-2.0, so check which license terms fit your distribution plans. Graph Node is the reference implementation for The Graph protocol, and its release cadence of roughly two months means you should expect regular updates.
Community notes