Solana gRPC vs WebSocket
Both protocols stream Solana state to your client. One is optimized for trading-bot latency, the other is the universal default built into every RPC node. Here's exactly how they differ and when to use each.
| Dimension | gRPC (Yellowstone) | WebSocket (JSON-RPC) |
|---|---|---|
| Transport | HTTP/2 binary (protobuf) | WebSocket (JSON) |
| Push model | Server pushes matched events | Validator pushes to subscription channel |
| Typical latency (vs gRPC) | Baseline (30–80ms p50) | +15–50ms p50 |
| Filtering granularity | Per-program, per-account, include/exclude, vote/failed flags | Per-account OR per-program, no combined filter |
| Subscription count per connection | Unbounded (per provider policy) | ~100 on public RPC |
| Parse cost on client | Borsh + protobuf (or 0ms on Subglow pre-parsed) | JSON.parse + field mapping |
| Reconnect semantics | Resume from last-seen slot | Full re-subscribe required |
| Client library ecosystem | @triton-one/yellowstone-grpc, yellowstone-grpc-client (Rust), grpcio (Python), grpc-go | @solana/web3.js, anchor-client, every Solana SDK |
| Best fit | Trading bots, copy trading, arbitrage, snipers | Wallet trackers, dashboards, analytics, learning |
The honest take
Use WebSocket when: you're building a wallet tracker, a dashboard, a notification service, an educational project, or anything where a 50–100ms wire latency delta doesn't change the product. It ships with every Solana SDK, works from the browser, and has zero setup cost. The whole ecosystem knows it.
Use gRPC when: you're building a bot where fill latency maps directly to P&L. Pump.fun snipers, copy trading, cross-DEX arbitrage, liquidation bots, MEV-adjacent strategies. The combined 15–50ms wire advantage plus 15–30ms parse advantage (with pre-parsed providers like Subglow) compounds across every decision your bot makes.
A common pattern: keep WebSocket for wallet/user-facing UI, put gRPC on the hot execution path. You don't have to choose one.
FAQ
Is Solana WebSocket the same as gRPC?
No. Solana WebSocket (wss://) is the JSON-RPC subscription API built into every Solana validator — accountSubscribe, logsSubscribe, slotSubscribe, etc. It's pull-initiated from the client, uses JSON over WebSocket frames, and has hard per-connection limits. gRPC (Yellowstone) is a separate protocol that runs as a Solana Geyser plugin, pushes protobuf messages bidirectionally, and was designed for high-throughput streaming. Both work, but they target very different workloads.
Which is faster, gRPC or WebSocket, for Solana?
gRPC wins consistently by 15–50ms p50. Three reasons: (1) Geyser push vs RPC poll — gRPC ships updates the moment the validator processes them, WebSocket notifications wait for the validator's notification channel which runs after slot commit; (2) binary protobuf vs JSON — protobuf decode is 3–5x faster than JSON.parse for equivalent payloads; (3) multiplexing — a single gRPC connection handles thousands of subscriptions with flow control, while WebSocket clients typically fan out to multiple connections to avoid per-connection limits.
Can I build a trading bot on Solana WebSocket?
For low-frequency or discretionary workflows, yes. For anything touching Pump.fun bonding curves, fresh Raydium pools, or sub-second reaction windows, you'll lose to bots running gRPC. The latency delta consistently shows up at entry fills. For copy trading specifically, 400–800ms of extra delay often turns a profitable mirror into a losing one. WebSocket is fine for dashboards, wallet trackers, and analytics pipelines.
What are the per-connection limits on Solana WebSocket?
Standard public RPC WebSocket has a ~100 concurrent subscription limit per connection and a handful of message-rate limits depending on the provider. Helius, QuickNode, and Triton WebSocket tier all apply quotas. gRPC providers typically don't limit subscription count within a single connection — you send one SubscribeRequest that includes filters for as many programs and accounts as you need.
Can I migrate from WebSocket to gRPC incrementally?
Yes, and most teams do. Keep your existing WebSocket wiring running, open a parallel gRPC connection for the latency-critical subscriptions (Pump.fun buys, Raydium swaps, etc.), and swap components over one at a time. The two protocols don't conflict — you can subscribe to the same program on both and compare fill latency for a week before committing. Subglow's client libraries are drop-in for standard Yellowstone, so the migration is a few hours of work, not days.
Does Subglow support Solana WebSocket?
No — Subglow is gRPC-first. We don't operate a public WebSocket endpoint because the audience that needs WebSocket specifically is well-served by Helius, QuickNode, and similar full-platform providers. If you're on WebSocket and want to move to gRPC, Subglow is the purpose-built answer; if you need both protocols in one bill, a multi-protocol provider is the better fit.