Solana WebSocket nodes for live account, log, and slot subscriptions

Both methods sit on the same socket and look similar in the docs. The shape of the data they push is wildly different, and getting that wrong costs you a week of debugging.

accountSubscribe fires whenever the bytes at a single pubkey change. The notification carries the slot, the lamport balance, the owner program, and the full data buffer in your requested encoding. We default to jsonParsed for token, stake, and vote accounts so you skip the bincode pass; pass base64 if you need raw bytes. Each notification is one account, fully serialized. Easy to reason about. The cost is one subscription per account; tracking a wallet means subscribing to its base account plus every token account you care about.

logsSubscribe is a different beast. The notification carries a transaction signature, the slot, an error field, and an array of log lines straight from the BPF runtime. No parsed instructions, no decoded arguments, no idea which inner instruction emitted which log unless you walk the array yourself. You also get every log from every program the transaction touched, which on a Jupiter swap might be eight programs deep. The filter options are all, allWithVotes, or a { mentions: [...] } object that scopes to transactions touching specific programs or accounts. Always use the mentions filter. all on mainnet is roughly 2,500 messages per second, most of it vote traffic.

The opinion: logsSubscribe is the wrong tool for parsed events. It's the right tool for two narrow cases: a known-program error log feed (you watch for Program log: Error), and a quick-and-dirty signal that anything happened at a program address while you build the proper gRPC pipeline.

The protocol gives you a TCP connection with TLS on top and JSON messages over the wire. Three things cap your effective throughput and the order they bite is predictable.

The first ceiling, the JSON parse, is what kills most production WebSocket setups. A busy programSubscribe on Token-2022 can land 600 messages per second, and a Node handler that does anything besides JSON.parse falls behind. The server can't magically make your client faster, so the messages queue, then drop. We watch teams hit this around the three-week mark of a launch.

The fix is one of two things. Either narrow the subscription (better filters, accountSubscribe per pubkey instead of one big programSubscribe), or change transports. Yellowstone gRPC handles 5,000+ messages per second on a single connection because Protocol Buffers parse in a quarter of the time JSON does and HTTP/2 multiplexes streams so one slow message doesn't block the next.

We have an opinion on this and we'll be direct about it. WebSocket is the right transport for two things: account-level UIs (a wallet, a position dashboard, a mint counter), and prototypes where you want to see something working in fifteen minutes. Past those two, gRPC is the right answer.

The signal you've outgrown WebSocket is rarely throughput. It's parsing tax. You start writing your own log decoder, then a discriminator router, then a fallback when the log lines are truncated, then a reconciliation pass when the subscription reconnects mid-stream. Every one of those is solved upstream when you switch to gRPC. The events arrive as protobuf messages with a stable schema. You skip the entire decode layer.

Some specific triggers. If you find yourself running multiple logsSubscribe connections in parallel because one isn't keeping up, switch. If you need to filter by accountInclude and accountExclude on the same stream, switch. If you want vote-free transactions and your logsSubscribe mentions filter is matching too many vote txs because the validator touched them, switch.

What stays on WebSocket: signature confirmation polling replaced by signatureSubscribe, a wallet UI showing a balance update, a slot heartbeat for cluster observability, a programSubscribe with tight filters on a low-volume program. Use the right tool for the question. The endpoint sits on our gRPC product page when you're ready.

A WebSocket connection isn't TCP-stable. It will drop. Your client needs to assume that and rebuild state on reconnect, or you'll spend a Saturday wondering why the dashboard stopped updating at 3am.

One more pattern that earns its keep: the snapshot-then-stream flow. Open the WebSocket and subscribe first. Once the subscription ack comes back, fire a one-shot getAccountInfo at the same commitment level. Apply the snapshot to your state. From that point, every notification is a delta. You never miss the starting state and you never double-count the moment between the subscribe and the snapshot.

Solana doesn't expose Server-Sent Events natively, but the comparison still matters because some teams reach for SSE through a proxy and end up worse off. Here's the honest take.

For a frontend that needs to show live state, the working pattern is: backend connects to our WebSocket (or gRPC for high volume), fans the relevant slice out to the browser via either WebSocket or SSE. That keeps the auth header on the server, lets you cache and dedupe before the browser sees anything, and gives you a natural place to add business logic between the chain and the UI.

For a backend that needs to react to state, skip SSE entirely. WebSocket if the volume fits, gRPC if it doesn't. Polling only for things that genuinely change slowly: an Epoch boundary, a stake-account state, a once-per-minute price.