Lark: the open-source Firebase Realtime Database alternative

26 Aug, 2026

Last updated: November 2026

Lark is an open-source (AGPL v3) realtime database that speaks the Firebase Realtime Database wire protocol. Existing apps keep using the official Firebase SDKs, security rules, and Firebase Auth. You change the databaseURL, import your JSON, and you're running, either self-hosted for free or on Lark Cloud starting at $10/month.

When people search for a "Firebase alternative," almost every result they find is really an alternative to Firebase as a whole: a full backend platform with its own database engine, its own client libraries, and its own permission model. If you're starting a brand new project from scratch, those are great options to look at.

If you already have a working application built on the Firebase Realtime Database (RTDB), though, "switch your whole backend and rewrite your data layer" is a tough sell. I built Lark because I wanted a third option: a server that is open source and fast, but speaks the exact same protocol as the Realtime Database so you don't have to rewrite your app to leave.

Here's a straightforward breakdown of how Lark works, where it matches Firebase RTDB, where it differs, and when you should (or shouldn't) use it.

What is a "drop-in" Firebase Realtime Database alternative?

A general Firebase alternative replaces Google's stack with a different stack -- usually Postgres or a document store -- which means redesigning your JSON tree into tables or collections, replacing every ref(), onValue(), and transaction() call in your codebase, and rewriting your security rules in a new language.

A drop-in replacement for the Realtime Database replaces only the database server while keeping the client contract intact:

1. Your client code continues to import and call the official Firebase SDKs (firebase/database in Javascript, or the Android, iOS, Flutter, C++, and Unity SDKs).
2. Your data stays a single JSON tree addressed by paths.
3. Your existing Firebase RTDB security rules (rules.json) run unmodified.
4. Your users stay on Firebase Auth, and Lark validates the same ID tokens directly.

As far as I know, Lark is currently the only open-source project that takes this wire-compatible approach for the Realtime Database.

Why do teams look for an alternative to Firebase RTDB?

I was one of the earliest adopters of the Realtime Database and built applications with millions of users on top of it. The programming model is still one of my favourite ways to build collaborative software, but teams usually start looking for an exit for a handful of practical reasons.

The most common one is bandwidth and storage cost at scale. Firebase RTDB on the Blaze plan bills $1.00 per GB of downloaded data and $5.00 per GB-month of storage. In a realtime app where one write fans out to dozens or hundreds of connected listeners, outbound bandwidth becomes the dominant line item on the bill very quickly.

The second is vendor lock-in. You can't read the Firebase server source code, you can't host it on your own hardware, and you can't tune or fix how it behaves under your specific workload. And within Google's own lineup, most new feature development and marketing attention has shifted toward Cloud Firestore, leaving long-time RTDB teams wondering where the product fits in the long run.

Finally, there are the limits on high-frequency updates. RTDB wasn't designed for 20Hz cursor positions, player movement, or live telemetry. Every tiny update goes through the full persistence and rules pipeline and is billed at standard bandwidth rates, and each database is capped at roughly 1,000 writes per second.

How does Lark stay compatible with Firebase?

Lark implements the actual WebSocket and long-polling wire protocol that the Firebase Realtime Database SDKs speak, along with the HTTP REST API (/.json endpoints, query parameters, ETags, and Server-Sent Events streaming).

When a Firebase SDK connects to Lark, it sends the same JSON frames for reads (once), writes (set, update, remove, push), live subscriptions (value, child_added, child_changed, child_removed, child_moved), queries (orderByChild, orderByKey, orderByValue, orderByPriority, limitToFirst, limitToLast, startAt, endAt, equalTo), transactions, and onDisconnect handlers.

Matching the documented API is only half the job. Over the years, production Firebase apps have come to rely on a lot of undocumented quirks: how sparse integer-keyed objects turn into arrays on read, how mixed-type values sort against each other, and how Javascript type coercion behaves inside .validate security rules. (I wrote a whole post about these in Firebase Gotchas.)

To make sure we don't break those expectations, we test Lark by cloning firebase-js-sdk and running Google's own @firebase/database-compat mocha test suite, unmodified, against a live Lark server, alongside our own REST conformance and differential model test suites.

