Kuzzle

Open-source backend infrastructure, honestly reviewed. Aimed at IoT teams and mobile developers who want real-time data without building the plumbing from scratch.

TL;DR

• What it is: Open-source (Apache 2.0) backend-as-a-service with built-in real-time pub/sub, multi-protocol API (HTTP, WebSocket, MQTT), Elasticsearch-powered search, and an extensible Node.js framework — primarily aimed at IoT and mobile applications [README][website].
• Who it’s for: Development teams building IoT platforms, connected-device applications, or real-time mobile/web apps who want a self-hosted alternative to Firebase without vendor lock-in to Google Cloud [1][5].
• Cost savings: Firebase’s Blaze plan charges per read/write/delete at scale and has no self-hosted option. Kuzzle is free to self-host under Apache 2.0; cloud hosting reportedly starts under $90/month [5].
• Key strength: MQTT support out of the box — rare in the Firebase-alternative category — combined with a multi-protocol API that lets the same backend serve web clients over WebSocket and IoT sensors over MQTT simultaneously [README][website].
• Key weakness: 1,639 GitHub stars is modest by modern BaaS standards. The project has a French company behind it (the homepage occasionally slips into French), limited English-language community content, and most third-party coverage treats it as a list item rather than a serious contender worth deep analysis [1][2].

---

What is Kuzzle

Kuzzle is a self-hostable backend that ships with the features most applications need before they write a single line of business logic: a document database (via Elasticsearch), user authentication with RBAC, real-time pub/sub, and a multi-protocol API layer. The GitHub README describes it as “Open-source Back-end, self-hostable & ready to use - Real-time, storage, advanced search - Web, Apps, Mobile, IoT” [README].

The pitch is reasonable: instead of assembling Elasticsearch, Redis, an auth layer, a WebSocket server, and a REST API from scratch, Kuzzle wires them together into one deployable unit and wraps them in a TypeScript framework you extend with your own controllers and plugins. The README’s hello-world example registers a new API action in roughly ten lines of TypeScript:

app.controller.register('greeting', {
  actions: {
    sayHello: {
      handler: async request => `Hello, ${request.input.args.name}`
    }
  }
});

That controller is then immediately reachable over HTTP, WebSocket, and MQTT without any additional wiring [README].

Where Kuzzle differentiates from the broader Firebase-alternative category is its explicit IoT focus. MQTT — the lightweight messaging protocol that battery-powered sensors and industrial equipment actually speak — is a first-class protocol in Kuzzle’s API layer, not an afterthought plugin. The company has a separate product, Kuzzle IoT, aimed at industrial deployments, and its customer case studies include SNCF (French national rail) connecting station equipment and La Poste (French postal service) optimizing parcel delivery logistics [website]. This is not a tool primarily designed for a startup’s CRUD app; it’s oriented toward environments where devices outnumber users.

The project has 1,639 GitHub stars and is licensed Apache 2.0 — genuinely permissive, with no commercial redistribution restrictions [README][merged profile].

---

Why people choose it

The third-party coverage of Kuzzle is thin. None of the articles we found are dedicated Kuzzle reviews; they’re Firebase alternatives roundups that include Kuzzle as one item in a numbered list [1][2][3][4][5]. That’s a signal in itself: Kuzzle hasn’t broken through to the level of community depth that Supabase or n8n commands. But within those roundups, the consistent reasons people reach for it are:

The open-source angle versus Firebase’s lock-in. The SaaSHub comparison article [2] frames Kuzzle as: “Unlike Firebase, which relies on NoSQL database, isn’t open source, and locks you into Google frameworks, Kuzzle offers Node.js and other databases. Plus, Kuzzle is open source and allows you to develop your custom business and other features for free.” The Apache 2.0 license means you can fork, embed in products, and deploy on your own infrastructure with no commercial agreement required.

Multi-protocol API in one deployment. The headline capability that distinguishes Kuzzle from most Firebase alternatives is MQTT support at the protocol layer [README][website][3]. If you’re building an application where mobile app users communicate over WebSocket and sensor hardware communicates over MQTT, Kuzzle handles both through the same backend and the same pub/sub system. Other open-source backends make you stitch that together yourself.

Real-time as a core primitive, not a bolt-on. Kuzzle ships with what it calls the Koncorde real-time engine — a pub/sub layer that can push database change notifications to subscribed clients [README][website]. A client subscribes to a filter, and when any document matching that filter is created, updated, or deleted in Elasticsearch, the subscriber gets notified. This is the Firebase Realtime Database pattern, but running on a stack you control.

