Summary
A Solana indexer ingests blockchain data—slots, blocks, transactions, and account state—and transforms it into a queryable format for applications. The core decision is ingestion: RPC polling with methods like getBlock and getSignaturesForAddress is simpler but can be rate-limited and slow for high-volume programs; Geyser plugins streaming via gRPC provide real-time, efficient access but require validator infrastructure or a managed stream service. Historical data requires a backfill strategy because streams and RPC calls can miss events during outages or reorgs. Design for checkpointing and idempotent writes so data can be replayed safely. Storage should match query patterns: relational databases for transactional queries, columnar engines for analytics. Managed indexing services such as SubQuery abstract much of this pipeline, offering GraphQL APIs and hosted storage. For production workloads, use a dedicated RPC provider or managed streams instead of public endpoints like https://api.mainnet-beta.solana.com, which are rate-limited and designed for development. OnFinality provides Solana RPC endpoints with HTTP/WebSocket and archive support—verify current options on the network page.
Key Takeaways
- Choose ingestion based on data freshness and throughput: RPC polling for simple tasks, Geyser/gRPC streams for real-time indexing.
- Always design for backfill and checkpointing: even stream-based pipelines can miss events during failures or reorgs.
- Solana’s account model requires careful normalization of account state and program-derived addresses.
- Managed indexing services like SubQuery reduce operational overhead but may limit query flexibility and control.
What a Solana indexer does
A Solana indexer connects to the blockchain, extracts data from slots, blocks, transactions, and account updates, and stores that data in a database or warehouse so applications can query it efficiently. Typical use cases include transaction explorers, portfolio trackers, analytics dashboards, and program-specific APIs.
Unlike EVM chains where event logs provide a convenient abstraction, Solana’s account model and high throughput mean indexers often need to process account state changes directly. The indexer must decide which data to capture, how often to capture it, and how to handle historical backfills.
For foundational RPC concepts and method coverage, see the Solana API guide.
- Parse transactions and instructions for relevant programs.
- Track account balances, token holdings, and program-derived addresses.
- Maintain slot and block metadata for ordering and reorg detection.
- Expose query APIs (SQL, GraphQL, or REST) to downstream applications.
RPC ingestion and historical data choices
Indexing typically starts with one of three ingestion approaches: RPC polling, Geyser plugin streams over gRPC, or managed webhook/stream services. Polling calls JSON-RPC methods like getSignaturesForAddress, getTransaction, and getBlock at intervals. It works for low-volume or batch workloads but can hit rate limits on public endpoints like https://api.mainnet-beta.solana.com or https://api.devnet.solana.com.
Geyser plugins (e.g., Yellowstone gRPC) attach to a validator and push account updates, transactions, and logs in real time. This is the most efficient for high-throughput indexing but requires running or renting a validator with plugin support.
Managed webhooks and stream services abstract the validator complexity, delivering data via HTTPS callbacks or gRPC streams. They are convenient but may limit control over filtering and storage.
OnFinality provides Solana RPC endpoints with HTTP and WebSocket access, archive support for mainnet, and regions in N. Virginia and Hong Kong. Verify current plan details and rate limits on the Solana network page. For evaluating endpoint speed factors, see Fastest Solana RPC.
| Criterion | What to check | Why it matters |
|---|---|---|
| Data freshness | Sub-second real-time vs. seconds-to-minutes batch | Live dashboards and trading tools need low latency; daily analytics can accept delays. |
| Throughput capacity | Max events per second and burst handling | Solana can produce thousands of transactions per second; the pipeline must keep up. |
| Operational overhead | Validator management, queue setup, database operations | Self-managed Geyser pipelines require significant DevOps effort. |
| Backfill support | Built-in replay or easy access to historical RPC data | Missed events during outages must be recoverable without rebuilding from genesis. |
Slots, blocks, transactions, and account state
Solana organizes data in slots (leader schedules), blocks (collections of transactions at a slot), and individual transactions (containing instructions and signatures). Account state is persistent data stored under public keys, modified by program execution.
A complete indexer must decide which parts to store. For most applications, transaction data is primary, but account state is critical for tracking balances, token ownership, and program state. Account updates can be obtained from Geyser account notifications or by polling getAccountInfo at intervals.
Normalization should map Solana’s binary formats (base58, base64) into developer-friendly types, preserve program IDs and instruction discriminators, and handle compressed NFTs or newer extensions if relevant.
- Slot/block metadata: slot number, blockhash, timestamp, leader, and parent slot.
- Transaction details: signatures, fee payer, recent blockhash, instructions, logs, and status.
- Account state: lamports, owner, executable flag, data, rent epoch, and token balances.
- Program-specific decoding: anchor events, SPL token transfers, and custom instruction layouts.
Backfills, checkpoints, and replay safety
No ingestion method is perfect: RPC calls can timeout, gRPC streams can drop connections, and nodes can fall behind. A robust indexer must support backfilling missed data. Checkpointing the last processed slot or signature enables the pipeline to resume without duplicates.
Reorg safety requires handling Solana’s commitment levels. Processed and confirmed transactions can be rolled back; only finalized is final. Indexers should store commitment status and re-ingest conflicting blocks if the chain reorgs deeper than the checkpoint.
Use idempotent writes (upserts keyed by slot or signature) and maintain a watermark table to avoid replaying already-processed data. For historical backfills, batch-fetch from archive RPC endpoints or use managed replay services.
- Persist checkpoints after each batch or stream message.
- Handle duplicate events gracefully with unique keys on slot/signature.
- Track max confirmed slot and reorg depth from the node.
- Provide a manual backfill command for gap-filling historical ranges.
Storage and query architecture
Choose storage based on query patterns. PostgreSQL is a good default for transactional queries with indexed columns; ClickHouse excels at high-volume analytical scans; object storage (e.g., S3) can hold raw transaction data for archival.
Many indexers use a hybrid approach: a relational database for current state and recent transactions, a data warehouse for historical analytics, and a GraphQL layer for flexible client access. Pre-aggregations (e.g., daily volume, active users) reduce dashboard load.
Retention policies matter: Solana generates substantial data, so plan for pruning or cold storage. Compress old transactions or move them to cheaper storage after a threshold.
| Criterion | What to check | Why it matters |
|---|---|---|
| Query flexibility | Support for ad-hoc SQL, GraphQL, or REST endpoints | Different clients need different access patterns. |
| Scalability | Horizontal scaling, partitioning, and replication | Data volume grows over time; the database must handle it. |
| Cost | Storage type, retention, and compute for queries | High-performance storage can become expensive at scale. |
| Operational complexity | Backup, failover, and schema migrations | More moving parts increase maintenance burden. |
Managed indexing and SubQuery options
Managed indexing platforms abstract the entire pipeline: they run nodes, collect data, normalize it, and expose query APIs. SubQuery is a popular open-source indexing framework with hosted options for Solana. It lets you define a mapping schema and query the data via GraphQL.
OnFinality provides infrastructure that can power a custom indexer: use its Solana RPC endpoints for polling or its dedicated node infrastructure for Geyser plugin setups. See the blog post Deploy a Solana indexer with OnFinality for a walkthrough.
When evaluating managed services, consider data source control (do they use Geyser or polling?), query flexibility (GraphQL, SQL), cost model (per event, per compute), and vendor lock-in. Managed options reduce ops but may not fit every custom requirement.
- SubQuery: open-source, GraphQL-based, supports Solana.
- Other managed stream services: offer webhook or gRPC delivery with varying filtering.
- OnFinality: provides endpoint and node infrastructure as building blocks.
- Always verify current capabilities and pricing on provider pages.
Solana indexer implementation checklist
Use this checklist when planning or auditing a Solana indexer. It covers architecture decisions, operational safety, and testing.
| Criterion | What to check | Why it matters |
|---|---|---|
| Data requirements | Which programs, accounts, and transaction types are needed | Determines filtering and ingestion strategy. |
| Ingestion method | RPC polling, Geyser/gRPC, or managed streams | Balances real-time needs against operational cost. |
| Historical backfill | Availability of archive data and replay tools | Required for missing data and initial load. |
| Checkpointing | Watermark table and idempotent write logic | Prevents data loss and duplicates during restarts. |
| Reorg handling | Commitment tracking and rewind strategy | Maintains consistency during chain rollbacks. |
| Storage design | Database type, indexing, and retention policy | Affects query performance and cost. |
| Testing | Run against Devnet with test SOL from https://faucet.solana.com | Validate pipeline before mainnet deployment. |
| Monitoring | Lag from chain head, error rates, storage growth | Detects issues before users notice. |
Frequently Asked Questions
What is a Solana indexer?
A Solana indexer is a service that ingests data from the Solana blockchain—transactions, account updates, and block metadata—and stores it in a queryable database for applications like explorers, dashboards, and analytics tools.
Can I use public RPC endpoints for indexing?
Public endpoints such as https://api.mainnet-beta.solana.com are rate-limited and intended for development and testing. For production indexing, use a dedicated RPC provider or managed stream service that offers higher throughput and reliability.
What is the difference between RPC polling and Geyser/gRPC?
RPC polling repeatedly calls JSON-RPC methods to fetch data on an interval; it is simple but can be slow and rate-limited. Geyser plugins (including Yellowstone gRPC) push data in real time from a validator, offering low latency and high efficiency but requiring validator infrastructure.
How do I handle reorgs and missed data in a Solana indexer?
Implement checkpointing to track the last processed slot or signature, use idempotent writes keyed by unique identifiers, and design a backfill mechanism to re-ingest data from archive RPC endpoints when gaps occur. Track commitment levels to respond to chain rollbacks.
Does OnFinality support Solana indexing infrastructure?
OnFinality provides Solana RPC endpoints with HTTP and WebSocket access, archive support, and regions in N. Virginia and Hong Kong. These can be used as the data source for a custom indexer. For a managed approach, see the blog post Deploy a Solana indexer with OnFinality. Verify current capabilities on the Solana network page.
Should I build my own indexer or use a managed service like SubQuery?
Build your own if you need deep customization, own the data completely, and have DevOps capacity. Use a managed service like SubQuery to reduce operational overhead and get a GraphQL API quickly, accepting some limitations in control and query flexibility.