Solana moves fast. Slots close roughly every 400 milliseconds, and a busy program can touch thousands of accounts per second. If your backend polls JSON-RPC on a timer, you are always reading slightly stale state and paying for requests that return nothing new. gRPC streaming flips that model: the node pushes updates to you the moment they land. For enterprise workloads — indexers, trading systems, wallets, analytics pipelines — that shift is usually the difference between keeping up and falling behind.
The catch is that "gRPC endpoint" means different things to different teams, and not every provider exposes the same streaming surface. This article walks through what to evaluate, how to test it, and when shared capacity stops being enough.
When a gRPC stream is the right fit (and when it is not)
Before you shop for endpoints, decide whether streaming actually matches your workload. gRPC is not a universal upgrade over JSON-RPC.
Choose gRPC streaming when you need:
- Real-time account or program state (DeFi positions, order books, liquidation monitors).
- Full block and transaction ingestion for an indexer or data warehouse.
- Slot-level notifications to trigger downstream jobs without polling.
- High fan-out: many internal consumers reading from one upstream stream.
Stay on JSON-RPC (with WebSocket where useful) when you need:
- Occasional reads, wallet balance checks, or transaction submission.
- Simple request/response calls where you control the timing.
- Historical queries that a stream cannot answer retroactively.
Most production Solana stacks end up using both. A common pattern is a gRPC stream feeding a queue, plus a standard RPC endpoint for on-demand reads and writes. OnFinality provides Solana RPC API access over HTTP and WebSocket, which pairs naturally with a streaming layer for the parts of your system that need push updates.
What "scalable" actually means for Solana gRPC
Scalability in streaming is not one number. It is a set of properties that show up under load. Ask a provider how they handle each of these.
| Property | What to ask | Why it breaks at scale |
|---|---|---|
| Subscriber fan-out | How many concurrent streams per endpoint or account? | A single stream shared by 50 services can bottleneck or drop |
| Filter flexibility | Can you subscribe by account, program, or owner? | Broad subscriptions flood your client with irrelevant data |
| Backpressure handling | What happens when your consumer is slower than the chain? | Buffers grow, memory spikes, and the stream lags |
| Reconnect behavior | Do you get a resume point or a fresh snapshot? | Silent gaps in data corrupt downstream state |
| Congestion resilience | How are streams prioritized during network spikes? | Shared endpoints can degrade exactly when you need them most |
| Isolation | Is your stream on shared or dedicated infrastructure? | Noisy neighbors affect your latency and throughput |
If a provider cannot answer these clearly, treat the endpoint as best-effort rather than production infrastructure.
Provider evaluation matrix for Solana streaming
Use this as a checklist when comparing options. OnFinality is listed first because it is the reference point for this article, but the columns apply to any provider you evaluate.
| Provider / option | Streaming model | Isolation path | RPC + WS alongside | Best for |
|---|---|---|---|---|
| OnFinality | Solana RPC API (HTTP/WS) with dedicated node options for isolated capacity | Shared to dedicated nodes | Yes, same provider | Teams that want RPC and dedicated infrastructure from one place |
| Shared public endpoints | Varies; often rate-limited | None | Sometimes | Prototypes and low-volume testing |
| Specialized streaming vendors | gRPC-first, Geyser-style | Usually dedicated tiers | Often RPC-only or separate | Pure streaming use cases |
| Self-hosted Geyser node | Full control | Fully isolated | You run it | Teams with deep Solana ops experience |
A self-hosted Geyser node gives maximum control but requires you to run, monitor, and upgrade validator-adjacent infrastructure. That is a real operational cost. A managed provider trades some control for someone else handling the node lifecycle.
Connecting and testing a Solana endpoint
Start with the public endpoint to confirm your client works, then move to a private or dedicated endpoint for production traffic. OnFinality's Solana mainnet public endpoint is:
# JSON-RPC over HTTPS
https://solana.api.onfinality.io/public
# WebSocket subscription endpoint
wss://solana.api.onfinality.io/public-ws
A quick health check before you wire up streaming:
curl https://solana.api.onfinality.io/public \
-X POST -H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"getHealth"}'
For WebSocket subscriptions (useful for slot and account notifications when you do not need full gRPC), a minimal client looks like this:
import WebSocket from "ws";
const ws = new WebSocket("wss://solana.api.onfinality.io/public-ws");
ws.on("open", () => {
ws.send(JSON.stringify({
jsonrpc: "2.0",
id: 1,
method: "slotSubscribe"
}));
});
ws.on("message", (data) => {
const msg = JSON.parse(data.toString());
if (msg.method === "slotNotification") {
console.log("slot", msg.params.result.slot);
}
});
For a true gRPC stream, your client connects to the provider's gRPC address and subscribes to account, slot, or transaction filters. The exact proto and endpoint come from the provider — confirm them before you build, and test reconnection behavior deliberately by killing the connection mid-stream.
Production readiness checklist
Before you route real traffic, verify these items. They catch most of the failures that only appear under load.
- Reconnect and resume. Simulate a dropped connection. Does your client resume from the last processed slot, or silently skip data?
- Idempotent processing. Streams can deliver duplicates. Your downstream writes should tolerate replays.
- Backpressure plan. Decide what happens when your consumer lags: drop, buffer, or shed load. Do not let an unbounded buffer grow.
- Failover endpoint. Keep a second endpoint configured. If your primary degrades, you want a fast switch, not a scramble.
- Monitoring. Track stream lag (current slot minus last processed slot), reconnect count, and consumer queue depth. Alert on lag growth, not just on disconnects.
- Rate and quota awareness. Understand the request and connection limits of your tier so a traffic spike does not silently throttle you.
- Isolation decision. If shared capacity shows variable latency during congestion, plan the move to dedicated nodes before it becomes an incident.
Shared versus dedicated capacity: the tradeoff
Shared endpoints are the right starting point. They are cheap, fast to set up, and fine for development, staging, and moderate production traffic. The problem is variance: during network congestion or when a neighbor runs a heavy workload, your stream can slow down through no fault of your own.
Dedicated nodes remove that variance by giving your workload isolated resources. You get predictable throughput, your own connection limits, and a clearer capacity ceiling. The tradeoff is cost and setup time — dedicated infrastructure is a commitment, not a free tier.
A practical path:
- Prototype on a public or shared endpoint. Validate your client and filters.
- Launch on a shared private endpoint with monitoring in place.
- Scale to dedicated nodes when lag, throttling, or isolation needs justify it.
OnFinality's dedicated node option is designed for this progression, so you do not have to migrate providers when shared capacity stops being enough. You can review RPC pricing to model the step up, and browse supported RPC networks if Solana is one of several chains you operate.
Common failure modes and how to diagnose them
| Symptom | Likely cause | First check |
|---|---|---|
| Stream lags behind current slot | Consumer too slow or backpressure ignored | Queue depth and processing time per message |
| Frequent reconnects | Endpoint instability or idle timeout | Reconnect logs and provider status |
| Missing accounts or transactions | Filter too narrow or resume logic broken | Compare stream output against a known block |
| Sudden throughput drop | Shared capacity contention | Whether the drop correlates with network congestion |
| Duplicate processing | No idempotency key | Downstream write logic |
When something breaks, isolate whether the problem is your client, the filter, or the endpoint. A quick way to separate client issues from endpoint issues is to run the same subscription from a second, minimal client. If the minimal client is healthy, the bug is in your consumer.
Key Takeaways
- Solana gRPC streaming pushes updates to your backend and is the right model for indexers, trading systems, and real-time monitors — not for occasional reads.
- "Scalable" means fan-out, filter flexibility, backpressure handling, reconnect behavior, and isolation, not just a single throughput number.
- Start on shared or public endpoints, monitor stream lag, and move to dedicated nodes when variance or throttling appears.
- Always pair streaming with a reliable JSON-RPC and WebSocket endpoint for reads, writes, and subscriptions.
- Test reconnection and duplicate handling before production; these are the failures that surface under load.
Frequently Asked Questions
Is gRPC the same as Solana's WebSocket subscriptions?
No. WebSocket subscriptions cover a subset of notifications (slots, accounts, logs, signatures). gRPC streaming, typically via a Geyser-style plugin, exposes a broader and often lower-overhead stream of account, block, and transaction data. Many teams use both.
Can I use a public Solana endpoint for gRPC streaming?
Public endpoints are best for testing and light use. For sustained streaming, use a private or dedicated endpoint so your throughput is not shared with unrelated traffic.
How do I know when to move to a dedicated node?
Watch for growing stream lag, throttling during congestion, or a need for guaranteed isolation. If shared capacity shows variable latency that affects your application, that is the signal to step up.
Does OnFinality offer Solana gRPC streaming?
OnFinality provides Solana RPC API access over HTTP and WebSocket, plus dedicated node infrastructure for isolated capacity. Check the Solana network page for current transport details and reach out about streaming requirements for your workload.
What should I monitor first?
Stream lag — the gap between the current slot and the last slot your system processed. It is the earliest signal that something is falling behind.
Next steps
If you are evaluating Solana streaming for an enterprise workload, start by confirming your client works against a public endpoint, then define your monitoring and failover plan. From there, decide whether shared capacity meets your needs or whether dedicated nodes are the better fit. You can compare options in our RPC provider selection guide, review RPC pricing, and explore supported RPC networks to plan across chains.
Related resources
Originally published at OnFinality.
Top comments (0)