Yellowstone gRPC on Solana: Geyser Streaming Guide
Learn how Yellowstone gRPC works on Solana, how it relates to Geyser, RPC, and WebSockets, and when production backends should use streaming instead of polling.
A lot of Solana backends start with polling because it is simple. Read accounts every few seconds, retry failed calls, cache the result, move on.
That works until the workload becomes continuous. The loop gets expensive, updates arrive late, WebSocket subscriptions need more recovery logic than expected, and the team starts debugging data gaps instead of building the product.
Yellowstone gRPC exists for that kind of workload: backend systems that need filtered live Solana state instead of scheduled reads. It is useful for indexers, trading infrastructure, alerting, monitoring, and analytics pipelines, but it is not a finished data product. The stream handles ingestion; the application still has to handle ordering, deduplication, replay, storage, and query access.
What Yellowstone gRPC is on Solana
Yellowstone gRPC is a network-accessible streaming interface for Solana validator data — think of it as a pipe that pulls live state directly out of the validator and delivers it to a backend as changes happen, with server-side filters applied before anything reaches the consumer. Instead of asking the chain what changed on a schedule, the system receives pushes.
The open implementation lives in the rpcpool/yellowstone-grpc repository. Several managed infrastructure providers offer Yellowstone-compatible endpoints with different packaging, pricing, regions, stream support, and reliability semantics.
Yellowstone is often described as "faster RPC," but that framing misses the point. The shift is architectural: once a workload moves from request/response to continuous observation, the data path should reflect that. Simulating a stream with a poller is a workaround, not a solution.
From Geyser to Yellowstone gRPC: the data path
Geyser, Yellowstone, and gRPC are often used in the same conversation, but they describe different layers of the streaming path.
Geyser is the validator-side plugin interface. When a Solana validator processes account writes, transactions, or slot transitions, Geyser emits callbacks into a loaded plugin, configured through --geyser-plugin-config. The plugin runs alongside the validator process and decides where that data goes next.
Yellowstone gRPC is the network-facing layer built on top of those Geyser callbacks. It turns validator-side events into subscribable streams that backend systems can consume over the network. Instead of running a validator or integrating directly with a local plugin, a backend connects to a Yellowstone-compatible endpoint and subscribes to the accounts, transactions, slots, or blocks it needs.
gRPC is the transport protocol underneath that connection: HTTP/2, bidirectional streaming, and protobuf serialization. It is well-suited for persistent backend streams with high throughput, but it is not a browser-native replacement for frontend WebSocket subscriptions.
The stream handles ingestion. The application still has to handle ordering, deduplication, storage, backfill, replay, and query access. For most production systems, that downstream layer is where the real engineering work begins.
What data you can stream with Yellowstone gRPC
The Yellowstone repo and Supanode's supported streams reference cover the core streams:
- Accounts — pushed on every write, with
write_versionto order multiple writes within the same slot - Transactions — voted and non-voted, with optional filtering on vote/failed flags and signatures
- Slots — status transitions across
processed,confirmed, andfinalized - Blocks — convenience views synthesized from lower-level messages
- Entries — a lower-level stream of ledger entries as they are processed by the validator, distinct from the transaction stream and useful for advanced pipelines that need finer-grained slot structure
Full block reconstruction is synthetic — assembled from Geyser messages rather than delivered natively — and the Yellowstone repo documents caveats around this. For most production indexers, account and transaction streams are more reliable as primary sources.
Startup notifications are worth understanding before building on account streams. When the plugin initializes from a snapshot, account notifications arrive with is_startup=true. This can break the initial state model during deployment if startup writes are treated as live updates.
The Yellowstone gRPC protocol also exposes unary helper methods — getSlot, getLatestBlockhash, isValidBlockhash, getVersion — alongside streaming, so a gRPC endpoint can handle some on-demand reads without a separate RPC connection.
Yellowstone gRPC vs RPC vs WebSockets
The fastest stream on a clean benchmark is not always the one you want in production. What matters is what happens when the connection drops, replay starts, messages duplicate, or the upstream node fails.
| Option | Best for | Not ideal for |
|---|---|---|
| JSON-RPC | Occasional reads, balances, single transactions, app queries, transaction submission | Continuous high-volume state monitoring, polling-heavy getProgramAccounts loops |
| WebSocket | Basic subscriptions, frontend/browser-adjacent real-time updates, lighter event streams | High-throughput backend pipelines needing replay, richer filtering, or strong recovery semantics |
| Yellowstone gRPC | Filtered backend streams, account writes, transactions, slots, blocks, indexers, bots, analytics | Simple apps that only need occasional reads or lightweight subscriptions |
| Custom indexer | Normalized historical/state data, custom queries, analytics products, durable internal APIs | Teams that only need raw live events without owning ingestion + storage + query maintenance |
RPC starts to break down when the workload becomes continuous. At that point, maintaining a polling scheduler, retry layer, and stale-data cache stops being an implementation detail — it signals the architecture doesn't match the load.
WebSockets become harder to operate when the stream needs stronger recovery semantics. Some providers run WebSocket products on top of stronger backend streaming systems precisely for this reason — not every product should consume gRPC directly; in some cases, the provider abstracts that backend stream behind a WebSocket interface.
Yellowstone gRPC is the wrong layer if the team expects a polished query product. Its value is in high-throughput raw ingestion, and everything built on top of it still needs to be designed.
Occasional reads, app queries, and transaction submission still belong in the Solana API and RPC layer.
When Yellowstone gRPC is the right choice
Yellowstone becomes relevant when the backend needs to observe state continuously rather than query it on a schedule.
Common trigger conditions include:
- needing every account write for a program, with no polling gaps
- building an indexer or fill engine that depends on ordered state
- looping
getProgramAccountsto the point where cost or latency is becoming a real problem - needing sub-second confirmation events
- building toward ordered program history for audit or analytics, where the consumer handles checkpointing, replay, and gap detection on top of the stream
Other common cases: monitoring and alerting systems that need to react to on-chain state changes faster than any polling interval can guarantee, dashboards watching liquidity pools, systems where the difference between processed and confirmed carries real consequences.
For trading infrastructure, stream latency only matters if the execution path can act on it quickly.
When standard RPC or WebSockets are enough
A simpler stack is better until its failure modes become the main bottleneck.
RPC remains the right tool for occasional balance checks, single-transaction lookups, current-slot queries, and transaction submission — and for most frontend app queries. It doesn't need to be replaced because gRPC exists.
WebSockets handle lighter subscription use cases well: price feeds with modest update frequency, simple event listeners, browser-facing real-time data. Not every real-time requirement justifies a backend gRPC deployment.
Cases where staying on RPC or WebSockets is the sensible decision:
- the backend only needs to react to occasional events, not continuous state
- the team doesn't have bandwidth to own recovery logic and consumer design
- the update frequency needed is achievable with a reasonable polling interval
- the workload is frontend-adjacent, where browser-native gRPC isn't viable
Before moving to gRPC, some teams should first tune the standard RPC layer: region, method mix, p95/p99 behavior, and subscription handling.
Hosted Yellowstone gRPC vs self-managed Geyser
The Agave docs include a specific warning: if Geyser plugin callbacks take too long, the validator falls behind. The recommendation is to process callbacks asynchronously and persist to external stores rather than doing heavy work inline.
In production, self-managed Geyser usually implies dedicated validator infrastructure. Full reliability also means running redundancy for outages, upgrades, and failover.
Self-hosting Geyser converts provider spend into:
- Validator node operations and hardware
- Geyser plugin configuration and compatibility maintenance across validator upgrades
- Failover and redundancy design
- Missed-update liability during maintenance windows
- Monitoring the health of the stream itself
Unless direct control over the stream path is a genuine product edge — say, a trading operation where the difference between a hosted hop and a co-located validator has measurable impact — for most application teams, the practical split is to use a managed stream and focus engineering time on the consumer, storage, and recovery layer.
Self-managed Geyser belongs inside the broader Solana RPC infrastructure decision: node operations, failover, endpoint exposure, and staffing.
Reliability questions: replay, reconnects, failover, and missed updates
Raw latency matters less if the consumer can't recover cleanly after a disconnect.
The questions worth nailing down before committing to any provider:
- How much replay is available? Public documentation shows meaningful variation — one provider documents roughly 3,000 replayable slots (~20 minutes), another documents 24-hour historical replay. That gap matters for recovery design.
- How do you detect gaps? Slot continuity should be tracked per commitment level and filter — the Agave docs note that
processedandconfirmedslot status events can arrive out of order relative to each other. A consumer that assumes simple monotonic slot progression across commitment levels can miss gaps silently. - What duplicates appear on reconnect? Reconnecting from a slot boundary can re-deliver already-processed updates. Consumers need idempotency, not an assumption of exactly-once delivery.
- What actually fails over when an upstream node dies? Multi-node failover and single-endpoint failover are different products with different recovery guarantees.
The yellowstone-grpc-client on docs.rs exposes auto-reconnect, configurable backoff, and deduplication state primitives. Having them in the client library is necessary — but recovery strategy still has to be designed explicitly.
Provider documentation describes from_slot replay for short disconnect recovery and a SubscribeReplayInfo.first_available field for discovering the available replay window. Both are worth understanding before committing to a provider. If the provider's replay window is shorter than the team's longest expected maintenance gap, that's a quiet data-quality problem until it isn't.
P95 and P99 stream stability matter more than best-case latency numbers. A stream delivering low median latency with frequent reconnects is worse in production than one delivering higher but stable latency with clean recovery behavior.
Filtering, bandwidth, and cost control
In streaming systems, server-side filtering is the primary cost-control mechanism. The cheapest byte is the one the provider never sends.
Yellowstone's filter vocabulary is substantial:
- Account filters by pubkey, owner,
memcmp, ordataSize account_include/account_exclude/account_requiredfor fine-grained stream compositionaccount_data_slicefor receiving only the bytes needed from each account — the upstream Yellowstone protocol supports slicing account payloads down to the fields a consumer actually uses- Transaction filters on vote/failed flags and signatures
- Slot filters by commitment level
- zstd compression support as an additional transport optimization
Entries and block metadata streams have less fine-grained filtering than account or transaction streams. If a workload depends on those streams, the incoming data volume can be higher than expected.
Provider-side filter caps are product limits, not only technical constraints. How many accounts can be subscribed per stream, how many concurrent streams are available, and whether filters are enforced server-side before transmission — these affect what the infrastructure costs at scale. Supanode's gRPC limits reference covers connection caps, per-stream filter caps, and how they scale by tier. Design server-side selectivity first; compression and connection tuning are secondary.
How to evaluate Solana gRPC providers
Many Solana infrastructure providers now advertise Yellowstone compatibility. The real differentiation is in the reliability semantics — and those are often absent from the product page.
Stream and filter support
- Which streams are available: accounts, transactions, slots, blocks, entries?
- What filter types are supported and what are the per-stream limits?
- Is full block streaming included or an add-on?
Reliability and recovery
- What is the documented replay window, and how is it measured?
- What is the reconnect and gap-recovery model?
- Is failover multi-node or single-node?
- What is p95/p99 delivery stability, not just advertised latency?
Operational fit
- What regions are available, and do they match the consumer geography?
- What are the connection limits per tier?
- How is authentication handled — token, TLS, or both?
Observability and support
- Does the provider surface stream health metrics, lag indicators, or reconnect counts?
- What is the support path during an active production incident?
- Is there a migration path if the team needs to move providers or go self-hosted later?
If a provider's public materials cover plan names and latency claims but not replay depth, gap behavior, or failover scope, there isn't yet enough information to commit production infrastructure. Ask directly before building on it.
Production checklist before switching to Yellowstone gRPC
Production readiness depends on recovery behavior, not only connection setup.
| Checklist item | Why it matters |
|---|---|
| Define workload and commitment target | processed, confirmed, and finalized have different freshness and finality semantics; some systems should resolve commitment client-side rather than relying on stream defaults |
| Choose the minimal necessary streams | Account and transaction streams are usually easier to reason about than full blocks; reconstructed full-block streams carry documented caveats |
| Design server-side filters first | Filter selectivity controls bandwidth and cost more than transport tuning |
| Persist last processed slot | Replay and recovery are slot-based; without a checkpoint, reconnect logic is guesswork |
| Implement dedup and idempotency | Replay from a slot boundary re-delivers already-seen updates; design for at-least-once delivery |
| Keep the stream alive with ping/pong | Idle connections get killed by load balancers and proxies; the Yellowstone protocol includes keepalive fields for this |
| Keep RPC beside gRPC | Streaming doesn't replace on-demand reads or transaction submission; run both |
| Test disconnect, replay, and failover paths | Recovery behavior is the decisive quality metric; happy-path latency is secondary |
| Verify region fit | Streaming quality is sensitive to physical distance; confirm provider regions match consumer geography |
| Plan observability | Visibility into lag, reconnect count, duplicate rate, consumer backlog, and slot continuity needs to be in place before something breaks |
Observability is easy to underbuild: teams often instrument the consumer but forget to instrument the stream itself. If the provider's replay window is shorter than the team's longest expected maintenance gap, recovery will require a separate backfill path.
Need real-time Solana data streaming for production?
If your backend depends on filtered Solana account, transaction, or block streams, start with the workload: region, filter width, expected throughput, replay needs, and recovery requirements.
Supanode supports Yellowstone gRPC, RPC, WebSockets, and dedicated indexer setups for production Solana teams. Start with the gRPC docs or get in touch to work through the right setup for your workload.