What works differently?

No two servers are identical in every operational detail, and it's better to know the differences up front before you try a migration.

First, you point your databaseURL at https://your-project-id.larkdb.net (or your own domain if you self-host) instead of firebaseio.com.

Second, the Firebase CLI command firebase deploy --only database:rules talks to Google's management API, so it won't deploy rules to Lark. Instead, you paste your rules into the Lark dashboard or deploy them from your terminal and CI pipelines with the Lark CLI (lark rules set -f rules.json).

Third, while .info/connected works as expected for tracking connection state and ServerValue.TIMESTAMP works for server-side timestamps, .info/serverTimeOffset is not supported on the Firebase protocol path (it is supported natively if you use the Lark JS SDK).

We keep a complete, up-to-date list on the compatibility notes page in the documentation.

How do I migrate from Firebase RTDB to Lark?

Because your application code and rules stay the same, a migration is mostly a configuration and data-import exercise. The full walkthrough is in the migration guide, and the steps look like this:

1. Create a project in the Lark dashboard (or on your self-hosted instance) and note your project ID.
2. Decide on your database layout. You can keep everything in one database just like Firebase, or use database routing to automatically split path prefixes (like /rooms/$roomId) into isolated databases on the server.
3. If you use Firebase Auth, paste your Firebase Project ID into your Lark project settings so Lark can verify your users' existing JWTs.
4. Export your security rules from the Firebase console and paste them into Lark's rules editor (or push them with lark rules set).
5. Export your data from Firebase as JSON using the Firebase console or firebase database:get / > backup.json.
6. Import that JSON file into Lark through the dashboard's Import tool or the REST API.
7. Change databaseURL in your app config. This is the only code change required:

const firebaseConfig = {
  apiKey: "...",
  authDomain: "your-app.firebaseapp.com",
- databaseURL: "https://your-app-default-rtdb.firebaseio.com",
+ databaseURL: "https://your-lark-project.larkdb.net",
  projectId: "your-app",
};

8. Point your staging environment at Lark first, run your test suite and click through your app, and then cut production traffic over when you're happy with it.

If you want to see a concrete example before touching your own codebase, check out examples/firebase-quickstart in our GitHub repo, which runs Google's own sample social-blogging app against Lark with just the config URL changed.

How much does Lark cost compared to Firebase RTDB?

If you self-host the open-source version of Lark on your own hardware or VPS, there are no licensing fees or usage limits from us at all -- you just pay your hosting provider for the server.

If you use Lark Cloud, our hosted service is priced at roughly half of Firebase's metered rates, with a flat $10/month base plan that includes your first 2 GB of storage and 20 GB of outbound bandwidth.

To put those numbers into a concrete example: say you run a collaborative web app with 20 GB of stored data and 250 GB of monthly outbound bandwidth. On Firebase RTDB, 20 GB of storage costs $100 and 250 GB of bandwidth costs $250, for a monthly total of $350/month (after negligible Spark free-tier offsets). On Lark Cloud, the $10 base plan covers the first 2 GB of storage and 20 GB of bandwidth, and the remaining 18 GB of storage ($45) and 230 GB of bandwidth ($115) bring the total to $170/month -- less than half the Firebase bill. If a chunk of that traffic is cursor presence or movement marked as .volatile, the savings are larger still because volatile egress is billed at $0.10/GB.

Should I self-host or use Lark Cloud?

We ship the exact same server and admin dashboard in the open-source repository that we run in production on Lark Cloud. There is no "open-core" split where essential features like the rules engine or the live data viewer are held back for paying customers.

As I wrote when we open-sourced Lark, we want the choice between self-hosting and Lark Cloud to come down to a single question: who do you want to answer the phone in the middle of the night if a disk fills up or a server goes sideways?

If you want to run it yourself, you can spin up a local stack in a couple of minutes with Docker (make up-release), use our one-command Fly.io quickstart, or follow the production deployment guide to run native binaries on a Linux host with NVMe storage. And if you start on Lark Cloud and decide two years from now that you'd rather run your own hardware, you can export your data and run the exact same software yourself.

