Supabase Realtime Binary Payloads | Algoramming

Supabase Realtime Binary Payloads | Algoramming

If you have ever built a real-time collaborative map, a multiplayer game, or an industrial dashboard, you know the exact moment the system begins to crawl. It usually happens when the network tab in your browser's developer tools turns into a waterfall of massive, repetitive JSON payloads. Every second, hundreds of connected devices send coordinates, temperatures, or game states, and your servers spend precious CPU cycles stringing together text, encoding it, and shipping it across a WebSocket connection.

For years, developers using Supabase Realtime had to live with JSON as the default format for ephemeral broadcast messages. When those messages contained binary data, such as compressed audio, sensor readings, or raw image frames, the standard workaround was to convert the data into a base64 string. This workaround came with a severe performance penalty, commonly known as the base64 encoding tax, which inflates payload sizes by at least thirty-three percent and spikes CPU usage on both clients and servers.

Recently, Supabase quietly addressed this bottleneck by rolling out native binary payload support for Realtime Broadcast. Clients can now send and receive raw binary payloads directly over WebSockets, the REST API, and even from the PostgreSQL database itself. By bypassing the base64 and JSON serialization pipelines, you can drastically reduce your bandwidth overhead, minimize client-side memory churn, and scale your real-time infrastructure to handle high-frequency data streams.

At Algoramming, we build high-scale, responsive digital products for clients worldwide. Whether we are engineering a unified operations dashboard for multi-branch businesses as we did in our Algonize case study, or designing data-heavy portals, optimizing network protocols is core to our engineering philosophy. In this deep dive, we will analyze why binary payloads are a massive win for real-time applications, how the underlying protocols work, and how you can implement them to achieve unmatched efficiency.

What is the primary bottleneck when scaling WebSocket data?

The primary bottleneck when scaling WebSocket data is the computational and bandwidth overhead of text-based serialization. When transmitting high-frequency updates, converting raw numeric or binary data into JSON strings or base64 text inflates payload sizes by up to five times, driving up server egress costs and overwhelming client-side CPU garbage collection.

The Base64 and JSON Tax on Real-Time WebSockets

To appreciate why binary payloads are a massive technical upgrade, we must first look at the mechanisms of text-based formats. When WebSockets became a standard protocol, text-based messaging (primarily JSON) emerged as the default choice. Developers loved it because it was human-readable, easy to debug, and supported out of the box by almost every web language. However, text-based structures are highly inefficient for machine-to-machine communication.

Consider a simple GPS coordinate consisting of a latitude and a longitude, both sixty-four-bit floating-point numbers. In raw binary, these two numbers occupy exactly sixteen bytes of memory. If we serialize this same coordinate into a JSON object, the result is a text string like {"lat":37.774929,"lng":-122.419416}. This string contains thirty-eight characters. Because each character in a JSON string is typically encoded as one byte in UTF-8, our sixteen bytes of data have ballooned to thirty-eight bytes before we even account for the network protocol wrappers.

The problem escalates when we need to transmit actual binary files, such as custom sensor telemetry formats, audio fragments, or compressed image frames, over a text-only channel. To make binary data safe for text-based transport, developers use Base64 encoding. Base64 works by taking every three bytes of binary data (twenty-four bits) and mapping them onto four printable ASCII characters (each representing six bits of information).

Every time you encode binary data to Base64, you pay a guaranteed thirty-three percent size penalty.

This thirty-three percent inflation represents only the baseline network cost. In practice, the performance penalty is far worse because of the CPU overhead. To send a Base64 payload, the client must allocate memory, run the encoding algorithm, wrap the result in a JSON string, and transmit it. The receiving server must then parse the JSON, locate the Base64 string, allocate new memory, and decode the string back into binary. For a single user, this process is negligible. For ten thousand concurrent users receiving ten updates per second, this constant cycle of encoding, decoding, and string allocation triggers relentless garbage collection pauses on the client and drives up server hosting costs.

Inside Supabase Realtime Binary Payloads: Architecture and Core Protocols

The core of Supabase's Realtime engine is built on Elixir and the Phoenix Framework, running on the Erlang Virtual Machine. The Erlang runtime is famous for its ability to handle millions of concurrent connections with extremely low latency, making it the perfect foundation for a real-time message broker. Phoenix Channels, which power Supabase's Realtime Broadcast and Presence features, natively support both text and binary frames over WebSockets.

