Repository navigation
SQLite indexer #7017
Description
Summary
This feature is needed to get acceptable performance out of several eth_* methods. There's a draft #6720 but some additional considerations might be needed.
Completion Criteria
- [ ]
Additional Links & Resources
Metadata
Metadata
Assignees
Type
Fields
Priority
None yet
Projects
- Status
Activity
eth_*methods performance #7008LesnyRumcajs commentedon Jun 18, 2026
@hanabi1224 please write down your findings here.
hanabi1224 commentedon Jun 24, 2026
(co-authored by Claude Code)
Benchmark Results: SQL vs. In-Memory Implementation for
eth_getLogsI ran load tests using
oha(1000 sequential requests, 500-epoch range) against three configurations. Here's a summary of the key metrics:main(with cache)main(no cache)sqlFindings
The SQL implementation performs on par with
mainwhen the in-memory cache is disabled — both averaging ~61 ms with throughput around 16.3 req/sec. This confirms that the SQL approach does not offer a performance improvement over the existing implementation.The
mainbranch with cache enabled significantly outperforms SQL across most percentiles, particularly at the median (p50: 37 ms vs. 58 ms) and throughput (20.9 vs. 16.3 req/sec). It is worth noting that SQL wins slightly at p99 (92 ms vs. 123 ms), suggesting more consistent tail behaviour, but this comes at the cost of a considerably worse median. The cache accelerates repeated data loading for the same tipset and has a modest memory footprint (~100 MiB), so it is doing real work at low cost.Conclusion
Since the SQL implementation merely matches the no-cache baseline without providing any measurable gain, and the existing in-memory cache already delivers substantially better median latency and throughput at negligible memory overhead, I don't think the current approach — a direct translation from Lotus — justifies proceeding further.
I'd suggest we close this out unless there is a compelling reason to prefer SQL beyond what is already covered by the current implementation.
Raw
ohabenchmark result：{
"method": "eth_getLogs",
"params": [
{
"fromBlock": "0x39e6a8",
"toBlock": "0x39e6da"
}
],
"id": 328,
"jsonrpc": "2.0"
}
hanabi1224 commentedon Jun 24, 2026
As discussed, the SQL is intended to be used for a larger range (like 2-month-worth epochs) with a strict filter. Will benchmark that scenario again.
LesnyRumcajs commentedon Jun 24, 2026
Yeah, and the methods affected are not only
eth_getLogsbut others ~eth.*filter.*LesnyRumcajs commentedon Jun 24, 2026
All in all, an SQL (or not, it's not set in stone) might have to be used to address expensive calls, for smaller ones we're probably good right now.
Kind of like
std::sort- use different algorithms for different collection sizes :)