Liveblocks vs. Firebase for collaborative editing
Liveblocks is a realtime collaboration platform that allows you to build multiplayer applications where users and agents can work together. It provides a sync engine that powers shared documents, text editing, presence, and more. Firebase is Google's app platform with two hosted databases, Cloud Firestore and Realtime Database, plus auth, hosting, and client SDKs with offline support.
Which should you choose?
Firebase and Liveblocks solve different problems. Firebase is where your application records live and how clients read them, including offline, whereas Liveblocks is how people edit artifacts together.
Choose Liveblocks when several people work on the same document, canvas, or board at once, and their edits need to merge without overwriting each other. Choose Firebase when your app needs a client-side database with offline support and realtime record updates, such as a job list that must keep working without a connection or a ticket queue refreshing on a dashboard. Many products use both services together.
Compare the responsibilities
| Area | Liveblocks | Cloud Firestore | Realtime Database |
|---|---|---|---|
| Persistence | Shared documents in Storage. | Documents and collections. | One JSON tree. |
| Realtime updates | Document changes, presence, and broadcast events. | Snapshot listeners on documents and queries. | Listeners on paths in the tree. |
| Presence | Built in. Who is online, cursors, and selections. | Not built in. Firebase suggests pairing with Realtime Database. | Connection state and onDisconnect handlers. |
| Conflict resolution | CRDT-based. Concurrent edits to objects, lists, maps, and text merge automatically. | None. Last write wins per field. | None. Last write wins per path. |
| Text editing | Built in, with Tiptap, BlockNote, Lexical, and more. | Not built in. Requires a CRDT library and your own sync code. | Not built in. Requires a CRDT library and your own sync code. |
| Offline | Edits queue while a loaded document is disconnected. | Cached reads and queued writes, kept across restarts. | Queued writes while the app is open. Disk persistence on Android and iOS. |
| Ready-made UI | Cursors, avatar stacks, comments, and notifications. | None for collaboration. | None for collaboration. |
| Authentication | Your server issues access tokens using your existing auth. | Firebase Auth with Security Rules. | Firebase Auth with Security Rules. |
| The main question | Which parts of your app should people edit together? | Which records and business rules belong in Firestore? | Which data should clients sync as a JSON tree? |
For a support app, Firebase can own the customer and ticket records while Liveblocks Sync powers the response draft that two agents edit together. Editor integrations give you collaborative text, Presence shows who is in the draft, and Comments adds a review conversation. The ticket stays in Firebase while everyone edits one shared draft.
How does offline behavior differ?
Firestore covers more cases. Firestore's offline persistence caches records and queues writes on the device, and on supported browsers that cache survives closing and reopening the app. Liveblocks Storage queues edits made in an already-loaded document and sends them when the connection returns. Unsent edits are not kept across a browser restart unless you build that yourself.
| Situation | Liveblocks Storage | Cloud Firestore |
|---|---|---|
| Network drops during an open session | Local edits queue and send on reconnect. | Reads and writes use the local cache. |
| Closing and reopening the browser | Reconnects to the loaded document. Unsent edits are not kept across restarts. | The persistent cache keeps data and queued writes when enabled on a supported browser. |
| Two people replace the same value | Depends on the data type. A single value resolves to one writer. | Last write wins once the offline change reaches the server. |
This table covers Storage and Firestore, not the Yjs integrations or every Firebase SDK. Realtime Database has its own offline behavior per platform. Either way, a text editor still needs a CRDT, not just a listener on a database record.
For an activity dashboard, a listener on a Firestore query may be enough: a record changes, and connected clients show the new value. For an editor, the difference is between overwriting a whole document and merging the individual edits two people make.
Firestore and Realtime Database do not merge. A write replaces the field or path it targets, so the last write wins, and there is no text CRDT. Liveblocks Storage merges concurrent edits to objects, lists, maps, and text. How it resolves conflicts depends on the data type: edits to different fields all survive, while concurrent writes to the same single value are last-write-wins, ordered by arrival at the server. You still need to structure your document and define business rules for competing actions. For example, when two people assign different owners to the same task, your app needs one final owner.
Can I use Firebase and Liveblocks together?
Yes. For a support tool, Firebase holds customers, tickets, and assignments while Liveblocks holds the response draft. Your server signs users in with Firebase Auth as usual and issues a Liveblocks access token for the ticket's room. There is no built-in sync between the two: your application connects them, and Liveblocks does not read or write Firebase records.
When an agent submits the response, your application copies the final text into the ticket record. Keep that copy separate from the live draft; if both stay editable, you need another conflict policy.
Store the Liveblocks room ID on the ticket record so your server knows which room to authorize. Treat the copy in Firebase as read-only.
How do Firebase and Liveblocks costs differ?
Firebase's Spark plan is free with fixed quotas, and the pay-as-you-go Blaze plan includes the same quotas before billing usage. Firestore charges per document read, write, and delete, plus stored data and network egress; the free quota is 50K reads, 20K writes, and 20K deletes per day and 1 GiB stored. Realtime Database charges mainly for stored and downloaded data: 1 GB stored and about 10 GB downloaded per month are free, then $5 per GB stored and $1 per GB downloaded, with 100 simultaneous connections on Spark and 200K per database on Blaze. A read-heavy ticket list therefore needs a different estimate from a frequently updated JSON tree.
As an example, a query that returns 20 documents to 50 clients is 1,000 document reads for the first result alone, before later listener updates, reconnects, or index charges. That count excludes free quota and location-specific rates. Streaming the same records from Realtime Database instead means measuring downloaded bytes, including protocol overhead.
If Liveblocks holds the draft, budget its collaboration usage separately. Your plan's credits apply once across all Liveblocks usage.
Firebase's databases are managed services and cannot be self-hosted. Liveblocks offers self-hosting as a paid add-on on the Enterprise plan. If you go that route, your own servers, database, backups, and operations are part of the budget.
Get started
Explore the editor example and follow the setup guide for the part of your app people edit together. Keep your ticket records in Firebase.