NoLag vs Supabase Realtime
Supabase is an all-in-one backend built around Postgres, with authentication, storage, edge functions, and a Realtime feature for broadcasting database changes, presence, and messages over WebSocket. NoLag is standalone realtime messaging: an open-source broker, kraken, that you run yourself, with the same pub/sub foundation and blueprint SDKs for common app patterns.
Short version: if you want a Postgres backend and realtime is one feature alongside it, Supabase is a great fit. If realtime messaging is the core of what you are building, and you do not want it tied to a specific database, NoLag is built for that.
At a glance
| NoLag | Supabase Realtime | |
|---|---|---|
| Core model | Realtime pub/sub over WebSocket | Realtime over WebSocket, coupled to Postgres |
| Database | Database-agnostic, bring your own | Postgres, part of the platform |
| High-level SDKs | Blueprints for chat, notify, feed, dashboards, tracking, sync, and more | Realtime channels: broadcast, presence, Postgres changes |
| Delivery | Presence, acknowledged publishes | Presence, broadcast, change data capture |
| Authentication | Actor tokens with per-topic ACL; short-lived browser JWTs with @nolag/core | Postgres Row Level Security via JWT |
| SDKs | JavaScript/TypeScript (including React Native), Go, Python | Client libraries across several languages |
Where NoLag is different
- Not tied to a database. NoLag is a messaging layer you can put next to any stack, rather than realtime bound to Postgres change feeds.
- A standalone broker. kraken is one Apache-2.0 container and needs no database of its own. Auth comes from a static file, an HTTP endpoint of your own, or the optional @nolag/core library (which keeps its configuration in Postgres).
- Blueprint SDKs. A domain-specific API for chat, notifications, dashboards, tracking, and more, so you skip the plumbing.
Where Supabase is a strong fit
- You want a managed Postgres backend with auth, storage, and functions in one place.
- Your realtime needs are mostly reacting to database changes.
- You are happy to standardise on the Supabase ecosystem.
When to choose NoLag
- Realtime messaging is the core of what you are building, not a feature of your database.
- You want higher-level SDKs to ship common realtime patterns quickly.
- You want realtime messaging that is independent of your database choice.
Try it
Follow the 5-minute quick start, read the self-hosting guide, then look at the high-level SDKs.