Until recently, the client-side SDKs and database helpers wrapped all communication in JSON. If you wanted to broadcast an update, the Supabase client library would serialize your data as a JSON string, and the Realtime server would route that text string to other connected clients. With the release of native binary payload support, the architecture has been opened up to allow end-to-end binary streaming.

Under this new architecture, the Realtime server can receive a raw binary stream over a WebSocket connection, read the channel routing headers, and broadcast the untouched binary payload to all subscribed clients. The server does not attempt to parse, deserialize, or inspect the binary payload. It acts as a pure, high-speed pipe. This design allows you to use highly optimized binary serialization protocols, such as Protocol Buffers, FlatBuffers, or custom packed binary arrays, directly within your application code.

This upgrade is supported across the entire Supabase ecosystem. You can broadcast binary payloads via the client libraries over WebSockets, make single-message POST requests to the REST API with a binary content-type, or trigger binary broadcasts directly from your PostgreSQL database using database functions. This native support removes the middleman, ensuring that your data travels from source to destination in its most compact, efficient form.

The Mechanics of Packing Binary Data: ArrayBuffers and Typed Arrays

To use binary payloads effectively, you must understand how modern web browsers and runtime environments handle binary data in memory. In JavaScript, raw binary data is represented by the ArrayBuffer object. An ArrayBuffer is simply a fixed-length, contiguous block of physical memory. You cannot read or write to an ArrayBuffer directly. Instead, you must use a view, such as a TypedArray or a DataView, to interpret the bytes.

TypedArrays provide a way to read and write uniform binary data. For example, a Float32Array treats the underlying buffer as an array of thirty-two-bit floating-point numbers, while a Uint8Array treats it as an array of unsigned eight-bit integers. If you are building a real-time tracking application, you can allocate an ArrayBuffer of twelve bytes: four bytes for a thirty-two-bit integer representing a user identifier, four bytes for a float representing the X coordinate, and four bytes for a float representing the Y coordinate.

For more complex, heterogeneous data structures, a DataView is highly effective. A DataView lets you read and write different types of numbers (integers, floats, signed, unsigned) at arbitrary byte offsets within the same ArrayBuffer. This approach gives you absolute control over the byte layout of your payload. You can pack a boolean into a single bit, an enum into a single byte, and coordinates into half-precision floats, creating a custom binary protocol that is incredibly compact.

The following list outlines the primary benefits of using raw binary arrays over JSON objects for web applications:

• Zero Parsing Overhead: Browsers can read values directly from a typed array in memory, bypassing the costly string-parsing phase required by JSON.
• Minimal Memory Footprint: Binary arrays store data sequentially without key names, brackets, or commas, reducing memory usage by up to eighty percent.
• Predictable Allocation: Because binary buffers have a fixed length, they can be pre-allocated and reused, preventing memory fragmentation and reducing garbage collection frequency.

How to Send Binary Data with the Supabase Client SDK

To implement binary payloads in your application, you must ensure you are using the correct library versions. Binary payloads are supported starting with supabase-js version 2.91.0 and supabase-swift version 2.44.0. If your clients are running older versions of the SDK, any binary messages sent to them will be silently dropped by the client library. Keeping your libraries up to date is critical to avoiding difficult-to-debug connection issues.

When initializing a Realtime channel with the JavaScript SDK, you subscribe to the channel as you normally would. When you are ready to broadcast a message, instead of passing a standard JavaScript object as the payload, you pass an ArrayBuffer or a view like Uint8Array. The SDK detects the binary type and automatically transmits it as a binary frame over the established WebSocket connection, bypassing any JSON serialization.

On the receiving end, the channel listener's callback receives the raw binary payload. The payload is delivered to your application as an ArrayBuffer. From there, you can instantiate a DataView or a TypedArray over the buffer to unpack the variables. Because the client receives the raw bytes directly from the network socket, there is no intermediate string conversion, allowing your code to read the incoming values with minimal latency.

This process is highly efficient because modern browsers optimize WebSocket binary frames at the system level. The browser receives the TCP packets, reassembles them into a binary frame, and exposes the memory buffer directly to your JavaScript context. If you are building a highly interactive application, such as a collaborative design tool or an online game, this pipeline allows you to update the user interface at sixty frames per second without stuttering.

Broadcasting Binary Payloads Directly from PostgreSQL

