Solana WebSockets vs gRPC: When to Switch and How

Both WebSocket and gRPC are meant to push Solana updates to the application without the need for client-side polling; for some types of dashboard subscriptions, the two can be used interchangeably. Differences arise when working on a larger scale: WebSocket subscriptions happen on the RPC layer after the block processing, transfer JSON, and become hard to maintain past several dozen subscriptions. On the other hand, Geyser gRPC is integrated into the node process, transfers binary data, applies server-side filters, and works well with thousands of accounts on a single stream. The suggested way to migrate is from WebSockets to gRPC as soon as the subscription count, message rate, or latency become a problem, whereas WebSockets continue to be used in simple scenarios.

Operational mechanisms

WebSocket is a subscription part of the Solana JSON-RPC API. A WebSocket Secure (WSS) connection is established with an RPC node, subscribe requests are performed, and the node starts pushing notifications in JSON format when matching events reach the chosen commitment level. The events themselves are collected by the node in its internal block processing, and the RPC service then formats and sends them.

Geyser gRPC is a plugin running inside the node process. It receives every account write, transaction, slot, and block, processed by the node, and streams the subset of it that satisfies the user-defined filters using a gRPC connection based on Protocol Buffers. No intermediary RPC layer is involved here, and no JSON is used. Yellowstone is the default plugin, and you can find details about the subscription model of Yellowstone gRPC in its documentation.

Comparative overview

Use cases for WebSockets

• Transaction confirmation: the signatureSubscribe functionality provides a simple tool to track a transaction until it reaches the desired commitment level.
• Simple dashboards: keeping track of just a few accounts and the balances and logs of some programs using WebSocket capabilities is quite easy.
• Notifications where some latency is not a concern: notifications where some hundred milliseconds delay is acceptable.
• Client simplicity: wide library support with almost no dependencies.

Use cases for gRPC

• Mass account watching: keeping track of hundreds of wallets or all accounts belonging to a certain program with gRPC subscriptions is much easier than with WebSockets.
• High message rate: the high message rate becomes a performance bottleneck for JSON serialization and per-subscription overhead on WebSockets; gRPC can handle the high throughput of streams.
• Latency-sensitive logic: apps like trading, liquidation, and copy-trading bots require earlier visibility and server-side filters.
• Comprehensive transaction metadata at scale: Yellowstone transaction updates contain inner instructions, balance changes, and logs; the information vital for indexing.

There is a third option for workloads where a single event is being watched that comes before both WebSockets and gRPC ones: shred-based streams like Jetstream where the transactions reconstructed from the leader broadcasts prior to node processing of the blocks are sent. The Shredstream architecture explains why it works in advance.

Migration from WebSockets to gRPC

The transition doesn't have to be a full-scale thing done at once. The steps can be the following:

1. Measure your baseline metrics: number of subscriptions, message rate, and latency between the slot of the event and the processing of it by the app. It will show what subscriptions to migrate.
2. Migrating the largest subscription first: it usually involves the programSubscribe or many accountSubscribe requests. Replace them with one gRPC accounts filter scoped to the program owner.
3. Migrating the latency-sensitive subscription next: the subscription that drives the bot's logic. Replace it with gRPC transactions or accounts filter at the processed or confirmed commitment.
4. Keeping the simple subscriptions on WebSockets until you have reasons to migrate them: for instance, signatureSubscribe for your own transactions.
5. Handling reconnections and possible gaps. gRPC streams are prone to disconnections; perform idempotent resubscriptions and check the state of the stream against the chain after a long pause.

Common mistakes

• Opening a WebSocket for every account. Better to multiplex the subscriptions on one connection or, even better, migrate them to gRPC.
• Client-side filtering on gRPC: subscribe widely and filter locally, thus consuming extra bandwidth and latency. Use the filters in the subscription request.
• Using processed commitment without considering rollbacks: the earliest commitment on either transport is reversible; use confirmed ones unless you can handle the reversion.
• Polling and subscribing to the same thing simultaneously: if you have a subscription, stop polling the same data, as it wastes the request bandwidth and is slower.
• Ignoring slot gaps: keep track of the slot corresponding to each message; the growing difference between the message slots and the current slot shows that the consumer is falling behind.

Cost aspects

WebSocket is included in most plans, even free tiers, because the node processes each event only once irrespective of the subscriber count. gRPC is usually a higher tier or a separate product because it transfers much more data per client.

Conclusion

Both WebSocket and gRPC transfer Solana updates; the differences are in the node interface, data serialization, filters, and scalability capabilities. WebSockets are to be used in simple, small-scale, and latency-tolerant subscriptions, as well as for confirming one's transactions. Geyser gRPC should be used for multi-account watching, high message rate, latency-sensitive logic, and the shred stream in case you need an early event visibility prior to the node block processing. The transition should be gradual with the prioritization of subscriptions depending on the workload.

OrbitFlare provides WebSocket on all plans and Yellowstone and Jetstream gRPC across all eleven regions. You can find more details on the gRPC page.

Resources

1. Solana WebSocket RPC methods (Solana docs)
2. Geyser plugins (Anza docs)
3. Yellowstone gRPC (GitHub)
4. Shredstream explained (OrbitFlare)
5. Jetstream and Yellowstone gRPC streaming (OrbitFlare)
6. OrbitFlare RPC plans