Query Latency
DeepBlock is built for real-time intelligence. There are two aspects to consider: data freshness and query response time.
Data Freshness
Our ingestion pipeline ensures that new block data is incorporated quickly. On chains with fast finality or frequent blocks (like Polygon or an L2), data is often available within a few seconds of on-chain confirmation.
On Ethereum mainnet, we typically see new transactions indexed within ~15 seconds of block production (usually effectively real-time for most use cases, given a block time of ~12s). For critical use cases, you can assume sub-minute latency from an on-chain event to it being queryable in DeepBlock.
We also monitor network finality. For instance, on Ethereum, we might choose to wait 1 block confirmation before reporting data, to avoid brief reorg issues, unless you opt for an unsafe mode.
Query Response Time
The GraphQL query engine is optimized to return results quickly. Simple queries (e.g., fetch one address’s latest transactions or a token’s current price) will return in hundreds of milliseconds.
More complex analytical queries (e.g., join across many entities, multi-hop traversals with filters) might take a few seconds, especially on large datasets. We use caching for repeated queries, so dashboards or periodic reports can get sub-second responses after the first run.
In internal tests, even heavy aggregate queries (like scanning all transactions for a pattern) usually complete within a single-digit number of seconds, thanks to our performance layer.
We continuously fine-tune this, aiming to bring most queries into the sub-second range by pre-indexing popular dimensions.
To summarize, DeepBlock provides near-real-time data across multiple chains, and the architecture is tuned to answer queries as fast as possible.
Whether you’re triggering an automated alert on a fresh transaction or running an end-of-day analysis across chains, the system is built to minimize wait times.
Last updated