Solana RPC vs gRPC vs shred streams

RPC: ask for a specific result

HTTP JSON-RPC fits actions such as loading an account, fetching a blockhash, or checking a signature. A request maps naturally to a user interaction or scheduled reconciliation job. WebSocket RPC subscriptions add ongoing notifications without repeated polling.

For a wallet interface, start with a request budget per screen. Cache stable data where appropriate, combine overlapping lookups, and make errors recoverable without forcing the user to reload everything.

gRPC: maintain a filtered consumer

Yellowstone gRPC is a useful fit for a backend that continuously consumes selected Solana updates. Filters help focus the stream, while protobuf messages give the consumer a defined data structure.

For an indexer, think beyond opening the stream: store checkpoints, manage queue growth, and test recovery. Keep a query path for filling gaps or answering requests outside the feed’s coverage.

Shreds: own more of the pipeline

Raw shreds put decoding and packet handling in your infrastructure. That gives your team control over the consumer, and it also gives your team responsibility for incomplete data and network behavior.

For a research or event-detection pipeline, prototype the raw and decoded paths against the same output requirement. Compare engineering effort, failure recovery, and event coverage alongside timing.

Compare the whole workflow

Use the same network, application region, observation window, and target events when evaluating interfaces. Avoid comparing a raw observation from one feed with a finalized result from another and calling the difference a transport benchmark.

• Payload: does the response include the fields your application needs?
• Semantics: what does the event prove about execution and confirmation?
• Recovery: how will you repair data after a disconnect or gap?
• Operations: can your team observe and run the consumer reliably?
• Access: do the enabled products, quotas, and locations match your workload?

Common questions