Superbank

GitHub ↗

Architecture explorer

Superbank architecture

How Solana blocks flow from a source into ClickHouse, out through JSON-RPC, and into Parquet archives. Toggle components to see the topology change.

Configure

Loading 3D view…

  • Block
  • Rows
  • Index / MV
  • Parquet
  • Query
  • Bundle metadata
  • Request
  • Head cache
  • Disk cache
  • ClickHouse

Click any component for details Tap a component · two fingers to pan and zoom

Data path for this configuration

How it fits together

Write path

Blocks enter from a live stream (Yellowstone gRPC or Fumarole), a bounded backfill (Solana JSON-RPC or Bigtable), a Parquet restore, or the separate Jetstreamer plugin that replays Old Faithful. superbank buffers rows and flushes each batch in a fixed order: transactions, then blocks_metadata, then entries.

So a slot in blocks_metadata implies its transactions are stored. Materialized views on transactions then build the gsfa and signatures indexes that the RPC relies on.

Read path

superbank-rpc answers JSON-RPC from ClickHouse. You can put two optional tiers in front: an in-memory head cache of the newest slots and a disk cache of recent finalized slots. A request tries each enabled tier in order and falls through on a miss.

ClickHouse is always the last tier. There is no fallback to an upstream Solana RPC and no Parquet read path. gRPC streaming is a separate, optional listener for bounded historical slot ranges.

Archive & restore

superbank-solparq exports ClickHouse tables into Parquet bundles named {kind}_{epoch}_{start}-{end}, either through local disk or straight to S3, where ClickHouse writes the files itself. Each range is checked against Solana getBlocks and the transaction counts in blocks_metadata first.

To restore, superbank --source solparq tells ClickHouse to load the bundles back. Parquet is an archive and restore format only.