Firebase Realtime Database vs Firestore: Choosing the Right Backend for Your MVP

New Firebase projects default to Firestore, and for most products that’s the right call — but I still reach for Realtime Database in specific situations, and I think the “just use Firestore, RTDB is legacy” advice going around is too simple. Here’s the actual tradeoff.

The core difference: tree vs. collections

Realtime Database is one giant JSON tree. You read and write at a path, and every listener on an ancestor path gets the whole subtree on change unless you’re careful about how you shape your data. Firestore is a proper document/collection model with real querying — compound queries, range filters, and indexes that don’t require you to pre-shape your data around every access pattern.

For anything with real query requirements — “show me all RFQs for this organization where status is pending and created after X” — Firestore’s query engine is not close. RTDB queries are limited to a single ordered key range, which means non-trivial filtering happens client-side or via denormalized index nodes you maintain by hand.

Where RTDB still wins

Low-latency, high-frequency writes with simple fan-out. RTDB’s onValue/onChildAdded listeners and its data model are genuinely well suited to presence systems, live cursors, and notification-style event streams — the kind of thing where you’re writing a small payload to a specific path and want every subscriber notified as fast as possible, without worrying about Firestore’s per-document write-rate limits.

I used RTDB specifically for onValueCreated triggers on paths like /leads/{pushId} and /invitations/{orgId}/{pushId} — event-style writes where the trigger fires a downstream action (send an email, ping Telegram) and the data itself doesn’t need complex querying. That’s exactly RTDB’s sweet spot: simple structure, real-time fan-out, cheap.

Cost predictability at high write volume. RTDB pricing is based on bandwidth and storage. Firestore pricing is based on document reads/writes/deletes, which means a chatty client that re-subscribes to a query on every re-render can produce a much less predictable bill than the same access pattern would on RTDB. If you’re building something write-heavy and simple — a live counter, a presence system — model the Firestore cost carefully before assuming it’s the default-correct choice.

Where Firestore wins, decisively

• Multi-tenant SaaS with real query needs. Organization-scoped data, role-based permissions, filtered lists — this is Firestore’s actual use case, and RTDB will make you build your own indexes by hand for anything beyond trivial lookups.
• Security rules that need to reason about document structure. Firestore’s rules language can validate field types, check document relationships, and reason about request data structurally in a way RTDB’s rules cannot.
• Offline support and multi-region. Firestore’s offline persistence and multi-region replication are more mature than RTDB’s.

My actual decision rule

If the data is a tree of simple, mostly-independent records that need real-time fan-out and minimal querying — RTDB. If the data needs filtering, sorting, pagination, or has real relational structure — Firestore, no contest. Most SaaS products are the second case, which is why Firestore is the sane default. But “Firestore is the default” and “RTDB is dead” are different claims, and conflating them leads to over-engineered Firestore schemas for what should have been a simple RTDB tree.

The two aren’t mutually exclusive within one project, either — I’ve shipped systems using Firestore for the application’s core multi-tenant data and RTDB specifically for event-trigger paths that fan out to Cloud Functions. Pick per data shape, not per project.