---
meta:
title: "Liveblocks vs. Firebase for collaborative editing"
parentTitle: "Compare"
description:
"Compare Liveblocks with Cloud Firestore and Firebase Realtime Database for
collaborative apps, offline data, presence, and shared-document 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? [#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](#can-i-use-firebase-and-liveblocks-together).
## Compare the responsibilities [#compare-the-responsibilities]
| Area | Liveblocks | Cloud Firestore | Realtime Database |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Persistence | Shared documents in Storage. A CRDT-based document store. Concurrent edits merge automatically, and data is kept until you delete it. Learn more. | Documents and collections. Documents hold fields and are grouped into collections that you query. Learn more. | One JSON tree. Data is stored as a single JSON tree and read or written by path. Learn more. |
| Realtime updates | Document changes, presence, and broadcast events. Every change to a document is pushed to everyone in the room. Learn more. | Snapshot listeners on documents and queries. | Listeners on paths in the tree. |
| Presence | Built in. Who is online, cursors, and selections. Presence is short-lived per-user state such as cursor position or selection. Learn more. | Not built in. Firebase suggests pairing with Realtime Database. The documented approach uses Realtime Database connection state and Cloud Functions to write online status into Firestore. Learn more. | Connection state and onDisconnect handlers. |
| Conflict resolution | CRDT-based. Concurrent edits to objects, lists, maps, and text merge automatically. Writes to the same single value are last-write-wins. Learn more. | None. Last write wins per field. | None. Last write wins per path. |
| Text editing | Built in, with Tiptap, BlockNote, Lexical, and more. Official packages for popular editors, plus Yjs guides for others. Learn 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. Offline persistence caches documents on the device and can survive closing the app on supported platforms. Learn more. | Queued writes while the app is open. Disk persistence on Android and iOS. Web clients keep data in memory only. Learn more. |
| Ready-made UI | Cursors, avatar stacks, comments, and notifications. React components you can drop in, plus hooks for building your own. Cursors, AvatarStack, Comments. | None for collaboration. | None for collaboration. |
| Authentication | Your server issues access tokens using your existing auth. Works with any auth provider, including Firebase Auth. Tokens grant access to specific rooms. Learn more. | Firebase Auth with Security Rules. Rules run on Google's servers and decide what each user can read and write. Learn more. | Firebase Auth with Security Rules. Rules run on Google's servers and decide what each user can read and write. Learn more. |
| 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? |
## Ticket records vs. shared drafts [#ticket-records-vs-shared-drafts]
For a support app, Firebase can own the customer and ticket records while
[Liveblocks Sync](/docs/products/sync) powers the response draft that two agents
edit together. [Editor integrations](/docs/products/sync/integrations) give you
collaborative text, [Presence](/docs/products/sync/presence) shows who is in the
draft, and [Comments](/docs/products/comments) adds a review conversation. The
ticket stays in Firebase while everyone edits one shared draft.
## How does offline behavior differ? [#how-does-offline-behavior-differ]
Firestore covers more cases.
[Firestore's offline persistence](https://firebase.google.com/docs/firestore/manage-data/enable-offline)
caches records and queues writes on the device, and on supported browsers that
cache survives closing and reopening the app.
[Liveblocks Storage](/docs/products/sync/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. Edits to different fields all survive. Writes to the same single value are last-write-wins. Learn more. | 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](https://firebase.google.com/docs/database/web/offline-capabilities)
per platform. Either way, a text editor still needs a CRDT, not just a listener
on a database record.
## Record updates vs. shared documents [#record-updates-vs-shared-documents]
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](/docs/guides/how-conflict-resolution-works-in-liveblocks-sync)
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? [#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](/docs/api-reference/authentication) 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? [#how-do-firebase-and-liveblocks-costs-differ]
Firebase's [Spark plan](https://firebase.google.com/pricing) is free with fixed
quotas, and the pay-as-you-go [Blaze plan](https://firebase.google.com/pricing)
includes the same quotas before billing usage.
[Firestore](https://firebase.google.com/docs/firestore/pricing) 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](https://firebase.google.com/docs/database/usage/billing)
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](/docs/pricing/plans) apply once across all Liveblocks usage.
Firebase's databases are managed services and cannot be self-hosted. Liveblocks
offers [self-hosting](/docs/platform/data-storage#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 [#get-started]
Explore the
[editor example](/examples/collaborative-text-editor-advanced/nextjs-tiptap-advanced)
and follow the [setup guide](/docs/get-started) for the part of your app people
edit together. Keep your ticket records in Firebase.
[Start building with Liveblocks for free](https://liveblocks.io/dashboard).
---
For an overview of all available documentation, see [/llms.txt](/llms.txt).