NoLag vs Firebase
Firebase is Google's app development platform. Its realtime features, Realtime Database and Firestore, work by syncing documents and firing client listeners when stored data changes, alongside auth, hosting, and cloud functions. NoLag is open-source realtime messaging built on explicit pub/sub, which you run yourself, with blueprint SDKs for common realtime patterns.
Short version: if you want a managed database with data-sync realtime and the wider Google ecosystem, Firebase is a strong fit. If you want an explicit messaging layer with pub/sub and presence that is independent of your database and runs on your own infrastructure, NoLag is built for that.
At a glance
| NoLag | Firebase | |
|---|---|---|
| Core model | Realtime pub/sub over WebSocket | Data sync via database listeners |
| Realtime primitive | Publish and subscribe to topics | Listen to changes on stored documents |
| Database | Database-agnostic, bring your own | Realtime Database or Firestore, part of the platform |
| Hosting | Self-hosted: one kraken container plus your auth | Managed by Google |
| High-level SDKs | Blueprints for chat, notify, feed, dashboards, tracking, and more | Database, auth, functions, messaging services |
| Delivery | Presence, acknowledged publishes | Offline sync, change listeners |
| Authentication | Actor tokens with per-topic ACL; browser JWTs your backend signs with @nolag/core | Security Rules language |
| SDKs | JavaScript/TypeScript (including React Native), Go, Python | Client SDKs across many platforms |
Where NoLag is different
- Messaging, not data sync. NoLag is explicit publish and subscribe over topics, rather than reacting to writes on a database you have to model around.
- Not tied to a database or a vendor. Add realtime to any stack instead of standardising on Realtime Database or Firestore, and run it on your own infrastructure: kraken is Apache-2.0.
- Blueprint SDKs. A domain-specific API for chat, notifications, dashboards, tracking, and more, so you skip the plumbing.
- Actor-based auth instead of a rules language. Permissions attach to a typed actor as per-topic ACL and are enforced at the broker, rather than written in a security-rules DSL. For browsers, with @nolag/core, your backend mints short-lived JWTs signed with a project signing key.
Where Firebase is a strong fit
- You want a managed database with offline sync and the Google ecosystem.
- Your realtime needs map naturally to reacting to stored-data changes.
- You are building mobile or web apps that benefit from the wider Firebase suite.
When to choose NoLag
- You want explicit pub/sub messaging and presence rather than data-sync listeners.
- You want to run realtime on your own infrastructure, with no vendor lock-in.
- You want realtime that is independent of your database choice, across JavaScript, Go, and Python.
Try it
Follow the 5-minute quick start, read the self-hosting guide, then look at the high-level SDKs.