Supabase Realtime: An Elixir WebSocket Server for Broadcast, Presence, and Postgres Changes
Broadcast, Presence, and Postgres Changes via WebSockets. This is a server built with Elixir using the Phoenix Framework that enables the following functionality: Broadcast: Send ephemeral messages from client to clients with low latency.
At a glance
- What is it?
- Supabase Realtime is an Elixir and Phoenix based server that pushes ephemeral messages, synchronizes state, and streams Postgres changes over WebSockets. It is production ready for v2, but message delivery is not guaranteed, and Postgres compatibility depends on specific supabase/postgres versions.
- Who is it for?
- Adopt Supabase Realtime if you are already on the Supabase platform and need low-latency client-to-client messaging, presence tracking, or Postgres change streaming over WebSockets without building a custom Phoenix channel server. Do not adopt it if you require guaranteed message delivery for every event, or if your Postgres version is below 14.x, since those are unsupported.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Elixir, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What It Solves and Who It Is For
Supabase Realtime solves the problem of pushing data from a server to many clients in real time, and also from one client to other clients. It is built for developers who already use Supabase as their backend and want to add live features without running a separate messaging infrastructure. The README lists three core functions: Broadcast for ephemeral messages, Presence for tracking and synchronizing shared state between clients, and Postgres Changes for listening to database changes and sending them to authorized clients. The target user is a Supabase developer who wants to build collaborative apps, live dashboards, or chat features. It is not a general-purpose message broker; it is tightly coupled to the Supabase ecosystem, though the server itself is open source and can be self-hosted.
How the Server Works: Phoenix Channels and WebSockets
The server is written in Elixir using the Phoenix Framework. Phoenix Channels provide the WebSocket transport layer, and the Realtime server extends that with three distinct channel types. Broadcast sends ephemeral messages from one client to many clients with low latency. Presence uses a CRDT-like mechanism to synchronize shared state across clients, so each client knows who else is online and their state. Postgres Changes listens to the database for insert, update, and delete operations, then forwards those changes to authorized clients. The README notes that the JavaScript client library heavily draws from the Phoenix Channels client, which means the protocol is familiar to anyone who has worked with Phoenix. The server does not guarantee message delivery; this is stated explicitly in the README. That is a fundamental design choice: it prioritizes low latency over reliability, which matters for use cases like cursor positions or typing indicators where dropping a message is acceptable.
Getting It Running: Setup and Configuration Files
The README directs developers to start with DEVELOPERS.md for local setup, which includes `mise` tasks and example workflows. There is no quick start command in the README itself, but the repository provides environment variables documented in ENVS.md. The README also mentions ERROR_CODES.md for operational codes and OBSERVABILITY_METRICS.md for monitoring information. For production deployment, Docker images are available at hub.docker.com/r/supabase/realtime. The README does not give a specific `docker run` command, but the image name is clear. Configuration is done through environment variables, not a config file. The key variables would include database connection settings and JWT secret for authorization, though the exact names are not in the README. You will need to read ENVS.md to get the full list. The setup is not a simple `npm install`; it requires an Elixir environment or a Docker container, plus a Postgres database that meets the compatibility requirements.
Postgres Compatibility: A Real Constraint
The README includes a compatibility table that is crucial for anyone planning to use the Postgres Changes feature. It states that Postgres versions below 14 are not officially supported. For 14.x, it requires superuser access because `log_min_messages` can only be set by a superuser, and on versions <= 14.5, calling `realtime.broadcast_changes(...)` from a trigger via `PERFORM` is unsupported. For 15.x versions before 15.14.1.018, there is a missing `supautils.policy_grants` on `realtime.subscription`. For 15.x >= 15.14.1.018, 16.x, and 17.x, superuser is only needed to run migrations, and tenant grants do not require superuser. This means the version of Postgres you run is not a minor detail; it determines whether you need superuser privileges for normal operation. If you are on a managed Postgres service that does not grant superuser, you may be unable to use Postgres Changes at all on older versions. This is a genuine limitation that can block adoption.
The No-Delivery-Guarantee Trade-off
The README states plainly: 'The server does not guarantee that every message will be delivered to your clients.' This is a significant caveat. For broadcast messages, this means a client could miss a message if the connection drops or the server is under load. For presence, the state is eventually consistent, so there may be a window where a client's presence is stale. For Postgres Changes, the README does not explicitly say whether changes are guaranteed, but the overall statement applies to the server's messaging. This design is typical for real-time systems that favor speed over reliability, but it makes Supabase Realtime the wrong tool for applications that require exactly-once delivery, such as financial transactions or order processing. You must build your own retry or acknowledgment mechanism if you need reliable delivery. The README gives no guidance on how to handle missed messages, so you are on your own.
Alternative: Phoenix Channels Directly
A direct alternative is to build your own Phoenix Channels server using the Phoenix Framework itself. Supabase Realtime is built on Phoenix, and the README credits Phoenix as the framework. If you need full control over message delivery guarantees, custom authorization, or a different database, you could write a Phoenix app with your own channels. The difference in approach is that Phoenix gives you the raw WebSocket and channel primitives, but you must implement the broadcast, presence, and Postgres change logic yourself. Supabase Realtime provides these as ready-made features, but with the Supabase ecosystem's assumptions. The trade-off is development time versus flexibility. If you are not already using Supabase, using Phoenix directly might be simpler because you avoid the compatibility requirements and the dependency on supabase/postgres. However, you would lose the integration with Supabase's auth and database policies.
Maintenance, Upgrades, and License
The repository is under active development, with recent releases in August 2026, and the README says the codebase is 'under heavy development' and documentation is 'constantly evolving.' This means you should expect frequent changes and potential breaking changes. You can watch releases to get notified. The license is Apache-2.0, which is permissive and allows commercial use, modification, and redistribution, with the requirement to include the original copyright notice. There is no mention of a separate enterprise license. The maintenance cost is on you if you self-host: you must keep up with releases, monitor the server using the metrics documented in OBSERVABILITY_METRICS.md, and handle error codes from ERROR_CODES.md. The README does not provide a migration guide for upgrading from v2 to v3, but the v1 code and Docker image are still available. The active release cadence is a double-edged sword: you get bug fixes and new features, but you also need to schedule upgrades.
Editorial conclusion
Adopt Supabase Realtime if you are already on the Supabase platform and need low-latency client-to-client messaging, presence tracking, or Postgres change streaming over WebSockets without building a custom Phoenix channel server. Do not adopt it if you require guaranteed message delivery for every event, or if your Postgres version is below 14.x, since those are unsupported. Before committing, verify your Postgres version matches the compatibility table, confirm you can run the required superuser migrations, and review ENVS.md to set the correct database and JWT configuration for your deployment.
Community notes