Supabase Realtime Broadcast Now Sends Binary, Old Clients Miss It

Supabase’s Realtime Broadcast channel can now carry binary payloads alongside JSON, letting apps push raw ArrayBuffer or Uint8Array data over the same WebSocket pub/sub channel used for chat and presence, according to the Supabase Developer Update for July 2026, published July 9, 2026. Send one to a client running an older SDK, though, and it never arrives. No error, no warning.

---

What actually changed

Broadcast has always been JSON-only: every message got text-encoded before it went over the wire, whether it was a chat bubble or a stream of sensor readings. That’s fine for small, sparse payloads, but it adds real overhead for dense, high-frequency numeric data, the kind you’d see in IoT telemetry or a live screenshot feed. Supabase’s changelog names both as motivating cases, since binary encoding skips the text-serialization tax entirely.

The support spans every way a Broadcast message can originate, not just one client library: the WebSocket clients, the REST API, and messages sent directly from the database. On the client side, it requires supabase-js 2.91.0 or newer and supabase-swift 2.44.0 or newer. The Dart, Kotlin and Python client libraries don’t support binary payloads yet.

The silent-drop gotcha

A binary payload sent to a client on an SDK version that predates binary support isn’t rejected, queued or logged as an error. It’s silently dropped. The message simply never arrives over the WebSocket, and nothing in the client or server signals that anything went wrong.

That’s a rough failure mode for a realtime feature. A dropped chat message gets noticed by a user immediately. A dropped telemetry frame or lost keystroke in a collaborative canvas can go unnoticed until someone’s debugging why data is missing downstream, with no error in any log to point at. Mixed-version fleets are the obvious risk: a mobile app that hasn’t force-updated everyone, or a web client with a stale cached bundle, will have some sessions silently missing every binary broadcast while the rest work fine.

Who should act now

If you’re not touching Broadcast, or you’re staying on JSON payloads, nothing changes for you today. If you plan to adopt binary, audit your client version floor first. That means confirming your minimum supported supabase-js/supabase-swift version meets the 2.91.0 / 2.44.0 threshold before any server-side code starts emitting binary messages, and treating any Dart, Kotlin or Python consumer as unsupported until Supabase ships binary support there too.

---

Key Takeaways

• Realtime Broadcast supports binary payloads (ArrayBuffer/Uint8Array) as of the July 9, 2026 Supabase Developer Update, across WebSocket clients, the REST API and database-originated messages.
• Requires supabase-js >= 2.91.0 or supabase-swift >= 2.44.0. Dart, Kotlin and Python clients don’t support it yet.
• Clients on older SDK versions silently drop binary messages. No error is raised on either end.
• Cited use cases are sensor telemetry and live screenshot streaming, where JSON’s text encoding adds meaningful overhead.
• Confirm your fleet’s minimum client version before sending your first binary Broadcast message in production.

---

The take

Binary support is the right feature; the failure mode around it is the part that should give teams pause. A silent drop is a worse default than a hard error for a message-passing primitive, because it fails exactly the way that’s hardest to catch in testing: works fine on your dev machine with a fresh install, breaks in production on the 8% of sessions still running a bundle from three releases ago. Until Supabase adds a way to detect or warn on an unsupported client, treat any Broadcast channel carrying binary as a “confirm the whole fleet updated first” rollout, not a drop-in change.