Realtime in the Deal Room (and Elsewhere)

Polling-loops on a warehouse tablet are a way to drain the battery and slow the network. The platform uses Supabase Realtime — Postgres changes pushed over WebSocket to subscribed clients — to keep things in sync without polling.

Where it’s wired

The deal room: messages, offers, status transitions push live. The inventory list: a sale by a colleague reflects in your view before they’ve let go of the mouse. The notifications bell: count updates in real time. The auction live page (/auction/[id]/live): bid updates push to all watchers. The receiving session: the QuickGrid intake reflects scans from other operators on the same session in real time.

How it works under the hood

Postgres logical replication exposes change events for selected tables. Supabase Realtime relays them, applying RLS rules (a tenant only receives change events for rows it’s authorized to read). The browser subscribes via WebSocket; on a change event, the relevant React component re-fetches the affected row and rerenders.

Fallback when WebSocket fails

Some networks block WebSocket. The platform’s fallback is short-poll — the same components query at a slow interval (every 30 seconds) when realtime is unavailable. The user sees slightly delayed updates rather than no updates. The fallback is automatic; users don’t have to know about it.

What isn’t realtime

Reports and analytics aren’t realtime — they’re aggregated nightly or on-demand. The pipeline view shows live status but the SLA aggregation refreshes hourly. The principle: real-time where the user is making decisions in the moment, batch-refreshed where the data is for analysis.