Yellowstone gRPC vs WebSockets: choosing a real-time Solana data pipeline

Every real-time Solana system eventually faces the same fork in the road: WebSocket subscriptions or Yellowstone gRPC. They look like two flavors of the same thing, since both push you chain events as they happen. But they originate from different subsystems inside the validator, carry different data, and fail in different ways. Picking wrong costs you either months of unnecessary plumbing or hundreds of milliseconds you can't get back.

01Two doors into the validator#

A common misconception is that WebSocket subscriptions are “Geyser with JSON.” They're not. The WebSocket PubSub API is part of the validator's built-in RPC service, fed by the same internal notifications that serve HTTP reads. Yellowstone gRPC is a Geyser plugin: a shared library loaded into the validator process that taps account writes, transactions, entries, and block metadata at the moment the runtime commits them, then serves them over its own gRPC server.

                    ┌─────────────────────────────────────────┐
                    │              solana validator           │
                    │                                         │
   replay/banking ──┼──▶ runtime commits state                │
                    │         │                               │
                    │         ├──▶ geyser plugin interface    │
                    │         │       │                       │
                    │         │       └──▶ yellowstone gRPC ──┼──▶ protobuf stream
                    │         │            (in-process)       │    (accounts, txs,
                    │         │                               │     slots, blocks)
                    │         └──▶ rpc service                │
                    │                 │                       │
                    │                 └──▶ pubsub websocket ──┼──▶ JSON notifications
                    │                      (accountSubscribe, │    per subscription
                    │                       logsSubscribe, …) │
                    └─────────────────────────────────────────┘

That architectural difference drives everything downstream: what data you get, how fresh it is, how it's encoded, and what happens when something breaks.

02WebSocket subscriptions in practice#

The PubSub API gives you a JSON-RPC subscription per question: accountSubscribe for one account's changes, programSubscribe for every account owned by a program, logsSubscribe for transaction logs mentioning an address, slotSubscribe and blockSubscribe for chain progress. It speaks the same commitment levels as HTTP reads, works from any language with a WebSocket client, and requires zero schema tooling. Watching PumpFun activity is a dozen lines:

import WebSocket from 'ws'

const PUMP_FUN = '6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P'
const ws = new WebSocket(process.env.WSS_URL!)

ws.on('open', () => {
  ws.send(JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'logsSubscribe',
    params: [
      { mentions: [PUMP_FUN] },          // txs that mention the program
      { commitment: 'confirmed' },
    ],
  }))
})

ws.on('message', raw => {
  const msg = JSON.parse(raw.toString())
  if (msg.method !== 'logsNotification') return
  const { signature, err, logs } = msg.params.result.value
  if (err) return                         // failed tx — usually skip
  // You get log lines, not decoded state. Parsing is on you.
  if (logs.some((l: string) => l.includes('Instruction: Buy'))) {
    console.log('buy:', signature)
  }
})

// Providers drop idle/zombie sockets. Heartbeat or be culled.
setInterval(() => ws.ping(), 30_000)

Honest assessment of what you just built:

• It was fast to write. No protobufs, no codegen, no client library. This is the transport's genuine superpower.
• You received log lines, not state. logsSubscribe hands you strings; recovering amounts, mints, and accounts means parsing instructions yourself or making follow-up HTTP calls, which adds back the latency you subscribed to avoid.
• JSON costs you twice. Once on the wire (base64-in-JSON inflation), once in JSON.parse at 5,000 notifications per second.

03Yellowstone gRPC in practice#

Yellowstone inverts the model. You open one bidirectional stream and send one SubscribeRequest describing everything you want: transactions touching certain accounts, account writes for certain owners, slots, blocks, entries. All of it is filtered server-side inside the plugin before a single byte crosses the network. The same PumpFun watcher, upgraded:

import Client, { CommitmentLevel } from '@triton-one/yellowstone-grpc'

const PUMP_FUN = '6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P'
const client = new Client(process.env.GRPC_URL!, process.env.GRPC_TOKEN, {})

const stream = await client.subscribe()

