Should You Use Supabase Realtime or Build the Transport?

A real-time feature can look small in a product brief and still create a large infrastructure decision. “Users should see updates immediately” does not yet tell you whether the system needs client-to-client messages, synchronized presence, database change delivery, durable history, regional placement, or a service that somebody on the team must operate.

That distinction matters because Supabase Realtime exposes several different mechanisms, not one universal real-time architecture. Its documentation describes Broadcast for low-latency messages between clients, Presence for tracking and synchronizing user state, and Postgres Changes for listening to database changes in real time. (Supabase Realtime documentation)

The practical question is therefore narrower than “Is Supabase Realtime good?” It is this:

Does the workload fit one of the documented Realtime interaction models, and is the team willing to accept the operational and cost unknowns that still need validation?

This article provides a decision path without pretending that a source excerpt can answer region, availability, pricing, retention, or support questions that it does not document.

Supabase Realtime or your own transport starts with the message contract

Before comparing products, describe the message.

A message can be an ephemeral event, a state update, a database change, or a presence signal. Those are different contracts, even if all of them are casually called “real time.” The contract should answer five questions:

1. Who sends the event?
2. Who receives it?
3. Must it be persisted?
4. What happens if a recipient is disconnected?
5. Is the event authoritative, or is it only a hint that the client may refresh?

The Supabase documentation supports three useful starting points:

• Broadcast is presented for low-latency messages between clients, including messaging, cursor tracking, game events, and custom notifications.
• Presence is presented for tracking and synchronizing user state, such as who is online or active.
• Postgres Changes is presented for listening to database changes in real time. (Supabase Realtime documentation)

These descriptions are capability statements, not a complete reliability or cost model. They help classify the workload, but they do not establish delivery guarantees, retention behavior, regional latency, support terms, or a production service-level commitment.

That boundary is important for engineering leaders and budget owners. A documented feature is not automatically a documented operating model.

Choose Broadcast when the event is transient

Broadcast is the clearest candidate when clients need to exchange a low-latency event and the event does not itself represent the durable business record.

Examples in the supplied documentation include chat messaging, cursor tracking, game events, and custom notifications. Those examples indicate a communication pattern: one client or application component emits an event, and other connected clients react.

The decision becomes unsafe when the product quietly expects the transport to become the system of record. If a chat message, approval, payment state, or audit event must survive disconnects and support later retrieval, the team should separately define where that durable state lives. The supplied Realtime documentation does not, by itself, establish persistence or retention semantics for Broadcast.

A useful architecture decision is:

Use Broadcast for transient interaction signals; write business-critical state to an explicitly chosen durable store before or alongside notifying clients.

That keeps the transport’s role narrow. It also makes recovery more understandable: after reconnecting, a client can obtain authoritative state from the application’s normal read path instead of assuming that every missed transient event can be reconstructed from the transport.

That recovery pattern is a design recommendation, not a verified Supabase behavior. Validate it against the actual application and documentation before implementation.

Choose Presence when the product needs shared user state

Presence addresses a different problem. The documentation describes it as tracking and synchronizing user state, with “who’s online” and active participants as examples. (Supabase Realtime documentation)

This is useful for collaborative tools, participant lists, and other interfaces where the current state of connected users matters. The key word is current. A presence signal should not automatically be treated as an audit record, attendance history, or proof that a person completed an action.

For a Presence-based feature, define:

• the state being shared;
• the meaning of connected, active, idle, and disconnected;
• whether stale state is acceptable;
• what the interface does when presence is unavailable; and
• whether any user action must be recorded elsewhere.

The last point prevents a common category error. “Alex is currently active” and “Alex approved the document at a recorded time” are not interchangeable facts. One is shared live state; the other is a durable business event requiring a different contract.

Choose Postgres Changes when database changes are the trigger

Postgres Changes is the relevant model when the database change itself is the event that clients need to observe. The documentation explicitly lists listening to database changes in real time as a Realtime capability. (Supabase Realtime documentation)

This can simplify the conceptual path from a committed data change to a client update. It can also create coupling between database activity and client behavior. Before choosing it, clarify:

