// the find
graphprotocol/graph-node
Graph Node indexes data from blockchains such as Ethereum and serves it over GraphQL
Graph Node is the indexing and query engine behind The Graph protocol — it watches blockchain data (primarily Ethereum, plus NEAR and others via Firehose), runs user-defined subgraph mappings written in AssemblyScript, stores results in PostgreSQL, and exposes them via GraphQL. It's production infrastructure used by a significant chunk of DeFi/Web3, not a toy project. Primarily relevant to Web3 developers who need structured, queryable access to on-chain data without rolling their own ETL.
- The architecture is well-thought-out for the problem: chain-agnostic adapter layer (Firehose/RPC), WASM sandbox for user mappings, sharded PostgreSQL for horizontal scaling — it handles reorgs, pruning, and time-travel queries, which are genuinely hard problems.
- Docs are unusually good for a Rust infrastructure project: environment-variables.md covers hundreds of tuning knobs, config.md explains multi-database sharding, and there are implementation notes explaining SQL query generation and schema design decisions.
- The new `gnd` CLI (replacing graph-cli) is a meaningful addition — it includes a built-in test runner with mock chain/IPFS/Arweave, which closes a real pain point for subgraph developers who previously had to deploy to test anything.
- CI is solid: separate audit workflow, nextest configuration, devcontainer setup, and dependabot — the project has the operational hygiene you'd want before depending on it.
- Build time from source is painful — it's a large Rust workspace with many heavy dependencies (ethers, diesel, tokio, prost). Even with released builds, you still need to manage PostgreSQL extensions (pg_trgm, btree_gist, postgres_fdw) and IPFS yourself, which is more yak-shaving than most developers expect.
- PostgreSQL is the only supported store, and the schema it generates is deeply intertwined with its own query generation logic. If you hit a performance cliff on a complex subgraph query, you're debugging generated SQL against an internal schema with limited visibility.
- The subgraph mapping sandbox still runs AssemblyScript (a TypeScript-like language that compiles to WASM), which is a niche toolchain with its own type gotchas and a smaller ecosystem than plain TypeScript or Rust. Errors in mappings can be cryptic, and the debugging story is weak.
- Multi-chain support beyond Ethereum is uneven — NEAR has decent coverage but other chains are largely dependent on Firehose stream availability from third-party providers (Streamingfast/Pinax), so self-hosting a full stack for non-Ethereum chains is not straightforward.