// Guide
Solana gRPC vs RPC: The Complete Comparison
If you're building a trading bot, sniper, copy trader, or analytics pipeline on Solana, the way you receive blockchain data determines whether you're fast or you're late. This guide breaks down every data delivery method available — JSON-RPC polling, WebSocket subscriptions, raw Yellowstone gRPC, and filtered gRPC — so you can choose the right stack for your use case.
What is Solana RPC?
Solana's JSON-RPC interface is the most common way developers interact with the blockchain. It works like any standard HTTP API: your client sends a request, the server sends back a response. Methods like getTransaction, getSignaturesForAddress, and getAccountInfo let you query transaction data, account state, and signature history. It is the default protocol that wallets, explorers, and most applications use to read from the chain.
The fundamental limitation of JSON-RPC is that it requires polling. If you want to know when a new Pump.fun token launches or a Raydium pool is created, you have to repeatedly call the API in a loop — typically every 200–500ms — and check whether anything new has appeared. Each request is a full HTTP round trip: DNS resolution, TCP handshake, TLS negotiation (on first call), request serialization, server-side processing, and response deserialization. Even with persistent connections, this adds 50–150ms of overhead per call.
For trading bots, this polling model creates a compounding latency problem. A bot polling every 200ms has an average detection latency of 100ms (half the polling interval) before it even starts the HTTP round trip. Factor in network latency, server processing time, and response parsing, and you're looking at 250–600ms from slot confirmation to your bot's awareness. In a market where Pump.fun tokens can spike 10x within seconds of launch, 500ms is an eternity.
RPC endpoints also enforce rate limits — typically 10–100 requests per second for free tiers, and 300–1,000 for paid plans. Aggressive polling to reduce detection latency quickly bumps against these limits, returning 429 errors and creating gaps in your data. Rate limiting is particularly punishing during high-activity periods, exactly when fast data matters most.
That said, JSON-RPC is perfectly appropriate for use cases that don't require real-time data: checking wallet balances, fetching historical transaction details, resolving account state for display in a UI, or running infrequent analytics queries. It's stable, well-documented, and supported by every Solana client library.
What is Solana gRPC (Yellowstone / Geyser)?
Solana's Geyser plugin system is a validator-level interface that allows external programs to receive a real-time stream of all blockchain events as they happen. Think of it as tapping directly into the validator's internal data pipeline. Yellowstone, developed by Triton, is the most widely used Geyser plugin. It exposes this data stream over gRPC — Google's high-performance remote procedure call framework — giving clients a persistent, bidirectional streaming connection to the validator.
The architecture is fundamentally different from RPC. Instead of your client asking "has anything new happened?" in a loop, the validator pushes data to your client the instant it becomes available. When a new transaction confirms, the Geyser plugin captures it, serializes it into a Protocol Buffer message, and streams it over the gRPC connection. There is no polling interval, no HTTP overhead, and no request-response cycle. Data flows in one direction: from validator to client, continuously.
Yellowstone gRPC can stream four categories of data: transactions (with full instruction data, logs, and account keys), account updates (any change to account state), slot notifications (when slots are processed, confirmed, or finalized), and block metadata. You can subscribe to specific combinations and apply basic filters — by program ID, account address, or transaction characteristics — to narrow the stream.
The challenge with raw Yellowstone gRPC is volume. Solana processes 3,000–5,000 transactions per second under normal load, and 15,000+ during peak activity. If you subscribe to the full transaction stream, your client receives all of them as Protobuf-encoded binary messages. Each message must be deserialized from Protobuf, and then the inner instruction data must be decoded from Borsh (Solana's binary serialization format) using program-specific IDLs. This deserialization step is CPU-intensive and error-prone — a single IDL update from Pump.fun or Raydium can break your parser overnight.
Even with Yellowstone's basic program-level filters, the data volume remains high. Filtering by the Pump.fun program ID still delivers every transaction that touches that program — including failed transactions, irrelevant administrative calls, and spam. Your bot still needs to deserialize every message and apply its own application-level filtering to find the events it actually cares about (new token creates, buys above a certain SOL threshold, migration events, etc.).
Running your own Geyser node is expensive. You need a bare-metal server capable of running a full Solana validator or RPC node (typically 256GB+ RAM, high-core-count CPU, NVMe storage), plus the operational overhead of keeping it synced, updated, and monitored. Budget $2,000–$5,000 per month minimum for hardware alone, plus engineering time for maintenance.
What is Solana WebSocket?
Solana RPC nodes also expose a WebSocket interface that allows push-based subscriptions. Using methods like accountSubscribe, programSubscribe, and logsSubscribe, your client can receive notifications when specific accounts change, when programs execute transactions, or when log messages match a pattern. This eliminates the polling problem — data is pushed to your client instead of pulled.
In practice, however, Solana WebSocket subscriptions have significant reliability issues that make them unsuitable for latency-critical applications. Connections drop frequently, especially during network congestion — exactly when you most need reliable data. When a WebSocket connection drops, there is no built-in mechanism to replay missed events. Your client must detect the disconnection, reconnect, and potentially backfill gaps using RPC calls, creating windows of 1–10 seconds where data is completely lost.
WebSocket subscriptions also lack meaningful server-side filtering. A programSubscribe call sends you every transaction touching that program, with no way to narrow by instruction type, account involvement, or transaction outcome. The data arrives as JSON, which is more readable than Protobuf but significantly less efficient for high-throughput streams. There is no backpressure mechanism — if your client can't keep up with the event rate, the server simply drops messages silently.
Event delivery latency through WebSocket typically falls in the 200–500ms range from slot confirmation, significantly slower than raw gRPC. This latency comes from the RPC node's internal event queue, JSON serialization overhead, and the fact that WebSocket notifications are generated from the node's own RPC layer rather than directly from the validator's Geyser pipeline. For UI dashboards and moderate-frequency monitoring, WebSocket is a reasonable middle ground between polling and gRPC. For competitive trading, it's not fast enough.
Head-to-head comparison
The following table compares all four data delivery methods across the dimensions that matter most for Solana trading infrastructure. Pay particular attention to the latency, filtering, and CPU overhead rows — these are the metrics that directly translate to trading performance.
| RPC Polling | WebSocket | Raw gRPC (Yellowstone) | Filtered gRPC (Subglow) | |
|---|---|---|---|---|
| Delivery model | Client polls | Server push | Server push (stream) | Server push (stream) |
| Latency | 250–600ms | 200–500ms | 10–50ms | < 5ms |
| Data completeness | Gaps during rate limits | Gaps on disconnect | Full stream | Full stream (filtered) |
| Server-side filtering | None | Program-level only | Program + basic filters | Program + instruction + parsed |
| Output format | JSON | JSON | Protobuf + Borsh | Clean JSON |
| Reconnection | N/A (stateless) | Manual, data gaps | Manual, can resume | Auto-reconnect, no gaps |
| Backpressure | None | None (drops msgs) | Built-in (gRPC flow control) | Built-in |
| Rate limits | 10–1,000 req/s | Varies by provider | Provider-dependent | Zero on Pro tier |
| CPU overhead | Low per request, high at scale | Moderate | Very high (Borsh decode) | Minimal (pre-parsed) |
| Best for | Balance checks, simple reads | UI dashboards, monitoring | Full-chain indexing | Trading bots, MEV, analytics |
When to use each approach
There is no single best method for every situation. The right choice depends on your latency requirements, data volume tolerance, engineering resources, and budget. Here is a practical breakdown for common Solana development scenarios.
JSON-RPC Polling
Use RPC for balance lookups, historical transaction queries, account state reads, and any low-frequency operation where 200–600ms latency is acceptable. It's the simplest integration path and works with every Solana client library out of the box. If you're building a wallet UI, a portfolio tracker, or an explorer-style application, RPC is the right tool.
WebSocket Subscriptions
Use WebSocket when you need push-based updates without the complexity of gRPC. It's a solid choice for UI dashboards that display account changes in near-real-time, moderate-frequency monitoring systems, and notification services where occasional missed events are tolerable. Avoid it for anything latency-critical or mission-critical where data gaps cost money.
Raw gRPC (Yellowstone)
Use raw Yellowstone gRPC when you need the full firehose — chain indexing, custom program analysis across every transaction, building your own analytics database, or running archive-node-style infrastructure. Be prepared for the engineering investment: you'll need robust Protobuf and Borsh deserialization, CPU-heavy processing infrastructure, and ongoing maintenance as program IDLs change.
Filtered gRPC (Subglow)
Use filtered gRPC when speed and simplicity are both non-negotiable. This is the right choice for sniper bots targeting Pump.fun launches, copy trading systems that need to mirror whale transactions within the same slot, MEV strategies that depend on sub-10ms awareness, and analytics dashboards that want structured event streams without the parsing overhead. You get the latency of raw gRPC with the convenience of pre-parsed JSON.
Why filtered gRPC changes the game
The core insight behind filtered gRPC is simple: move the filtering and parsing work from the client to the server. With raw Yellowstone gRPC, every subscriber receives the same firehose. If you only care about Pump.fun token launches, you still receive — and must process — thousands of irrelevant transactions per second from every other program on the network. Your bot's CPU spends the majority of its cycles on deserialization and discard logic rather than on trading decisions.
Borsh deserialization is particularly expensive. Each Solana program defines its own instruction layout, and decoding a single transaction requires loading the correct IDL, parsing binary instruction data, resolving account keys, and extracting typed fields. A bot processing the raw firehose might deserialize 15,000 transactions per second only to discard 14,900 of them. That's wasted compute that directly increases your latency and hardware costs.
Subglow solves this by running the filtering and parsing pipeline on our infrastructure, directly connected to Geyser nodes in the same datacenter. When a transaction confirms, our system receives it via the raw Geyser stream, applies your filters (program ID, instruction type, account involvement), deserializes the matching transactions from Borsh into structured JSON, and streams only the parsed result to your client. The entire pipeline — from validator to your bot's callback — completes in under 5ms.
The numbers tell the story. A typical raw gRPC subscriber processing the full Solana stream needs 4–8 CPU cores dedicated to deserialization and filtering. With Subglow, the same workload runs on a single core with headroom to spare, because your client receives pre-parsed JSON at a fraction of the volume. On a busy day, Subglow filters 80M+ transactions and delivers only the matching fraction — typically 0.5–2% of total network volume — as clean, structured data.
This architecture also eliminates the IDL maintenance burden. When Pump.fun updates their program or Raydium deploys a new AMM version, Subglow's parsing layer is updated centrally. Your bot doesn't need a code change, a redeployment, or a new Borsh schema. The JSON output format remains stable while the underlying binary encoding evolves.
Real-world latency breakdown
Latency is not a single number — it's a pipeline. Each stage between slot confirmation and your bot's decision point adds delay. Here is how the total detection latency breaks down for each approach under typical network conditions.
Poll interval (avg 100ms) + HTTP round trip (50–100ms) + server processing (30–50ms) + response parse (10ms)
Event queue delay (150–400ms) + JSON delivery (20–50ms) + client parse (5ms)
Stream delivery (10–50ms) + Protobuf decode (5ms) + Borsh deserialize (15–20ms) + client filtering (5–10ms)
Server-side filter + parse + stream delivery (< 5ms) + zero client processing
The latency gap becomes especially pronounced with Solana's Alpenglow upgrade, which targets 150ms finality. When the entire chain finalizes in 150ms, a data pipeline that adds 250–500ms of detection latency means your bot is consistently 2–3 finality windows behind. With Subglow's sub-5ms delivery, your bot operates within the same finality window as the event itself.
Code comparison
The complexity difference is visible in the code itself. Here is what it takes to detect a Pump.fun token launch with RPC polling versus Subglow's filtered gRPC stream.
RPC Polling — detect Pump.fun launches
// Poll every 200ms for new signatures
while (true) {
const sigs = await connection.getSignaturesForAddress(
PUMP_FUN_PROGRAM, { limit: 10 }
);
for (const sig of sigs) {
if (seen.has(sig.signature)) continue;
seen.add(sig.signature);
const tx = await connection.getTransaction(sig.signature);
const parsed = decodePumpFunInstruction(tx); // your Borsh parser
if (parsed?.type === "create") handleLaunch(parsed);
}
await sleep(200);
}Subglow Filtered gRPC — detect Pump.fun launches
const client = new Subglow({
url: "grpc.subglow.io:443",
apiKey: "your-api-key",
filter: ["pump_fun"],
});
client.subscribe((tx) => {
if (tx.parsed.type === "create") handleLaunch(tx.parsed);
});The RPC approach requires managing a polling loop, deduplication state, multiple API calls per detection, your own Borsh deserializer, and error handling for rate limits and failed requests. The Subglow approach is a single subscription that delivers pre-parsed events as they happen — no polling, no deduplication, no Borsh, no rate limits.
Frequently asked questions
What is the difference between Solana RPC and gRPC?
Solana RPC uses the JSON-RPC protocol over HTTP where your client polls the validator for data. gRPC (specifically Yellowstone/Geyser gRPC) uses a persistent streaming connection where the validator pushes data to your client in real time. gRPC eliminates polling latency, supports backpressure, and can deliver transactions within milliseconds of confirmation rather than hundreds of milliseconds.
Is gRPC faster than WebSocket for Solana?
Yes. Solana WebSocket subscriptions typically deliver events 200–500ms after confirmation, suffer from dropped connections, and offer limited server-side filtering. Yellowstone gRPC delivers data 10–50ms after confirmation with built-in backpressure and reconnection guarantees. Filtered gRPC services like Subglow reduce this further to under 5ms by pre-parsing and filtering at the source.
What is Yellowstone gRPC?
Yellowstone is an open-source Geyser plugin for Solana validators developed by Triton. It exposes a gRPC interface that streams real-time blockchain data — transactions, account updates, slot notifications, and block metadata — directly from the validator. It replaces the need for RPC polling by giving clients a persistent, low-latency data firehose.
Do I need to run my own Geyser plugin?
No. Running a Geyser plugin requires operating a full Solana validator or RPC node with the plugin installed, which costs thousands per month in hardware and maintenance. Services like Subglow run the Geyser infrastructure for you and expose a managed gRPC endpoint that you connect to with an API key.
What is filtered gRPC?
Filtered gRPC adds a server-side filtering and pre-parsing layer on top of raw Yellowstone gRPC. Instead of receiving every transaction on the network (15,000+ per second) and filtering locally, a filtered gRPC service only sends you the transactions matching your criteria — already deserialized from Borsh into clean JSON. This dramatically reduces bandwidth, CPU usage, and end-to-end latency.
How much does Solana gRPC cost?
Running your own Geyser node costs $2,000–$5,000+/month for hardware alone. Managed raw gRPC providers typically charge $300–$1,000/month. Subglow's filtered gRPC starts at $99/month for the Sniper tier with Pump.fun, Raydium, and Jupiter streams, $249/month for Pro with zero rate limits and custom filters, and custom pricing for dedicated infrastructure.
Can I use gRPC for Pump.fun sniper bots?
Absolutely — gRPC is the preferred data source for competitive Pump.fun sniper bots. RPC polling is too slow to catch launches before they spike. With Subglow's filtered gRPC, you receive pre-parsed Pump.fun events (creates, buys, sells, migrations) the instant they confirm, giving your bot a sub-5ms head start over RPC-based competitors.
What is Subglow?
Subglow is a managed Solana gRPC infrastructure provider that delivers filtered, pre-parsed blockchain data. Instead of sending you the raw firehose of 15,000+ transactions per second, Subglow filters at the source for programs you care about (Pump.fun, Raydium, Jupiter, or custom Program IDs) and delivers clean JSON with under 5ms slot lag. It eliminates the need to run your own Geyser node, write Borsh deserializers, or waste CPU on irrelevant transactions.
Ready to upgrade from polling?
Start receiving filtered, pre-parsed Solana transactions in under 5 minutes. Free trial available — no credit card required.