The IoT/industrial positioning. REGENDUS [5] puts it simply: “Today, this platform offers two products that provide better functions. The first product is specifically designed for IoT and the other is to accommodate the development of apps and websites.” If your use case is genuinely device-centric — ingesting sensor data, managing device state, distributing commands to equipment — Kuzzle’s architecture maps to that problem better than a generic REST API backend.

What the articles don’t say much about: user experience, documentation quality, how painful the setup is, or how active the community is in practice. Most coverage is 2021–2022 vintage. For a project with 1,639 stars, community momentum is a legitimate concern.

---

Features

Based on the README and website:

Data and storage:

• Document storage via Elasticsearch — full JSON document persistence with versioning [README]
• CRUD queries through the standard Kuzzle API [website]
• Advanced search with Elasticsearch’s full query DSL [README][website]
• Real-time pub/sub subscriptions on collections and documents [README]

API layer:

• HTTP, WebSocket, and MQTT protocols — all exposing the same API [README][website]
• Standardized request/response format across all protocols [README]
• Built-in REST API at port 7512 by default [README]

Authentication and security:

• RBAC (role-based access control) for data and API access [README][website]
• 500+ authentication strategies via Passport.js (OAuth2, OpenID, local, etc.) [website]
• Per-collection and per-document permission rules [README]

Real-time engine (Koncorde):

• Client-side subscription filters: subscribe only to documents matching a specific condition [README]
• Pub/sub topics independent of the document model [README]
• Database change notifications pushed to subscribers automatically [README]

Extensibility framework:

• TypeScript-first plugin API [README]
• Custom API controllers registered in code, not config [README]
• Plugin system for authentication strategies, storage backends, and protocol handlers [README]

SDKs:

• JavaScript/TypeScript (Web, Node.js)
• Kotlin (Android)
• Dart (Flutter)
• iOS (Swift/ObjC) [website]

DevOps:

• Docker Compose deployment [README]
• Kourou CLI tool for scaffolding and management [README]
• Prometheus/ELK integration mentioned on the website [website]
• Cluster mode for multi-node horizontal scaling [website]

---

Pricing: SaaS vs self-hosted math

This section is limited by what’s publicly documented. Kuzzle’s pricing page is not fully scraped in the available data.

Self-hosted (open source):

• Software license: $0 (Apache 2.0) [README]
• Infrastructure: You run Elasticsearch, Redis, and the Kuzzle Node.js process. Elasticsearch is the heavyweight here — expect a minimum of 4GB RAM total, which means a $12–$20/month VPS at minimum, more like $20–$40 for a comfortable production setup on Hetzner or Contabo.

Kuzzle Cloud:

• REGENDUS [5] mentions cloud hosting “starts at less than USD 90 per month.” No pricing page breakdown is available in the data reviewed.
• The official website advertises “Cloud & On Premise” deployment but routes to a demo request rather than a self-serve pricing table [website].

Firebase for comparison:

• Spark (free): 1GB Firestore storage, 50K reads/day, 20K writes/day
• Blaze (pay-as-you-go): $0.06/100K reads, $0.18/100K writes, $0.02/100K deletes — charges compound fast at IoT sensor data volumes
• Realtime Database add-on charges separately

Concrete IoT math: A modest IoT deployment writing 1,000 sensor readings per hour (24K writes/day) stays within Firebase Spark’s free tier. At 10x that — 10,000 readings/hour — you’re writing 240K records/day. At Firebase Blaze pricing that’s roughly $13/month in writes alone, not counting reads, storage, or network. Scale to 100K sensor readings/hour and you’re looking at $130+/month just in write costs, growing linearly.

Self-hosted Kuzzle on a $25 Hetzner server has no per-operation costs. The math favors self-hosting aggressively at IoT data volumes. The trade-off is you’re maintaining Elasticsearch, which is not trivial.

---

Deployment reality check

Kuzzle runs on Docker Compose with Elasticsearch and Redis as required dependencies [README]. The Kourou CLI scaffolds a new project in one command:

kourou app:scaffold playground
cd playground && docker compose up -d

What that hides: Elasticsearch is the expensive part of this stack. It requires Java heap configuration, adequate RAM (minimum 2GB just for Elasticsearch, more in production), and careful index management. If you’ve never run Elasticsearch before, budget time to understand heap sizing, shard counts, and the occasional JVM GC pause. Redis is comparatively simple. The Kuzzle Node.js process itself is lightweight.