• which tables or records are eligible;
• whether every change should be visible to every subscriber;
• whether a client receives enough information to render safely;
• how authorization is evaluated; and
• what the client does after missing or rejecting an update.

The supplied source does not provide the answers to those questions. They belong in the implementation review, not in an assumed architecture diagram.

A conservative rule is to make the database the authority and the real-time notification the delivery mechanism. If a client receives an update it cannot trust or apply, it should have a defined path to obtain current state. Again, this is an architectural recommendation, not a claim about an undocumented provider guarantee.

Cost and operations: write the assumptions before the estimate

No pricing, quota, region, retention, or support values are supplied in the source material. Therefore, a responsible decision document should not attach a number to Supabase Realtime or to a self-managed alternative.

Instead, write the cost model inputs first:

Label each future number correctly:

• List price: a provider-published unit price, with provider, plan, region, unit, and source date.
• Estimate: a scenario using declared workload assumptions.
• Calculation: the formula connecting usage to the estimate.
• Observed result: a measurement from the running system, with its collection period and environment.

Do not substitute a dashboard observation for a published price, or a published feature description for a service-level guarantee. This separation is especially important when comparing a managed service with self-managed infrastructure, because the latter also carries engineering time, on-call responsibility, upgrades, monitoring, and recovery work that may not appear on a hosting invoice.

A small operational checklist for the first reliable version

The smallest reliable solution is not the one with the fewest components. It is the one whose failure behavior the team can explain.

Use this checklist before committing to either path:

Workload and boundaries

• Classify each event as transient interaction, shared presence state, database change, or durable business record.
• Name the authoritative store for every business-critical fact.
• State whether clients may be disconnected and what they do when they return.

Failure modes

• A client loses its connection during an update.
• A presence signal becomes stale.
• A database change reaches a client that cannot apply it.
• A transient event is mistaken for durable history.
• The real-time path is unavailable while the core application remains available.

For every failure, document the user-visible result and the recovery path. “Retry” is not a recovery design unless the team knows what can be safely repeated and how duplicates are handled.

Observability

Track enough information to distinguish an application problem from a connection problem: connection state, event type, rejected or failed application updates, recovery attempts, and the age of any state shown as current. The exact metrics and thresholds remain implementation decisions; the source does not provide them.

Delivery and ownership

Record who owns configuration, access control, incident response, upgrades, and provider escalation. If the team builds the transport, those responsibilities are explicit. If the team uses a managed capability, they do not disappear; they change shape and must be validated against the selected plan and support model.

A decision path for teams with limited operational capacity

Use Supabase Realtime as the initial candidate when all of the following are true:

1. The workload maps clearly to Broadcast, Presence, or Postgres Changes.
2. The team can keep authoritative business state outside the transient communication contract where necessary.
3. The required region, availability, storage, egress, retention, and support assumptions can be verified.
4. The user experience has a defined degraded and recovery path.

Investigate a self-managed transport when the workload or constraints demand behavior that the supplied Realtime description does not establish, or when the team needs direct control over an unverified requirement. That is not an argument for building infrastructure by default. It is an argument for identifying the requirement first.

The decision should end with a short record: workload classification, chosen mechanism, authoritative state, assumptions, unresolved questions, failure behavior, owner, and validation date. This is more reusable than a generic architecture diagram because it preserves the reasoning behind the choice.

Conclusion: make the transport smaller than the product promise

Supabase Realtime offers three documented ways to think about live application behavior: Broadcast, Presence, and Postgres Changes. The right choice depends less on the label “real time” than on whether the message is transient, shared state, or a database change—and whether the team has defined what happens when delivery is late, incomplete, or unavailable.

Start with the message contract. Separate transport from durable truth. Put workload, region, availability, storage, egress, retention, and support assumptions on the page before discussing cost. Then choose the smallest solution whose failure and recovery behavior you can operate.

If you are weighing a real-time feature, infrastructure choice, or operational review, I can help turn the open assumptions into a decision record your product and engineering teams can use.

Official sources

• Supabase Realtime documentation
• Inside Java
• Python 3.16.0 alpha 2 announcement