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_atcolumn for the dataset you query. - For API pagination, you can also monitor the response
cursorprogression and returnedcountover 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.