Firestore vs Realtime Database: Which Is Best and Why?

Firebase offers two databases: Realtime Database (the original JSON tree) and Cloud Firestore (the newer document database). Both sync in real time and work offline, but they’re built for different needs. Here’s how they compare and which one I pick—and why.fi

Quick Overview

	Realtime Database	Firestore
Model	Single JSON tree; data nested under paths	Collections + documents; each doc can have subcollections
Queries	Deep path reads; no real “query language”	Rich queries: where, orderBy, limit, compound indexes
Scaling	Single region; scales but with limits on fan-out	Multi-region; designed to scale with automatic sharding
Offline	Full offline with persistence	Full offline with persistence
Pricing	Per GB stored + bandwidth; often cheaper at tiny scale	Per read/write/delete + storage; can get costly with heavy reads
Latency	Very low (single tree, simple reads)	Slightly higher (more flexible but more work per query)

Realtime Database: What It Is and When It Shines

What it is — One big JSON tree. You read and write at paths like /users/uid/profile or /chats/chatId/messages. Data is nested; you listen to a path and get everything under it (or use shallow reads to limit depth). There’s no “query by field” — you structure the tree so that the path is your query (e.g. “messages for this chat” = one path).

Strengths:

• Simple — No collections, no indexes. You just read/write paths. Great for small apps and prototypes.
• Very low latency — Single tree, direct path access. Good for high-frequency updates (e.g. presence, cursor position, live scores).
• Cheap at small scale — If you have little data and moderate traffic, storage + bandwidth pricing can be lower than Firestore’s read/write model.
• Tiny SDK — Smaller bundle than Firestore; matters for very constrained environments.

Weaknesses:

• No real queries — You can’t “get all users where role = admin” or “messages where createdAt > X.” You either read a path and filter in the client or denormalize heavily and maintain multiple paths. Complex querying gets messy fast.
• Scaling and depth — Deep trees and wide “fan-out” (e.g. one write that touches many paths) don’t scale as well. You hit limits and have to flatten or split data.
• Structure — Everything is a tree. Relations and many-to-many are awkward; you end up with duplicated data and sync logic.

When I use it: Simple real-time apps (presence, simple chat, live counters), prototypes, or when the data is naturally a tree and query needs are minimal. Also when the team already has a Realtime Database app and migration isn’t worth it.

Firestore: What It Is and When It Shines

What it is — A document database. Data lives in collections (e.g. users, chats); each document has an ID and key-value (and nested) data. You can have subcollections (e.g. chats/chatId/messages). You query with where, orderBy, limit, and compound indexes. Realtime listeners work on collections or query results.

Strengths:

• Real queries — “Users where role == 'admin',” “messages where chatId == X orderBy createdAt limit 50.” You model data once and query it many ways. Compound indexes are explicit and predictable.
• Scales better — Designed for large apps. Multi-region, automatic scaling. No single-tree bottleneck. Better for many collections and complex access patterns.
• Clearer data model — Documents and subcollections map well to “entities” and relations. Less denormalization than Realtime Database for the same flexibility.
• Offline — Same strong offline support; queries and listeners work offline with persistence.

Weaknesses:

• Pricing can bite — You pay per read/write/delete. Heavy read traffic (e.g. “list all items” on every open) can get expensive if you don’t cache or paginate. You need to think about read volume.
• More setup — Indexes, security rules, and data modeling take more thought than “just a path.”
• Slightly higher latency — More flexible queries mean a bit more work per request than a single path read. Usually negligible for most apps.

When I use it: Most new Firebase apps. Anything that needs “list by X,” “filter by Y,” pagination, or multiple views over the same data. Apps that will grow in data and query complexity.

Side-by-Side: Key Differences

Data structure — Realtime Database = one tree; Firestore = collections + documents + subcollections. Firestore fits relational-ish and multi-entity models better.

Querying — Realtime Database = path-based (and maybe client-side filter); Firestore = server-side queries with where/orderBy/limit and indexes. Firestore wins for anything beyond “give me this path.”

Scaling — Realtime Database scales but has a single-tree and fan-out limits; Firestore is built for scale and multi-region. For growth, Firestore is the safer bet.

Cost — At tiny scale and low reads, Realtime Database can be cheaper (GB + bandwidth). At higher read/write volume or complex queries, Firestore’s model is easier to reason about and often comparable or better if you design for it (pagination, cache, avoid unnecessary reads).

Offline — Both support offline persistence and sync. No clear winner; both are good.

Which Is Best? My Recommendation

For most apps today: Firestore is the better default.

Reasons:

1. Querying — Almost every app eventually needs “get items by condition” or “ordered list with pagination.” Firestore does that natively; Realtime Database forces workarounds and denormalization.
2. Scaling — If the app grows, Firestore scales with you. Realtime Database can hit structural limits and require big refactors.
3. Data model — Documents and collections match how we think about users, chats, posts, etc. Easier to maintain and onboard others.
4. Ecosystem and future — Google is investing in Firestore (multi-region, better tooling). Realtime Database is stable but not where new features land first.

When Realtime Database is still the best choice:

• Very simple real-time only — Presence, live counters, or a tiny tree with almost no query needs. Simplicity and latency matter more than flexibility.
• Strict cost at tiny scale — You have almost no reads/writes and want the smallest bill; Realtime Database’s pricing can be lower.
• Existing Realtime Database app — Migration has a cost. If the current app is simple and stable, staying on Realtime Database is fine until you need Firestore’s query and scale.

Summary: Use Firestore for new projects and anything that needs queries or will grow. Use Realtime Database for simple, path-based real-time apps or when you’re already on it and migration isn’t justified. In practice, “which is best” = Firestore for most cases; Realtime Database for a narrow but real set of use cases.

---

*Saad Mehmood — Portfolio