One of the most powerful features of Supabase Realtime is the ability to trigger broadcasts directly from your database. This capability is incredibly useful when database events, such as a row insert or an external API webhook, need to notify connected clients instantly. Previously, this required generating a JSON payload in SQL, which could quickly become verbose and difficult to maintain.

To support binary workflows, Supabase introduced the realtime.send_binary() database function. This function accepts a channel topic, an event name, and a payload of the PostgreSQL bytea (binary string) data type. When you call this function, Postgres inserts the binary payload into the realtime.messages table, which triggers the database replication slot. The Realtime server reads the raw bytes from the Write-Ahead Log (WAL) and broadcasts them directly to all subscribed clients over their WebSocket connections.

This database-native binary broadcast mechanism is exceptionally clean. For example, if you are building an IoT data ingestion engine, your database can receive raw binary packets from field devices, store them in highly optimized tables, and immediately broadcast the raw bytea payload to web-based dashboards without any intermediate Node.js or serverless function translation. This direct path from database to browser minimizes moving parts and reduces latency to the absolute physical limit of your network.

When designing database triggers that broadcast binary payloads, you should construct your binary arrays carefully within your SQL functions. PostgreSQL provides powerful built-in binary manipulation functions, such as set_byte and set_bit, allowing you to pack status flags, sensor readings, and timestamps into a compact bytea variable. This ensures that your database-driven updates remain as light as those sent directly from client WebSockets.

Scaling IoT Dashboards with Densely Packed Sensor Telemetry

Industrial internet of things (IoT) dashboards are notorious for pushing web browsers to their limits. A typical IoT deployment might involve hundreds of sensors reporting temperature, humidity, vibration, and electrical current multiple times per second. If you attempt to stream this telemetry using standard JSON over WebSockets, the browser's main thread quickly becomes choked with JSON parsing tasks, leading to unresponsive user interfaces and dropped frames.

By adopting a binary protocol over Supabase Realtime, you can achieve an order-of-magnitude improvement in dashboard performance. Instead of transmitting descriptive JSON keys like {"sensor_id": 412, "temp": 23.85, "humidity": 62.4}, you can pack this data into a tiny binary packet. A single four-byte integer can hold the sensor identifier, a four-byte float can hold the temperature, and a two-byte integer can hold the humidity scaled to a percentage. This reduces the payload from fifty-three bytes of text to just ten bytes of binary.

When we scaled municipal waste management dashboards in our DSCC Weighbridge project, we saw firsthand how critical it is to design lean data flows for real-time tracking. By optimizing your telemetry streams to use binary arrays, you achieve massive savings in bandwidth and client processing. For example, if a field dashboard monitors fifty sensors operating at fifty hertz, the browser must process twenty-five hundred messages per second. Using JSON, this stream requires substantial bandwidth and triggers continuous garbage collection. Using binary, the data fits into a tiny fraction of that bandwidth, and the client-side CPU usage remains completely flat.

because binary data is so compact, you can store historical telemetry frames locally in browser memory using pre-allocated circular buffers. When a user changes the date range or zooms in on a chart, the application can slice and render the historical data instantly, without needing to make expensive queries back to the database. This local-first architecture is highly responsive, giving users an incredibly smooth interaction pattern.

Real-Time Multiplayer App Performance: Reducing Client CPU and Latency

In real-time multiplayer applications, latency is the ultimate metric. Whether you are building a collaborative digital whiteboard, a virtual office space, or a fast-paced web game, every millisecond of delay between a user's action and the corresponding visual update degrades the user experience. To achieve a responsive feel, updates must be broadcast and rendered in less than fifty milliseconds.

When multiple users are active simultaneously, the volume of broadcast messages increases quadratically. If ten users are moving their cursors at thirty updates per second, the server must process and distribute three hundred messages per second. If you scale that to one hundred users, the message volume jumps to thirty thousand messages per second. If each message is a text-based JSON object containing coordinates and user metadata, the client's main thread will spend all of its time parsing strings instead of rendering the user interface.

By implementing a custom binary protocol over Supabase Realtime, you can eliminate this CPU bottleneck. Instead of sending user profiles and state changes as nested objects, you can serialize them into a fixed-length byte buffer. The first few bytes can contain a compressed unique identifier, followed by packed bitwise flags representing user states (such as active, writing, or selecting), and finally, the coordinate values stored as compact sixteen-bit integers.

