The best Firebase Realtime Database alternatives in 2026

26 Oct, 2026

Last updated: November 2026

The right alternative to the Firebase Realtime Database depends on how much of your app you're willing to rewrite. Lark is the only wire-compatible replacement, so your existing Firebase SDK code and security rules keep working. Cloud Firestore keeps you on Google Cloud with a document data model and richer queries. Supabase, PocketBase, Appwrite, Convex, and InstantDB are full backends that require a rewrite, each with different trade-offs in SQL, self-hosting, and realtime sync.

If you search for "Firebase alternatives," almost every listicle you'll find is really answering a broader question: what should I use as my all-in-one backend instead of Google's Firebase suite?

That's a useful question if you're starting a brand new app from an empty folder. It's much less useful if you specifically use (or want the programming model of) the Firebase Realtime Database (RTDB) -- a low-latency JSON tree where clients subscribe to paths, get delta updates in milliseconds, and clean up their state with onDisconnect().

Full disclosure up front: we make Lark, which is an open-source, wire-compatible replacement for the Firebase Realtime Database. We put Lark first on this list only because it is the only drop-in option where you don't have to rewrite your existing Firebase RTDB code. Every other tool below is a genuinely good piece of software that beats both Firebase RTDB and Lark in specific areas, and we'll be straightforward about where each one shines and where it falls short.

How we evaluated each option

Because "realtime database" gets stretched to mean everything from a 20Hz multiplayer game server to a webhook that fires once a minute, we evaluated each alternative against six practical questions:

1. How much of an existing Firebase RTDB application do you have to rewrite to switch?
2. What is the underlying data model (a single JSON tree, document collections, or relational SQL tables)?
3. How does the realtime mechanism actually work under the hood (in-memory tree subscriptions, database WAL replication, Server-Sent Events, or reactive server functions)?
4. Can you self-host it, what license is the server under, and how complicated is the deployment?
5. What is the shape of the cloud pricing (billed by bandwidth and storage, per read/write operation, or tiered compute instances)?
6. How well does it handle high-frequency, fan-out workloads like live cursors, presence, and multiplayer game state?

1. Lark

What it is: Lark is an open-source (AGPL v3) realtime database server written in Rust (on Glommio and Linux io_uring) with a Go edge gateway. It implements the actual Firebase Realtime Database wire protocol, REST API, and security rules language.

Best for: Teams with an existing Firebase Realtime Database app who want to cut their bandwidth/storage bill in half or self-host without rewriting their code, as well as new multiplayer games and collaborative apps that need sub-50ms p99 latency and high-frequency updates.

Migration from Firebase RTDB: Drop-in. Your existing client code using the official Firebase SDKs (Javascript, Android, iOS, Flutter, C++, Unity) keeps working unchanged. You copy your rules.json over, set your Firebase Project ID so Lark can validate your existing Firebase Auth tokens, import your exported JSON, and change databaseURL in your config.

