Freshness - BlockDB Docs

Freshness by channel

BlockDB processes datasets in a coordinated pipeline, so most tables advance together. The main differences you observe in freshness come from delivery channel and chain-specific reorg/finality buffers.

Delivery Channel	Typical Freshness	Notes
Real-time (WSS)	Lowest latency	Reorg-aware: you may see updates for recent blocks within the real-time buffer window.
API (REST)	Near-real-time	Stability guaranteed via chain-specific backoff beyond max reorg; queries are reproducible.
Warehouse shares	Hourly	Freshness depends on provider and replication cadence.
Bulk exports (SFTP/S3/Blob)	Nightly snapshots	Nightly by default; hotfix replays are run ad-hoc if needed.

Chain buffers (blocks)

Chain ID	Chain	API & Archive buffer (blocks)	WSS buffer (blocks)	Rationale	Source
`1`	Ethereum Mainnet	`3`	`0`	Etherscan forked-block data shows observed reorgs are almost always one block, we set the buffer above that.	https://etherscan.io/blocks_forked

These values are operational defaults and may change over time as chains evolve. If you need stricter guarantees for a specific chain, contact support.

How do I monitor data freshness?

Use the _updated_at column for the dataset you query.
For API pagination, you can also monitor the response cursor progression and returned count over time.

Need tighter guarantees? Mirror the dataset via the API and compare _tracing_id values. Differences indicate your mirror is stale or queried inside the reorg buffer.

Last modified on June 10, 2026