Triton One Open-Sources SuperBank, a 38x Faster Historical Ledger Layer for Solana Built on ClickHouse

Triton One has open-sourced SuperBank, a ground-up rebuild of Solana's historical data layer that replaces the industry's standard Google Cloud BigTable key-value store with ClickHouse, a columnar analytics database. The release, announced June 17, brings P50 latency improvements of 38x for getSignatureStatuses (from 1,885ms down to 49ms) and 5x for getSignaturesForAddress (from 245ms down to 50ms), and ships under the AGPL-3.0 license at github.com/solana-rpc/superbank.

Why BigTable's Key-Value Schema Breaks at 400TB

Solana's ledger has accumulated more than 400TB of block and transaction data since 2020, growing at roughly 1,000 transactions per second against 400-millisecond slot times, per Triton One's engineering team. The ecosystem's conventional approach (Google Cloud BigTable with a fixed key-value schema) routes each query to a separate lookup table. Fetching wallet history requires decompressing entire blocks regardless of how much of the block is actually relevant to the query. Checking whether a list of signatures has been finalized requires one round-trip per signature. The result, according to Triton One, is "constant time-outs, high egress costs, and extremely limited access patterns."

The problem is structural. Key-value stores are optimized for point lookups by a single key. Solana's most common historical queries (retrieving all transactions for an address, checking whether a set of signatures confirmed, showing token activity for a given owner) are inherently multi-dimensional. No amount of caching or horizontal scaling fixes a schema that was never designed for columnar access patterns.

How SuperBank's Three-Layer Architecture Works

SuperBank is built around three independent components that together replace the BigTable pipeline end-to-end.

Hydrant is the ingestor. It accepts data from multiple upstream sources simultaneously: Yellowstone Fumarole, Yellowstone gRPC, standard Solana JSON-RPC, and BigTable itself. This source diversity means SuperBank can be deployed incrementally without a hard cutover from existing infrastructure.

ClickHouse is the storage layer. The key design choice is a set of materialized views sorted by different dimensions. The base tables (blocks_metadata and transactions) are keyed by slot. From those, SuperBank maintains three materialized views: signatures (sorted by signature for fast existence checks), gsfa (sorted by account address and slot for getSignaturesForAddress), and token_owner_activity (sorted by token owner for SPL token history). Each column is compressed independently using Delta+ZSTD encoding rather than compressing whole rows. ClickHouse's bloom filters on signature columns eliminate block-scan overhead for point lookups.

For high-traffic addresses (exchanges, program accounts, aggregators) a gsfa_hot re-partitioning ensures that accounts with millions of transactions do not degrade other queries. Tiered storage moves cold data from NVMe to HDD to S3 automatically, controlling costs as the dataset grows past 400TB.

The JSON-RPC API layer is stateless and sits in front of ClickHouse. It includes a head cache (an in-memory store of recent slots that serves sub-millisecond reads when callers pass a slot hint) and a 300-second result cache for finalized transactions. A slot synchronizer refreshes every 200 milliseconds, keeping the hot cache current without hammering ClickHouse. The layer supports both single-node ClickHouse and distributed shard deployments, so teams can scale horizontally as query volume grows.

SuperBank vs BigTable: P50 Latency Benchmarks

The Triton One team measured P50 latency across methods, comparing the existing BigTable pipeline against SuperBank:

The gains on getSignatureStatuses are the largest because BigTable's fixed schema required sequential per-signature lookups. ClickHouse's bloom filters and signature-sorted materialized views collapse this to a single columnar scan regardless of how many signatures are in the request.

A New Method: getTransactionsForAddress

SuperBank also ships a new RPC method, getTransactionsForAddress, that consolidates what previously required multiple round-trips into a single call returning two times the throughput of the prior approach. The method enables complete wallet history in one request, which matters for explorers, portfolio trackers, and any application that currently stitches together signature lists and individual transaction fetches client-side.

What SuperBank Unlocks for Solana Infrastructure Teams and App Builders

The operational implications split across two groups. Teams running their own RPC infrastructure can deploy SuperBank against their existing ClickHouse clusters using the DDL schemas in the repository's ddl/ directory. The Nix flake development environment and included k6 load testing scenarios reduce integration friction. Triton One also provides a managed hosted version with geo-distribution and redundancy for teams that do not want to run their own ClickHouse deployment.

For application developers, the change is largely transparent. SuperBank exposes the same standard Solana JSON-RPC interface, so existing SDK integrations work without modification. The benefit shows up as reliability (fewer timeouts on deep history queries) and as new capability in the form of getTransactionsForAddress.

The open-source release under AGPL-3.0 also makes the architectural pattern itself available to the ecosystem. Any node operator or infrastructure provider can adapt the ClickHouse schema, the materialized view design, and the tiered storage approach for their own deployment.

SuperBank builds on Triton One's earlier work on Old Faithful, the open-data Solana ledger archive that surfaces the complete historical ledger for downstream consumers. Where Old Faithful solved the data availability problem (making the full 400TB accessible), SuperBank solves the query performance problem on top of that data.

The repository is live at github.com/solana-rpc/superbank. The full architecture breakdown, including schema definitions and benchmark methodology, is published on the Triton One blog.