Polling vs streaming blockchain data — which should you use?

Updated August 2026

Polling means repeatedly asking a node whether anything new has happened. Streaming means holding an open connection and receiving data as it is produced. Streaming is lower latency, cheaper at scale, and — most importantly — can tell you exactly what you missed when the connection drops.

For anything beyond a script or a prototype, streaming is the better default.

How do they compare?

	Polling	Streaming
Latency	Bounded by poll interval	As data is produced
Request volume	Constant, mostly empty responses	One connection
Cost at scale	Grows with frequency	Roughly flat
Missed data on disconnect	Detect and re-query by block range	Resume from a cursor
Reorg visibility	Must detect yourself	Signalled in the stream
Implementation	Trivial	Requires connection handling

Why is polling expensive?

Because most polls return nothing. Poll every second for a chain producing blocks every twelve, and roughly eleven of every twelve requests are wasted — but you still pay for them, and the node still serves them.

Tightening the interval to reduce latency makes this worse, not better. You end up paying more to wait less, and the ratio never improves.

What actually goes wrong with polling?

Not latency. Gaps.

Your process restarts, or the network drops, or a deploy takes thirty seconds. When polling resumes you need to work out what happened while you were away — which means tracking the last block you processed, querying the range, and handling the possibility that some of it was reorganised while you were disconnected.

Most teams write this logic. Many write it slightly wrong, and the failure is silent: a handful of missing records nobody notices until a total does not reconcile months later.

How does streaming solve that?

With a cursor — a token identifying exactly where in the stream you are, including fork context. Reconnect with your last cursor and the stream resumes precisely there. Nothing is missed, nothing is duplicated, and if the chain reorganised while you were away, the stream tells you what was undone rather than quietly skipping it.

This is how Firehose works, and it is why streaming consumers can make correctness guarantees that polling loops cannot. The reliability difference is larger than the latency difference, and it is the one that matters in production.

When is polling fine?

When you are prototyping, when you genuinely only need a periodic snapshot, or when you are checking a small number of specific values on a slow cadence. If a missed update is recoverable and latency is irrelevant, polling's simplicity is a real advantage.

Frequently asked questions

Are webhooks streaming? Closer to streaming than polling, but delivery is at-most-once unless the provider implements retries and replay. Check what happens when your endpoint is down.

Can I stream historical data too? Yes. Substreams processes history in parallel and continues into live streaming with the same code.

What if my consumer is slower than the chain? A cursor-based stream lets you fall behind and catch up without losing position.

Stream instead of polling — get an API key at thegraph.market, no personal information required.