On the client side, decoding this binary payload is incredibly fast. Rather than invoking the standard JSON parsing engine, which allocates thousands of short-lived objects that must be cleaned up by the JavaScript garbage collector, your application can read the values directly from the incoming array buffer. This direct memory access keeps the browser's main thread free to handle UI rendering at a steady sixty frames per second, ensuring a responsive user experience even on low-end mobile devices.

Honest Trade-offs of Going Pure Binary

While binary payloads offer massive performance advantages, they are not a silver bullet for every real-time application. Designing, building, and maintaining a custom binary protocol introduces significant engineering complexity. As a professional software development partner, we believe in being entirely transparent about the trade-offs involved before you commit to a major architectural rewrite.

First, binary protocols are notoriously difficult to debug. When you look at a JSON stream in your network tab, you can read the variable names and values instantly. When you look at a raw binary stream, you see nothing but an unreadable sequence of hexadecimal bytes. To debug issues, you must write custom inspection tools or logging wrappers that can deserialize the bytes back into a human-readable format. This adds development overhead and can slow down your debugging cycles, especially during the early phases of an MVP build.

Second, binary payloads require strict schema coordination between the sender and the receiver. If you decide to add a new field to your payload (such as a battery level indicator to your sensor telemetry), you cannot simply add a key as you would in JSON. You must update your serialization code to write the new bytes at a specific offset, and you must update your deserialization code on every client to read those bytes from the exact same offset. If a client running an older version of your application attempts to parse the new binary structure, the offsets will be misaligned, resulting in corrupted data or runtime crashes.

JSON Payload (Self-describing, easy to change):
{ "id": 101, "temp": 24.5 }

Binary Payload (Extremely compact, but brittle):
[ 0x65, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC4, 0x41 ]
(Offsets must match perfectly on both sides)

To mitigate this schema fragility, many teams adopt established serialization frameworks like Google's Protocol Buffers (Protobuf) or FlatBuffers. These tools allow you to define your data structures in schema files, which then generate highly optimized serialization and deserialization code for your front-end and back-end environments. However, integrating these compilers into your build pipelines increases the complexity of your codebase and requires your development team to learn and maintain a completely new set of tools.

Finally, you must consider the financial and operational costs of implementing a binary architecture. While binary payloads will significantly reduce your Supabase network egress bills, the initial engineering cost to design, build, and test a custom binary pipeline is substantially higher than building a standard JSON-based system. If your application only handles a few updates per second for a small number of concurrent users, the performance gains will be unnoticeable, and the investment will not yield a positive return.

In our experience, we recommend skipping a pure binary approach if you are still validating your product-market fit or building an early-stage MVP. At that stage, developer velocity and rapid iteration are far more valuable than micro-optimizations. However, if you are scaling an existing, validated product that processes millions of real-time messages daily, or if you are building for highly constrained hardware environments, migrating to binary payloads is one of the most cost-effective ways to future-proof your infrastructure and slash your operational costs.

A Step-by-Step Security Strategy: RLS and Binary Payloads

Security is a paramount concern when dealing with real-time data streams. When you broadcast messages using Supabase, you must ensure that sensitive data is only delivered to authorized users. Supabase Realtime integrates directly with PostgreSQL's Row Level Security (RLS) policies, allowing you to secure your channels using the same access control rules that protect your database tables.

When a client attempts to join a Realtime channel, the Supabase server authenticates the connection using the user's JSON Web Token (JWT). If you are broadcasting database changes, the server acts as the authenticated Supabase Admin role. It attempts to read the record within a temporary transaction, applying your RLS policies to verify if the subscribing user has permission to view that specific row. If the RLS check fails, the transaction is rolled back, and the message is blocked from being sent to the client.

When transitioning to binary payloads, implementing RLS requires a structured approach because the database cannot natively inspect or parse custom binary arrays to determine ownership. To maintain robust security, we recommend adopting a hybrid routing strategy:

1. Use Descriptive Channel Topics: Instead of broadcasting all updates to a single public channel, partition your traffic into specific, secure topics. For example, use a topic structure like room:tenant_id:device_id.
2. Enforce Row-Level Security on Subscriptions: Write RLS policies on your underlying tables that restrict access based on the tenant or device identifiers embedded within the channel topic. This ensures that a client can only subscribe to channels they are explicitly authorized to view.
3. Validate Payloads in Database Triggers: If you are broadcasting binary payloads directly from PostgreSQL using triggers, validate the sender's permissions within your PL/pgSQL functions before invoking the realtime.send_binary() function.
4. Rotate Encryption Keys for Sensitive Data: For highly sensitive environments, you can encrypt your binary payloads on the client side using lightweight cryptographic libraries before broadcasting them. This ensures that even if a message is intercepted, the data remains completely secure.

By combining topic-based routing with robust database-level RLS policies, you can build a real-time binary streaming pipeline that is both incredibly fast and fully secure. This approach ensures that your application complies with strict data privacy standards while still taking full advantage of the performance benefits of raw binary serialization.

A Checklist for Upgrading Your Existing Realtime Application

If you have decided that migrating to binary payloads is the right choice for your application, you should plan the upgrade systematically to avoid service disruptions. Because binary payloads are handled differently by older client versions, a careless deployment can cause active users to experience silent data loss or application crashes.

Here is the step-by-step checklist we use at Algoramming when upgrading client applications to support binary workflows:

• Audit Client Library Versions: Verify that all client-facing applications are running at least supabase-js version 2.91.0 or supabase-swift 2.44.0. Ensure that platforms using Dart, Kotlin, or Python are excluded from binary features, as these SDKs do not yet support binary payloads.
• Design the Binary Schema: Document your byte offsets and data types. Decide whether you will use raw typed arrays with a DataView or integrate a serialization framework like Protocol Buffers.
• Implement Fallback Mechanisms: Write client-side code that can gracefully handle both old JSON formats and new binary payloads. This allows you to deploy the upgrade without requiring all users to refresh their browsers simultaneously.
• Update Database Functions: If you are broadcasting from PostgreSQL, replace your existing realtime.send() calls with realtime.send_binary(), ensuring that you pass your payload as a valid bytea variable.
• Configure Server Environment Variables: If you are self-hosting Supabase, verify that your Realtime server is updated to at least version 2.103.2.
• Perform Load Testing: Run simulated stress tests using tools like Artillery to measure the reduction in server memory usage, bandwidth consumption, and client-side CPU overhead under high load.
• Deploy in Phases: Roll out the binary upgrade to a small percentage of users first. Monitor client-side error logs and connection stability before enabling binary payloads for your entire user base.

Following this structured approach minimizes deployment risks and ensures a seamless transition for your users. Once the migration is complete, you will immediately observe a significant drop in your network egress costs and a noticeable improvement in your application's responsiveness.

Key takeaways

To help you quickly summarize the architectural shifts and implementation details we have covered, we have compiled the essential points:

Key takeaways

• Zero base64 tax: Native binary payloads over Supabase Realtime eliminate the thirty-three percent size inflation and CPU overhead of converting binary data into text strings.
• End-to-end binary support: You can broadcast raw binary data (such as ArrayBuffer or bytea) via WebSockets, the REST API, and directly from PostgreSQL triggers.
• Drastic performance gains: Moving to a binary protocol can reduce telemetry payload sizes by up to eighty percent and lower client-side CPU usage during high-frequency updates.
• Strict version requirements: Binary payloads require modern SDK versions (such as supabase-js 2.91.0+) and will be silently dropped on older client libraries.
• Increased complexity: Implementing binary streams requires careful schema coordination and custom debugging tools, making it best suited for validated, high-scale applications.

Conclusion

Scaling real-time web applications requires a relentless focus on optimization. The release of native binary payload support in Supabase Realtime represents a major architectural milestone, giving developers the tools to bypass the base64 encoding tax and stream high-frequency data with unprecedented efficiency. By adopting binary protocols, you can unlock massive bandwidth savings, reduce client-side CPU overhead, and future-proof your real-time features.

At Algoramming, we specialize in helping businesses navigate these complex architectural decisions. Whether you are building an IoT dashboard from scratch or optimizing a legacy real-time application, we bring years of hands-on engineering experience to the table. Our team has engineered high-scale, reliable real-time systems for clients around the globe, and we understand how to design software that scales seamlessly under pressure.

If you are planning an engineering project that requires high-performance real-time capabilities, we are happy to talk it through. You can explore our full range of custom software development services to see how we partner with teams to build world-class digital products. Let's connect and discuss how we can help you build highly optimized, scalable, and secure applications that deliver an exceptional user experience.