Firestore vs Realtime Database: Which One Should You Use?

Firebase has two databases. Realtime Database came first, in 2012. Cloud Firestore arrived in 2017 and is the one Google now recommends for new projects.

Both sync data live to connected devices. Both work offline. The names do nothing to explain the difference, which is why this question gets asked constantly.

They store data in genuinely different shapes

Realtime Database is one enormous JSON object. Your entire database is a single tree. Everything hangs off one root.

{
  "users": {
    "user1": {
      "name": "Maya",
      "posts": {
        "post1": { "title": "Hello" }
      }
    }
  }
}

Firestore stores documents inside collections. A document is a bundle of fields. A collection is a folder of documents. Documents can hold their own sub-collections.

users (collection)
  └── user1 (document)
        ├── name: "Maya"
        └── posts (sub-collection)
              └── post1 (document)
                    └── title: "Hello"

This is not cosmetic. In Realtime Database, reading a node reads everything underneath it. Ask for a user and you also download every post they ever wrote. The usual workaround is flattening your data into separate top-level lists and stitching it together in the app.

In Firestore, reading a document gets you that document. Sub-collections are not included unless you ask. The structure you want is usually the structure you can have.

Querying is where the gap is widest

Realtime Database can sort or filter on one property at a time. That is the whole feature. Anything more and you are filtering in your app after downloading too much.

Firestore handles compound queries — several conditions at once, sorted, paginated.

import { collection, query, where, orderBy, limit, getDocs } from "firebase/firestore";

const q = query(
  collection(db, "orders"),
  where("status", "==", "shipped"),
  where("total", ">", 50),
  orderBy("total", "desc"),
  limit(20),
);

const snapshot = await getDocs(q);

There is a catch worth knowing early: compound queries need an index, and Firestore will not guess. The first time you run one it fails with an error containing a link. Click the link, the index is created, the query works. It feels like a bug the first time and is entirely normal.

How they charge you is the real decision

This trips people up. In Firestore, a query returning 500 documents costs 500 reads, even if each document is four bytes. Build a dashboard that lists everything on load, and a few hundred users can produce a surprising bill.

When Realtime Database is genuinely the better choice

It is older, not obsolete. Two cases where it still wins:

• Very frequent, very small updates. Live cursor positions, a multiplayer game state, a presence indicator. Dozens of tiny writes per second cost less under bandwidth pricing than under per-operation pricing.
• Presence detection. Knowing reliably when someone disconnects is a first-class Realtime Database feature. Firestore has no direct equivalent, and the usual workaround is to use Realtime Database alongside it just for this.

Using both in one project is allowed and reasonably common.

The rest of the differences, briefly

That last row matters. In Realtime Database, granting read on a node grants it on everything below. In Firestore, rules apply exactly where you write them — which is safer, and requires you to be explicit.

So which one?

1. New project, ordinary app? Firestore.
2. Live cursors, game state, or presence? Realtime Database, possibly alongside Firestore.
3. Already on Realtime Database and it works? Stay. Migrating is real work and "newer" is not a reason on its own.
4. Unsure? Firestore. It is where the development effort goes.