// the find
supabase/realtime
Broadcast, Presence, and Postgres Changes via WebSockets
Supabase Realtime is the WebSocket server powering Supabase's live data features: Broadcast (ephemeral pub/sub), Presence (shared state synchronization), and Postgres Changes (CDC via logical replication). It's a multi-tenant Phoenix application designed to run as managed infrastructure — you're most likely consuming it through the Supabase JS client, not self-hosting it.
The multi-tenant architecture is well thought out — each tenant gets isolated connection pooling, rate limiting, and per-tenant Postgres replication connections rather than sharing a single slot. The migration trail in lib/realtime/tenants/repo/migrations/ goes back to 2021 and is still actively maintained (migrations landed as recently as this week), which is a good signal for production stability. RLS integration for Postgres Changes is a genuine differentiator — subscribe filters respect row-level security policies so clients only receive rows they're authorized to see, not a common feature in CDC tools. The observability story is solid: PromEx plugins cover channels, tenants, distributed metrics, and OS-level stats, and there's a built-in LiveDashboard with SQL inspector and recon trace for production debugging.
The README explicitly states message delivery is not guaranteed — for Broadcast this is fine, but for Postgres Changes this is a real gap if your use case requires exactly-once processing; there's no dead letter queue or replay mechanism beyond the messages table partitioning added in late 2024. Self-hosting is technically possible but clearly not the primary path — the setup involves Fly.io configs, supabase-specific Postgres roles (supabase_realtime_admin), and a supautils dependency that most people won't have, making it non-trivial outside the managed offering. The multi-tenant model means the API surface expects a JWT per connection with tenant context embedded, which is an awkward fit if you want to use this as a standalone pub/sub layer without the Supabase auth stack. Postgres 14 support is degraded and requires superuser, which is a gotcha if you're running older managed Postgres.