Which Solana Data Path Does Your App Need?
Solana applications do not all need the same view of the chain.
Some need a confirmed balance. Some need to know when an account changes. Some need to process every transaction as it arrives. Some need to see data before the block is confirmed.
The right choice is not the fastest feed by default. It is the feed that gives your application the information it needs, at the moment it needs it.
Start with confirmed state
Solana RPC is the default for reads and transaction submission.
Use it to fetch balances, account data, transactions, blocks, and other confirmed state. It is the right layer for wallets, dashboards, application backends, and any workflow where correctness matters more than seeing an event first.
RPC answers a question your application asks. It is simple, reliable, and enough for most interactions with the chain.
Use WebSockets when polling becomes the problem
WebSockets turn a repeated question into a subscription.
Instead of asking whether an account, program, or slot has changed, the application keeps a connection open and receives the update when it happens. This is a good fit for account watchers, program logs, live dashboards, and straightforward real-time features.
Use WebSockets when the application needs updates as they happen, but does not need to process a high-volume stream.
Use Yellowstone gRPC for sustained real-time data
Yellowstone gRPC is built for applications that need to consume accounts, transactions, and blocks continuously.
It is the right layer for indexers, market-data systems, trading infrastructure, analytics pipelines, and other workloads where WebSocket messages become too limited or too expensive to process at scale.
The difference is not only speed. gRPC is a binary streaming protocol with server-side filtering, so the application can subscribe to the data it actually needs and keep processing it efficiently.
Use ShredStream for signal, not truth
ShredStream delivers data before a block is confirmed.
That makes it useful for first-mover systems: arbitrage, liquidations, MEV, and other workloads where seeing a transaction early changes the outcome. It is not the right source for balances, settlement, or final state. A transaction seen in the stream may not land, or may land differently.
Use ShredStream for the earliest possible signal. Use RPC to confirm what became true.
The simple rule
Use RPC for confirmed reads and writes. Use WebSockets for simple real-time subscriptions. Use gRPC for sustained high-throughput streams. Use ShredStream when pre-confirmation visibility is the requirement.
All four services are available alongside compute, so the application can use the right path without changing where it runs.