Where it stands out: Beyond wire compatibility, Lark adds volatile paths for high-frequency data (like cursors and player positions) that batch updates in memory with no writes-per-second cap and bill at 1/5th the bandwidth rate on Lark Cloud ($0.10/GB vs. $0.50/GB standard egress, compared to Firebase's $1.00/GB). If you use the native @lark-sh/client JS SDK, you also get WebTransport (QUIC/UDP) support. Self-hosting is just two binaries (lark-edge and lark-server).

Watch out for: Lark is intentionally narrow. It only replaces the Realtime Database -- it does not include its own user management UI, file storage, or serverless functions (most users pair it with Firebase Auth/Storage or their existing backend). And because it uses the same JSON tree model as RTDB, it is not a relational SQL database.

2. Cloud Firestore

What it is: Google's newer, flagship NoSQL document database inside the Firebase platform. Instead of a single JSON tree, data is organised into collections of documents (up to 1 MiB each) and subcollections.

Best for: Teams staying all-in on Google Cloud whose data naturally fits discrete documents and who need compound, indexed queries across multiple fields at once.

Migration from Firebase RTDB: Full schema redesign and code rewrite. Despite sharing the Firebase brand, Firestore has a completely different SDK (firebase/firestore), a different security rules language, and no automated migration tool from RTDB. (We wrote a dedicated breakdown of Firebase Realtime Database vs Firestore if you're weighing this specific move.)

Where it stands out: Querying. Where RTDB and Lark only let you sort or filter on a single key per query (orderByChild), Firestore indexes fields automatically and lets you chain multiple where() and orderBy() clauses without manually denormalizing your data into composite keys. Its per-GB storage price ($0.18/GB-month) is also much lower for large, cold datasets.

Watch out for: Per-operation billing and realtime limits. Firestore bills for every document read, write, and delete, and every time a document updates, each connected listener receives the full document and counts as a billed read. It also lacks server-side onDisconnect() hooks, which is why Google's own documentation still recommends using RTDB alongside Firestore for presence systems and frequent small updates.

3. Supabase

What it is: The largest open-source Firebase alternative in the market, built around a dedicated PostgreSQL database paired with authentication (GoTrue), auto-generated REST/GraphQL APIs (PostgREST), file storage, edge functions, and an Elixir-based Realtime server.

Best for: New applications with relational data that want SQL, foreign keys, joins, and a full open-source backend suite in one place.

Migration from Firebase RTDB: Full rewrite. You redesign your JSON tree into normalized SQL tables, rewrite every client read/write/listener against @supabase/supabase-js, and rewrite your rules.json permissions as SQL Row-Level Security (RLS) policies. (See our full Lark vs Supabase comparison for side-by-side examples.)

Where it stands out: It's real Postgres underneath. You get the entire Postgres ecosystem, including pgvector, PostGIS, SQL views, triggers, and strict relational integrity. Its Realtime layer offers three modes: Broadcast (ephemeral client-to-client messages), Presence, and Postgres Changes (streaming inserts/updates/deletes from the replication log).

Watch out for: If your realtime workload relies on database-backed Postgres Changes with Row-Level Security enabled, Supabase has to evaluate RLS per subscriber on a single replication thread, so high fan-out on frequently updated tables can bottleneck Postgres compute. Self-hosting also requires running a Docker Compose stack of roughly a dozen interconnected services.

4. PocketBase

What it is: An open-source (MIT) backend packed into a single Go binary with an embedded SQLite database (running in WAL mode), built-in user authentication, file storage, an admin dashboard, and realtime record subscriptions over Server-Sent Events (SSE).

Best for: Indie developers, prototypes, internal tools, and small-to-medium self-hosted applications where deploying a single executable on a $5/month VPS is the dream setup.

Migration from Firebase RTDB: Full rewrite. You model your data as flat collections (tables) in PocketBase's admin UI, rewrite your client calls using the PocketBase JS or Dart SDK, and express permissions using PocketBase's collection API rules.

Where it stands out: Operational simplicity. There is nothing else in this list as easy to self-host as PocketBase: download one binary, run ./pocketbase serve, and you have a database, auth, admin UI, and realtime SSE subscriptions running in a few megabytes of RAM.

Watch out for: Because it runs on embedded SQLite in a single process, PocketBase only scales vertically on a single server, and there is no official managed cloud service from the creator. Its realtime layer is built on Server-Sent Events for collection/record changes rather than arbitrary JSON tree paths or high-frequency UDP/WebTransport streams, and the project notes that it is still pre-1.0.

5. Appwrite

What it is: An open-source (BSD-3-Clause) end-to-end Backend-as-a-Service (BaaS) providing document/table databases (backed by MariaDB), authentication, file storage, serverless functions across multiple languages, messaging, and a WebSocket Realtime API.

Best for: Teams who want a comprehensive, self-hostable BaaS with a polished console and broad language SDK support for web, mobile, and server.

Migration from Firebase RTDB: Full rewrite. Data is stored as documents inside collections with defined attribute schemas, permissions are configured per collection or document, and client code uses the Appwrite SDKs to subscribe to realtime channels (like databases.[ID].collections.[ID].documents).

Where it stands out: Breadth of platform features. If what you actually want is an open-source replacement for the entire Firebase console -- auth providers, storage buckets, scheduled functions, push notifications, and document storage -- Appwrite covers all of those in a unified interface, available both self-hosted and on Appwrite Cloud.

Watch out for: Like Supabase, Appwrite's self-hosted setup is a multi-container Docker Compose stack (MariaDB, Redis, multiple worker containers, and Traefik). Its database requires predefined collection attributes rather than a schema-less JSON tree, and its realtime channels broadcast document-level events rather than byte-level path deltas or volatile game-state batches.

6. Convex

What it is: A reactive backend-as-a-service built from the ground up for TypeScript. Instead of subscribing to paths or writing client-side database queries, you write server-side TypeScript query and mutation functions, and Convex automatically tracks what data each query read and pushes updated results to connected clients whenever those rows change.

Best for: Greenfield TypeScript and React teams who want end-to-end type safety, ACID transactions by default, and zero manual cache invalidation.

Migration from Firebase RTDB: Full architectural rewrite. You move from client-driven path reads/writes and rules.json to server-side TypeScript query/mutation functions and a document-relational schema defined in TypeScript.

Where it stands out: Developer ergonomics for TypeScript web apps. Because every read is a deterministic TypeScript function running next to the database and every write is a serializable ACID transaction, you never have to worry about inconsistent client state, race conditions, or writing security rules in a separate DSL. The backend engine is also open source (FSL / Apache 2.0) and can be self-hosted.

Watch out for: Convex's reactive model re-evaluates query functions when underlying table data changes, which is fantastic for collaborative CRUD and SaaS apps, but isn't designed for 20Hz–60Hz fire-and-forget UDP/volatile position streaming. And if you have an existing mobile or game codebase on Firebase RTDB SDKs, moving to Convex means rewriting both your client and server layers in TypeScript.

7. InstantDB

What it is: An open-source (Apache 2.0), client-side reactive database often described as a "modern Firebase." Inspired by Figma's LiveGraph and Facebook's Tao, it stores data as triples on top of Postgres and gives clients a declarative, GraphQL/Datalog-style query language (instaql) with built-in optimistic updates and presence hooks.

Best for: New collaborative web applications (especially React/TypeScript apps) that love Firebase RTDB's client-first, optimistic-UI feel, but wish they had relational links and multi-hop queries without managing SQL on the client.

Migration from Firebase RTDB: Full rewrite. Although the philosophy is very close to Firebase RTDB, the API (db.useQuery, db.transact), the data model (entities and links rather than a single JSON tree), and the permissions language (CEL expressions) are all new.

Where it stands out: It captures the magic of building directly in the client with instant optimistic updates and built-in room presence/cursors, while solving RTDB's classic pain point of joining related entities across a tree.

Watch out for: It's a younger ecosystem focused primarily on Javascript/TypeScript and React/React Native clients, and migrating an existing Firebase RTDB app still requires reshaping your tree into entities and rewriting your client queries and security rules. As of August 2026 it is being sunsetted as a hosting service, although the open-source version remains available on Github.

Comparison summary

Which one should you pick?

If you want a quick rule of thumb based on your starting point:

1. If you have an existing Firebase RTDB app and don't want to rewrite it, pick Lark. It's the only option that speaks the Firebase RTDB protocol and runs your existing rules.json.
2. If you're building a multiplayer game or high-frequency collaborative app (cursors, whiteboards, 20Hz positions), pick Lark for volatile paths, onDisconnect, and WebTransport support.
3. If you want to stay on Google Cloud and need multi-field compound queries on documents, pick Cloud Firestore (and consider keeping RTDB or Lark alongside it if you need cheap presence).
4. If you're starting a new relational app and want SQL, joins, and a full Postgres platform, pick Supabase.
5. If you're building a small self-hosted project and want a single binary on a cheap VPS, pick PocketBase.
6. If you want a self-hosted, all-in-one open-source replacement for the entire Firebase console, pick Appwrite.
7. If you're starting a new TypeScript/React app and want reactive server functions or client-side relational queries, look at Convex.

Frequently asked questions

What is the cheapest Firebase Realtime Database alternative?

If you self-host on your own VPS, open-source options like Lark, PocketBase, Supabase, and Appwrite cost nothing beyond your server bill. Among hosted cloud services for an existing RTDB workload, Lark Cloud starts at $10/month and charges roughly half of Firebase RTDB's storage ($2.50/GB-month vs. $5.00/GB-month) and outbound bandwidth ($0.50/GB vs. $1.00/GB) rates, with volatile bandwidth at $0.10/GB.

Which Firebase Realtime Database alternatives can I self-host?

Lark, Supabase, PocketBase, Appwrite, Convex, and InstantDB all have open-source server code that you can self-host. PocketBase (one Go binary) and Lark (two binaries: lark-edge and lark-server) have the smallest operational footprints. Cloud Firestore is proprietary to Google Cloud and cannot be self-hosted.

Is there a drop-in open-source replacement for Firebase Realtime Database?

Yes. Lark is wire-compatible with the Firebase Realtime Database, meaning you can keep using the official Firebase client SDKs, your existing rules.json security rules, and Firebase Auth while pointing your databaseURL at Lark Cloud or your own self-hosted Lark server.

Does Lark Cloud have a free tier?

Self-hosting the open-source version of Lark is free forever with no limits. On Lark Cloud, plans start at $10/month (which includes 2 GB of storage and 20 GB of outbound bandwidth) and come with a 14-day free trial so you can test your migration before paying anything.

Firebase, Firebase Realtime Database, and Cloud Firestore are trademarks of Google LLC. All other product names and trademarks are the property of their respective owners. Lark is an independent project and is not affiliated with, endorsed by, or sponsored by Google.