What does Lark add beyond Firebase RTDB?

While wire compatibility gets your existing app across the bridge, we also built Lark to solve the architectural pain points we hit in our own realtime applications.

The biggest addition is volatile paths for high-frequency data. Mark a path with ".volatile": true in your security rules and Lark treats writes to that path as ephemeral, fire-and-forget broadcasts. They bypass disk persistence, have no writes-per-second cap, are batched automatically on the server (20Hz over UDP/WebTransport, 7Hz over WebSocket), and cost 1/5th the bandwidth rate on Lark Cloud. Even standard Firebase SDK clients receive volatile batches natively as PATCH events.

Lark is also built for predictable, low latency. The database engine is written in Rust using a thread-per-core architecture on Linux io_uring (see Third time's the charm), keeping internal write latencies below 50ms at p99 and under 10ms at p50 without garbage-collection pauses. If you use the lightweight (~20 KB) Lark JS SDK, clients can also connect over WebTransport (QUIC/UDP) to avoid TCP head-of-line blocking on lossy networks -- and you can mix Firebase SDK clients and Lark SDK clients in the same project talking to the same database.

Finally, Lark supports automatic database routing and ephemeral databases. Instead of cramming every game room or workspace into one giant JSON tree and fighting the 1,000 writes/sec per-database ceiling, Lark can route path prefixes into separate databases, create them on the fly when the first user connects, and clean them up when the last user leaves.

When is Lark not the right choice?

Lark does one specific job, and there are plenty of cases where another tool will serve you better.

If you want SQL, joins, or relational schemas, Lark isn't a fit -- it's a JSON tree, just like Firebase RTDB. When your data is naturally relational and you're starting a new project (or you're happy to rewrite your data layer), look at Postgres-backed platforms like Supabase instead.

If you want rich multi-field compound queries on documents, Cloud Firestore is built for that model. Like RTDB, Lark queries filter and sort on a single ordering key (orderByChild, orderByKey, orderByValue, or orderByPriority) plus a range.

And if you're looking for an all-in-one backend replacement that bundles auth, file storage, and serverless functions into one new vendor, Lark intentionally only replaces the Realtime Database so that you can keep using Firebase Auth, Hosting, and Storage (or whatever else you already run) alongside it.

Frequently asked questions

Do I have to stop using Firebase Auth, Hosting, or Storage to use Lark?

No. Lark only replaces the Realtime Database. You can leave your users on Firebase Auth, keep serving your frontend from Firebase Hosting, and keep your files in Cloud Storage. Lark validates Firebase Auth tokens out of the box when you provide your Firebase project ID, and can also handle server-side tokens generated using Google service accounts or legacy auth tokens for Firebase.

Does Lark's AGPL v3 license apply to my application code?

No. Using Lark to store and sync your application's data over the network does not put your application under the AGPL, any more than talking to a Postgres or Redis server would. The AGPL only applies if you modify the Lark server itself and run that modified server as a network service without publishing your server changes.

Can I migrate from Firebase RTDB gradually?

Yes. Most teams start by pointing a local or staging environment at Lark and running their existing test suite against it. For production, you can mirror writes or migrate specific features or rooms to Lark first before moving the rest of your traffic.

Is Lark affiliated with Google?

No. Firebase and Firebase Realtime Database are trademarks of Google LLC. Lark is an independent project and is not affiliated with, endorsed by, or sponsored by Google.

Is Lark production-ready if it's still version 0.x?

Yes. Lark Cloud runs this exact codebase in production today. The 0.x version number reflects the project's age rather than instability; we don't break the on-disk format without a migration path, and we verify every release against Firebase's own SDK test suite, REST conformance checks, and power-loss crash simulations.

Is there a free tier?

Self-hosting the open-source version of Lark is completely free with no artificial limits. On Lark Cloud, plans start at $10/month and include a 14-day free trial so you can test your migration before paying anything.

If you're ready to try it out, you can spin up the open-source version from GitHub, start a trial on Lark Cloud, or drop us a note at team@lark.sh if you'd like a hand planning a migration from Firebase.