Solana data infrastructure is not one market. It is a stack of adjacent problems that often get bundled together under the word "indexing."
The useful split is:
| Layer | Core question | Typical systems |
|---|---|---|
| Source acquisition | How does raw chain data enter the system? | RPC, Geyser, Yellowstone, snapshots, Bigtable, block crawlers |
| Decode and parse | How does raw data become typed events or records? | IDL decoders, account parsers, instruction parsers, custom program decoders |
| Pipeline runtime | How are updates filtered, ordered, retried, and delivered? | Stream processors, parser runtimes, job queues, backfill workers |
| Storage model | What read shape is optimized? | Postgres, ClickHouse, Kafka, object storage, custom indexes |
| Serving layer | How do applications query the data? | JSON-RPC, GraphQL, REST, SQL, streams, webhooks |
Practical Categories
Protocol Indexers
Protocol indexers transform Solana program data into application-specific tables, events, and APIs. Their core advantage is semantic precision: they know the target program, its accounts, instructions, and event structure.
This category favors:
- typed decoders
- backfill plus live indexing
- custom processors
- application-specific schema design
Stream Infrastructure
Stream infrastructure focuses on low-latency movement from validators or data vendors to consumers. The design center is not only decoding, but also filtering, fanout, coordination, and delivery under real-time load.
This category favors:
- Yellowstone and Geyser-native ingestion
- parser prefilters
- Kafka or stream outputs
- durable event routing
Ledger History Stores
Ledger history systems optimize for transaction, block, signature, and address-history queries. The storage engine matters because the data volume is large and the read shape is repetitive.
This category favors:
- columnar storage
- materialized views
- RPC-compatible serving
- historical backfill and compaction
Account-State RPC
Account-state systems optimize for current and recent account queries, especially
getProgramAccounts-style workloads. They are closer to state indexes than transaction
warehouses.
This category favors:
- account versions
- owner and filter indexes
- snapshot loading
- query tracking and hot-path optimization
Current Open-Source Reference Points
| Project | Primary fit | Notes |
|---|---|---|
| Carbon | General Solana indexing framework | Broad decoder and datasource posture; strong for application-specific pipelines |
| Yellowstone Vixen | Stream parser/runtime framework | Yellowstone-oriented parser and handler model for real-time pipelines |
| Superbank | ClickHouse-backed ledger RPC | Opinionated historical transaction and block serving layer |
| Cloudbreak | Postgres-backed account-state RPC | Account state, snapshot/live ingestion, and account query serving |
The open-source stack is strongest when these projects are seen as layers, not direct replacements. A serious data product may use more than one category: for example, Yellowstone ingestion, typed protocol decoders, ClickHouse for ledger history, and Postgres for account-state indexes.
Working Thesis
The winning systems will make tradeoffs explicit:
- latency versus completeness
- semantic decoding versus raw replay
- current account state versus historical transaction history
- general framework flexibility versus operationally opinionated appliances
- open-source composability versus managed-provider convenience
The category is still early enough that a clear map of roles is more useful than a single ranked list.