// One stream, server-side filtering. The validator's Geyser plugin
// pushes us full transactions — accounts, instructions, balances —
// not just log lines.
stream.write({
  commitment: CommitmentLevel.PROCESSED,
  transactions: {
    pump: {
      accountInclude: [PUMP_FUN],
      accountExclude: [],
      accountRequired: [],
      vote: false,
      failed: false,
    },
  },
  accounts: {}, slots: {}, blocks: {}, blocksMeta: {},
  entry: {}, transactionsStatus: {}, accountsDataSlice: [],
})

stream.on('data', update => {
  if (update.transaction) {
    const slot = update.transaction.slot
    const tx = update.transaction.transaction
    // Binary, complete, and ~hundreds of ms ahead of confirmed WS.
    handleTransaction(slot, tx)
  }
  if (update.ping) stream.write({ ping: { id: update.ping.id } })
})

What changed, concretely:

• Full transactions, not logs. Instructions, account keys, pre/post balances, metadata. Decoded amounts are a borsh-parse away, with no follow-up reads.
• processed at the source. Geyser emits the moment the runtime commits, so you see activity slots before a confirmed WS notification describes it.
• Protobuf on the wire. Smaller payloads, cheaper decode, and a typed schema that fails at compile time instead of at 3 a.m.
• The cost is real tooling. A gRPC client, TLS config, token auth, ping handling, and a build step. Budget a day, not an hour.

04Latency and payload: the numbers#

We measured both transports side by side on the same machine, subscribed to the same program, against endpoints in the same datacenter, recording when each transport first told us about each transaction:

Two things worth internalizing. First, commitment dominates transport: gRPC at confirmed is slower than WebSocket at processed, because waiting for the cluster to vote costs more than any serialization format saves. Second, at equal commitment, gRPC still wins by 50 to 150ms at the tail. The JSON encode/decode and the PubSub notification machinery are pure overhead the Geyser path never pays.

05Failure modes and recovery#

Steady-state latency is what gets benchmarked; recovery behavior is what gets you paged. The transports diverge sharply here.

WebSocket: detect and reconcile

A dropped WS connection loses everything in the gap. Your recovery story is to detect fast (heartbeats, idle timers), resubscribe, then reconcile what you missed via HTTP reads. Accept that for log-shaped data, perfect reconciliation may be impossible.

gRPC: resume from slot

Yellowstone keeps a short in-memory slot buffer and accepts a fromSlot on subscribe. Track the last slot you processed, and a reconnect becomes a resume instead of a gap:

let lastSlot = 0n

async function consume(): Promise<never> {
  for (;;) {
    try {
      const stream = await client.subscribe()
      stream.write(buildRequest({
        // Resume from where we left off. Yellowstone replays the gap
        // from its slot buffer instead of silently skipping it.
        fromSlot: lastSlot > 0n ? String(lastSlot) : undefined,
      }))
      for await (const update of stream) {
        if (update.transaction) {
          lastSlot = BigInt(update.transaction.slot)
          await handleTransaction(update.transaction)
        }
        if (update.ping) stream.write({ ping: { id: update.ping.id } })
      }
    } catch (err) {
      console.error('stream dropped, resuming from slot', lastSlot, err)
      await new Promise(r => setTimeout(r, 1_000))   // backoff, then resume
    }
  }
}

06Choosing your pipeline#

Our decision table, distilled from operating both fleets:

07When you want neither#

There's a third option this comparison quietly assumes away: not running the pipeline at all. Both transports hand you raw chain data. You still own program-specific decoding, IDL drift when protocols upgrade, and the unglamorous work of keeping parsers correct across 37 programs' worth of instruction layouts.

That layer is a product. Our Enhanced Streams deliver decoded, schema-stable events (swaps, launches, graduations, liquidity changes) over the same WebSocket and gRPC transports, and Program Streams expose every instruction and event of every major program as 1,074 individually subscribable topics. The transport trade-offs in this post still apply; the decoding burden doesn't.

The summary we'd put on a sticky note: WebSocket is the right default; Yellowstone gRPC is the right ceiling. Start with the transport you can ship this afternoon, instrument your first-sight latency honestly, and when the numbers in Table 1 start costing you money, the gRPC migration is a well-marked road. Both doors are on our endpoints. Run the comparison yourself.