What you actually need:

• A Linux VPS with at least 4GB RAM (Elasticsearch alone wants 2GB minimum heap)
• Docker and docker-compose
• A reverse proxy (nginx, Caddy) for HTTPS
• An SMTP provider if you want email-based auth flows
• Familiarity with Elasticsearch index management if you’re going beyond basic CRUD

What can go sideways:

• Elasticsearch cluster management is a specialized skill. Running a single-node Elasticsearch instance in production is fine for small deployments but lacks redundancy.
• The project’s English-language documentation is functional but thinner than Supabase or Appwrite. Some guides and community posts are in French, reflecting the French company behind it.
• The cluster mode (multiple Kuzzle nodes) is available but requires additional coordination work beyond the default single-node Docker Compose setup [website].
• No dedicated third-party guides or “Kuzzle on Hetzner in 30 minutes” tutorials found in research — the community content footprint is small compared to alternatives.

Realistic time estimate for a developer familiar with Docker: 1–2 hours to a working local instance. A production deployment with proper SSL, backup strategy, and Elasticsearch tuning: a full day if you know what you’re doing, several days if Elasticsearch is new to you.

---

Pros and Cons

Pros

• Apache 2.0 license. No commercial redistribution restrictions, no “Fair-code” surprises. Fork it, embed it, resell it [README].
• MQTT as a first-class protocol. Rare in the Firebase-alternative space. If you’re building for IoT hardware, this is the single strongest reason to choose Kuzzle over Supabase, Appwrite, or Parse [README][website].
• Multi-protocol from day one. HTTP, WebSocket, and MQTT share the same API surface. One backend serves your web dashboard, mobile app, and sensor hardware simultaneously [README][website].
• Koncorde real-time engine. Database change notifications pushed to subscribers without polling — the Firebase Realtime Database experience on your own infrastructure [README].
• 500+ authentication strategies. Passport.js integration means OAuth2, OpenID, SAML, and dozens of social providers work without custom code [website].
• No per-operation costs at scale. For IoT workloads with millions of sensor writes, flat infrastructure costs beat Firebase’s per-operation billing significantly.
• Production-proven in enterprise IoT. Customer cases include SNCF and La Poste, suggesting the platform can handle real industrial load [website].

Cons

• Elasticsearch dependency is a burden. Every Kuzzle deployment drags in Elasticsearch — a complex, memory-hungry Java application. If your use case is modest, you’re over-engineering. If it’s large, you need dedicated Elasticsearch expertise [README].
• Small community. 1,639 GitHub stars is genuinely low for a backend platform in 2026. Finding answers on Stack Overflow or Reddit to Kuzzle-specific problems is harder than with Supabase or Parse [merged profile][1].
• French-company weight. The website partially renders in French, documentation occasionally has gaps in English, and community resources skew toward French-speaking contributors. Not a dealbreaker, but friction for a primarily English-speaking team [website].
• Limited third-party review depth. No serious independent review in recent research — only roundup list entries [1][2][3][4][5]. This makes it hard to find real-world war stories about production failures, scaling limits, or upgrade pain.
• Cloud pricing opacity. The managed cloud tier doesn’t show a pricing table publicly — you’re routed to a demo request [website]. For founders evaluating costs, this is annoying.
• Niche positioning can become a trap. If you’re not building IoT or heavily real-time applications, Kuzzle’s Elasticsearch + Redis + Kuzzle stack is heavier than necessary. Supabase (PostgreSQL-backed) or Appwrite are simpler for standard CRUD apps.
• No publicly documented SLAs or Trustpilot-equivalent community feedback. Can’t assess support quality from third-party data.

---

Who should use this / who shouldn’t

Use Kuzzle if:

• You’re building a platform that needs to ingest data from IoT devices over MQTT and serve that data to web/mobile clients over WebSocket — simultaneously, from the same backend.
• You want a genuinely permissive open-source license (Apache 2.0) with no commercial restrictions.
• Your team includes at least one person comfortable operating Elasticsearch in production.
• You’re doing enough writes/reads that Firebase’s per-operation billing would become painful — high-frequency sensor data is the clearest case.
• You want real-time database change notifications pushed to clients as a built-in feature, not a custom implementation.

Skip it (use Supabase instead) if:

• You’re building a standard web or mobile app with CRUD requirements and optional real-time features.
• You want PostgreSQL (relational data with joins, foreign keys, transactions) instead of document-oriented JSON storage.
• You want a large English-language community, extensive tutorials, and a polished managed cloud option.
• Your team has no Elasticsearch experience.

Skip it (use Appwrite instead) if:

• You want a Firebase-style BaaS with file storage, push notifications, and functions in one package.
• You prioritize ease of setup over advanced search and MQTT support.
• You want a rapidly growing community (Appwrite has 47K+ GitHub stars) with more beginner resources.

Skip it (use Firebase itself) if:

• You need Google’s global CDN and infrastructure without managing any servers.
• Your data volumes are low enough that Firebase’s free tier covers you indefinitely.
• Your team is primarily mobile developers already fluent in the Firebase SDK.

Skip it (consider Parse Server instead) if:

• You want a simpler, more established open-source BaaS with broader community documentation and hosting options.

---

Alternatives worth considering

From the SaaSHub comparison data and broader context:

• Supabase — the most serious Firebase alternative in 2026. PostgreSQL-backed, real-time via Postgres replication, 70K+ GitHub stars, excellent documentation, managed cloud with a generous free tier. The obvious choice for non-IoT use cases [1].
• Firebase — the incumbent. Zero setup, Google infrastructure, the widest mobile SDK support. Loses on lock-in and per-operation costs at scale.
• Appwrite — closer to Kuzzle’s BaaS positioning than Supabase. Ships with auth, storage, functions, and a database in one Docker deployment. 47K+ GitHub stars, Apache 2.0, more active community than Kuzzle [1].
• Parse Server — older, more established open-source BaaS. Simpler stack (MongoDB or PostgreSQL), well-documented, large community. Less real-time capability than Kuzzle [1][2].
• Back4App — managed Parse hosting, freemium, easier than self-hosting but still closed infrastructure [1][2].
• PocketBase — single-binary backend with SQLite, auth, and file storage. Drastically simpler to deploy than Kuzzle. No IoT/MQTT support, but for simple apps it’s hard to beat the operational simplicity.

For IoT specifically, there’s no clean open-source competitor that replicates Kuzzle’s multi-protocol API with MQTT support in one package. The alternatives involve assembling components: an MQTT broker (Mosquitto or EMQX), a time-series database (InfluxDB or TimescaleDB), and a REST API layer separately.

---

Bottom line

Kuzzle is a focused tool solving a specific problem: a self-hosted backend that speaks HTTP, WebSocket, and MQTT from the same API surface, with Elasticsearch-powered search and real-time subscriptions built in. For that problem — IoT platforms, connected-device dashboards, real-time industrial applications — it’s a coherent solution with a permissive license and real enterprise production history. The cost math versus Firebase at high write volumes is compelling.

The honest caveats: the community is small, the English documentation has gaps, and operating Elasticsearch is a non-trivial commitment. If your project is a standard web or mobile app with no IoT angle, Kuzzle’s stack is heavier than necessary — Supabase or Appwrite will serve you better. If you’re genuinely building for IoT, Kuzzle deserves a hard look, but budget extra time for infrastructure work that Supabase users take for granted.

If the Elasticsearch operations piece is the blocker, that’s the kind of deployment infrastructure upready.dev handles for clients — one-time setup, you own the stack.

---

Sources

1. SaaSHub — Kuzzle Alternatives & Competitors (community votes and product comparisons). https://www.saashub.com/kuzzle-alternatives
2. SaaSHub — 10 Best Open Source Firebase Alternatives (summarizing rigorousthemes.com article, 2021). https://www.saashub.com/alternatives/post-rigorousthemes-2021-06-30-10-best-open-source-firebase-alternatives
3. TopAlter.com — Best Hoodie Alternatives (includes Kuzzle feature listing). https://topalter.com/best-hoodie-alternatives
4. HubTech — What is Firebase? Top 9 Alternatives of Firebase In 2021. https://www.hubtechblog.com/firebase-alternatives/
5. REGENDUS — 15 Best Firebase Alternatives & Competitors (Deniz, includes Kuzzle entry with pricing mention). https://www.regendus.com/best-firebase-alternatives/

Primary sources:

• GitHub repository and README: https://github.com/kuzzleio/kuzzle (1,639 stars, Apache-2.0 license)
• Official website: https://kuzzle.io/kuzzle-backend
• Official documentation: https://docs.kuzzle.io/core/2/guides/introduction/what-is-kuzzle/