ClickHouse on Solana: why analytics stacks keep landing here
How ClickHouse fits Solana data workloads: high insert rates, compression, analytical SQL over history. CryptoHouse, Triton Superbank, indexers via Geyser/Yellowstone/Goldsky, and what it is (and is not) good for.
devrels.xyz/a/208short linkClickHouse shows up a lot in Solana data stacks. That is not because it replaces the ledger or the validator’s local RocksDB. It is because Solana produces a continuous stream of blocks and transactions, and many products need analytical access to that history: filters, aggregations, time ranges, dashboards — workloads where key-value history stores (classic BigTable-style layouts) get expensive and awkward.
This note is for builders choosing where to put Solana event data after it leaves the node: when ClickHouse is a good fit, who already runs it, and how it sits next to RPC and streaming.
Why the pairing shows up
Solana’s head is optimized for consensus and recent state. Long-term history is pruned off local disk into separate storage. Triton estimates hundreds of terabytes of historical block/tx data at ecosystem scale. Product questions then look like:
- All swaps for a mint over 30 days, grouped by hour
- Wallet activity and PnL-style joins across many programs
- Leaderboards, volume, fee stats with low latency
- Historical JSON-RPC that is not “fetch whole compressed block, parse client-side”
ClickHouse is an open-source columnar OLAP database built for high insert throughput, heavy compression, and fast scans/aggregations over large tables. That matches “append Solana events forever, query them like a warehouse” better than a primary key-value archive designed for point lookups of full blocks.
| Need | Typical store |
|---|---|
| Live account state, recent slots on a node | Validator / RPC local RocksDB (and friends) |
| Point getTransaction by signature (legacy path) | History KV (e.g. BigTable-shaped) or Superbank-style layer |
| Aggregations, multi-filter history, product analytics | ClickHouse (or similar OLAP) |
| Realtime fan-out of slots/accounts | Yellowstone gRPC / Geyser |
Who uses it in the Solana ecosystem
| Project | Role of ClickHouse |
|---|---|
| CryptoHouse (ClickHouse; data often via partners such as Goldsky) | Free public SQL over crypto datasets; UI includes a solana schema among others |
| Triton Superbank | Full historical ledger rebuild on ClickHouse + Solana-compatible history RPC. Triton publishes large speedups vs public BigTable paths (e.g. getSignatureStatuses ~38×, getSignaturesForAddress ~5×, getTransaction ~3× at P50 in their architecture write-up) |
| Helius (historical) | Large-scale archival analytics on ClickHouse has been part of ecosystem lore; Helius has also moved some storage choices toward specialized paths (e.g. RocksDB for certain roles). Treat “Helius + ClickHouse” as prior/partial, not a permanent architecture claim |
| Bullet and other DeFi apps | Product analytics: trades, volume, leaderboards — often ClickHouse Cloud or self-hosted |
| Indexers / internal data teams | DEX fills, token transfers, holder graphs streamed in via Geyser plugins, Yellowstone, or hosted pipelines (Goldsky, etc.) |
Superbank is open source under the Solana RPC org: github.com/solana-rpc/superbank. CryptoHouse artifacts: github.com/ClickHouse/CryptoHouse.
How data usually gets in
Validator / RPC node
│
├─ Geyser plugin ──────────────┐
├─ Yellowstone gRPC stream ────┼──► transform / batch ──► ClickHouse
└─ Hosted indexer (e.g. Goldsky)┘
ClickHouse serves:
• SQL dashboards / notebooks
• App backends (aggregates, search)
• Optional history RPC façade (Superbank pattern)You keep a real RPC (or Light/DAS stack) for current accounts and submission. ClickHouse sits beside that for history and analytics. Superbank’s pitch is specifically: keep JSON-RPC shapes builders already use, but back history with columnar tables sorted for those query patterns.
Common Solana use cases
- DEX and launchpad analytics (volume, unique traders, fee totals)
- Token transfer and holder distributions over time
- Wallet timelines, cohort, and “smart money” style scans
- Internal monitoring and anomaly queries over program logs
- Historical methods that are painful when every hit inflates a full block blob
What ClickHouse is not
| Not a replacement for… | Why |
|---|---|
| Consensus / validator store | Wrong consistency and write model for fork choice |
| Primary OLTP app DB for user profiles | Different sweet spot; use Postgres/etc. for that |
| “Free infinite history without ops” | You still design schema, retention, ingest lag, and cost |
| Decoded program semantics out of the box | You (or an indexer) must decode instructions/logs into tables |
Practical starting points
| Goal | Start here |
|---|---|
| Explore public Solana tables in SQL | crypto.clickhouse.com |
| History RPC without building ingest yourself | Triton ledger queries / Superbank docs and self-host guide |
| Own pipeline | Yellowstone or Geyser → queue → ClickHouse MergeTree tables partitioned by day/slot |
| Schema ideas | CryptoHouse GitHub queries and Superbank DDL in their repos |
Resources
- ClickHouse docs
- CryptoHouse · CryptoHouse GitHub
- Triton: Inside Superbank · Superbank repo
- Related DevRels: Yellowstone gRPC · Blockworks / Messari data stack
- ClickHouse organisation
Summary
ClickHouse is a strong default for Solana analytics and historical query layers: high ingest, compression, and SQL over large event tables. CryptoHouse makes public exploration easy; Superbank shows the same engine under production history RPC. Keep a normal RPC path for live state and tx send; put ClickHouse next to it for the questions that scan billions of rows.
Keep reading
One vendor stack from warehouse SQL to 3–5s REST and agent MCP — Solana included. Here is how the products split and how builders start.
Blockworks is no longer just research podcasts. After the Messari acquisition, the product surface for builders is a dual API stack, deep Solana analytics (REV, DEX, DATs), and institutional Lightspeed IR. Here is the map: what to call, when not to use it, and a research clip on Jupiter distribution.
Top Ledger is the data layer behind a lot of Solana analytics. Its API serves decoded protocol data across DEX, lending, perps, LP, staking, and yield — and it ships two ways to call it: an API-key MCP/REST tier, and a keyless x402 endpoint that any agent can pay per call. A look at the surface and the two access models.
Get new articles in your inbox
Technical deep-dives on Solana tooling, infrastructure, and ecosystem. No noise.
