Why is my subgraph syncing so slow?

Updated August 2026

Most likely because subgraphs process history sequentially — one block after another — so sync time scales with how much chain history you are covering. Contract calls inside your handlers and heavy entity writes then multiply that baseline.

The structural cause is the processing model, not your configuration. Tuning helps at the margin; changing how history is processed is what actually fixes it.

What are the actual causes?

Sequential processing. The subgraph walks history block by block. There is no way to tune your way past this — it is how the model works.

Contract calls inside handlers. An eth_call in a handler means a network round trip per event. This is the most common self-inflicted cause, and it can dominate everything else. If you are calling symbol() or decimals() on every transfer, that is your problem.

Heavy entity writes. Every save() is a database write. Loading, modifying, and saving several entities per event adds up quickly across millions of events.

Large block ranges. A start block earlier than you actually need means processing history you will never query.

RPC latency. The underlying data source matters. A slow or rate-limited endpoint throttles everything downstream.

What can I fix myself?

Worth doing before anything structural:

Problem	Fix
`eth_call` in handlers	Cache immutable values; store them once rather than fetching per event
Start block too early	Set it to contract deployment, or the earliest block you actually need
Excessive entity writes	Batch updates; avoid load-modify-save loops where you can compute directly
Indexing unused events	Handle only the events your schema needs

These help — sometimes substantially, particularly the first. But they are optimisations within a sequential model. If you need to cover years of a busy contract, you are still walking every block.

How do I fix the structural cause?

You move the extraction and transformation off the sequential subgraph model entirely, onto Substreams, which processes historical segments in parallel and then continues into live streaming.

This also changes what a schema change costs. Under sequential processing, re-syncing is a project you avoid. Under parallel processing it is an operation you can repeat, which in practice means people actually fix their data models instead of working around them.

How do I tell which problem I have?

Watch the sync rate. If it is roughly constant and low, the bottleneck is structural — sequential processing over a large range. If it is erratic or drops sharply at particular blocks, you likely have contract calls or heavy writes triggered by specific activity.

Constant and low means change the model. Spiky means fix the handler first.

Frequently asked questions

Will a faster RPC endpoint fix it? It helps if RPC is your bottleneck, but it does not change sequential processing.

Do I have to rewrite my subgraph? You keep your schema and query interface; it's the extraction layer underneath that changes.

Does this affect live indexing too? Live indexing is bounded by block time, so the pain is almost always in historical sync.

Get an API key at thegraph.market — no personal information required.