Streaming Blocks on Solana: Data Volume, Latency, and Unavoidable Trade-offs

Source: Dev.to

Overview

Solana is known for high throughput and low latency.
But if you are building:

• a block indexer
• a transaction decoder
• real‑time analytics
• monitoring or alerting systems

you will quickly realize that streaming blocks on Solana is not just about speed — it’s about managing uncertainty, data volume, and trade‑offs.

This post walks through:

1. How block streaming actually works on Solana
2. The main streaming approaches
3. Why RPC latency becomes a bottleneck
4. Why commitment‑level choices matter more than you think

1️⃣ Solana is Slot‑Based, Not Block‑Based

Important consequences

• A slot occurs roughly every ~400 ms.
• Not every slot produces a block.
• Blocks may arrive late.
• Confirmation levels change what data you receive.

So when people talk about block streaming on Solana, they are really talking about streaming execution results derived from slots, under different guarantees. Every streaming approach is just a different way to deal with this reality.

2️⃣ The Most Basic Approach – Polling

# Pseudo‑code
slot = getSlot()
block = getBlock(slot)          # or getParsedBlock(slot)
decodeTransactions(block)

Why it looks appealing

• Simple to reason about
• No persistent connections
• Easy to prototype

Why it breaks at scale

• Slots can be skipped
• Blocks may not exist yet
• Retries are frequent
• RPC rate limits are hit quickly
• Large transactions / instruction data cause high latency

Result: you end up building:

• retry loops
• back‑fill logic
• slot‑to‑block reconciliation

At low volume it works; at scale it becomes fragile and expensive.

3️⃣ blockSubscribe – An Event‑Driven Approach

WebSocket → subscribe (blockSubscribe) → receive blocks pushed from RPC node

Pros

• Fewer RPC round‑trips
• Lower latency than polling
• Simpler flow control

Cons

• Typically limited to confirmed and finalized commitment levels
• processed is usually unavailable or unreliable
• Blocks may still be partial (missing some instructions / inner instructions)
• Provider behavior varies

You gain safety and simplicity, but sacrifice ultra‑low latency.

4️⃣ Geyser Plugin – The Most Powerful (and Complex) Option

Data is streamed directly from validators, bypassing RPC bottlenecks.

Pros

• Highest completeness (full instruction visibility)
• Predictable performance, minimal retries
• Very low latency (near‑zero)

Cons

• Requires validator access or partnerships
• More complex infrastructure
• Higher operational cost

Geyser does not remove complexity — it moves it into the infrastructure layer where it belongs.

5️⃣ Data Volume – The Often‑Underestimated Bottleneck

A single Solana block can contain:

• Hundreds or thousands of transactions
• Deeply nested instructions
• Large inner‑instruction trees
• Verbose account metadata

Impact on RPC‑based fetching

• Response payloads are large → serialization / deserialization expensive
• Network transfer dominates end‑to‑end latency

In practice:

• getBlock often takes hundreds of ms; under load it can reach seconds.
• Retries amplify the cost.
• Even with a fast decoder, you’re often waiting on the wire.

Typical polling loop (simplified)

getSlot()
getBlock()
if missing → retry
if commitment changes → refetch

Combine that with:

• Skipped slots
• Partial blocks
• Confirmation re‑checks

Result: high tail latency, uneven block arrival, back‑pressure in your pipeline, and escalating RPC costs.
That’s why many Solana indexers feel fast in tests but unstable in production.

6️⃣ The Core Question for Every Streaming Setup

How wrong am I willing to be, and for how long?

Processed Commitment (with Geyser)

• Data comes directly from the validator execution path.
• processed commitment is commonly used in practice.
• Latency is extremely low; stream stability is high.

Because execution data is emitted immediately:

• Blocks arrive consistently.
• Instruction data is complete.
• Re‑processing logic is predictable.

Result: Geyser + processed is often the fastest and most operationally stable streaming setup on Solana. Ideal for:

• Real‑time decoding
• Monitoring systems
• Low‑latency analytics
• Applications that tolerate short‑lived re‑orgs

blockSubscribe – Safer, but Slower

• Supports only confirmed and finalized.
• Does not reliably expose processed.
• Varies across RPC providers.

Consequences:

• Higher end‑to‑end latency
• Fewer re‑orgs → simpler correction logic
• Safer, but fundamentally different from validator‑level streaming

7️⃣ Reducing Redundant RPC Calls

Both WebSocket and Geyser reduce:

• Redundant RPC calls
• Polling overhead

But they do not change the core reality:

• Transaction + instruction data is large.
• Decoding cost is unavoidable.
• Memory pressure is real.

On Solana, data size is part of the protocol design, not an implementation detail.

8️⃣ Real‑World Implementation – txdecoder.xyz

At txdecoder.xyz we treat Solana block streaming as an infrastructure problem, not just an API choice.

Hybrid Streaming Architecture

1. Multiple Geyser gRPC block‑streaming workers – primary data source
2. Additional WebSocket blockSubscribe worker – fallback path

Geyser gRPC

• Fastest option
• Most complete instruction data
• Stable enough to run at processed commitment

Challenges: long‑lived streams can drop; validators can restart; transient network issues happen.

Mitigations:

• Run multiple independent Geyser workers
• De‑duplicate blocks downstream
• Treat each worker as a non‑authoritative source

Benefits:

• Higher availability
• Predictable latency
• Graceful degradation instead of hard failure

WebSocket blockSubscribe

• Backup when gRPC streams disconnect
• Typically runs at confirmed or finalized (slower, but more resilient across providers)

Purpose:

• Ensure no long blind spots
• Provide smoother recovery

9️⃣ Takeaways

Final Thought

No matter which method you choose, understanding the trade‑offs between latency, completeness, and operational overhead is essential. By treating block streaming as an infrastructure concern and leveraging a hybrid approach, you can achieve both high availability and low latency while keeping costs under control.

Prepared by the team at txdecoder.xyz.

Continuity During Validator‑Level Disruptions

On Solana, no single streaming method is perfect.
Instead of chasing one “ideal” solution, we:

• Combine multiple imperfect streams
• Accept short‑lived inconsistencies
• Resolve them deterministically downstream

This approach allows txdecoder.xyz to:

• Stay low‑latency under normal conditions
• Remain correct under failure
• Avoid catastrophic data gaps

Resilience on Solana is a feature you have to build yourself.

Solana block streaming isn’t hard because Solana is “bad”.
It’s hard because Solana optimizes for:

• Throughput
• Parallel execution
• Low confirmation latency

Those choices push complexity downstream.

If you are building Solana data infrastructure, you are not just streaming blocks — you are managing uncertainty, volume, and trade‑offs. There is no perfect approach, only conscious ones.

txdecoder.xyz

Transaction decoding API – standardizing blockchain data into one unified, readable schema on Ethereum, Base, BSC, and Solana.

Website:

Social & Community:

• X (Twitter):
• Telegram:
• Announcements:
• Medium: