Cloud Firestore vs Realtime Database in 2026

Pick Cloud Firestore for anything you are starting in 2026 — it is what
Google itself recommends new customers start with, it queries like a real
database, and it is the only one of the two that runs multi-region. Keep
Realtime Database for exactly one class of feature: tiny, extremely chatty
ephemeral state — presence, typing indicators, live cursors — where its ~10 ms
responses and bandwidth-based pricing beat Firestore's per-operation billing.
The two are not rivals so much as a default and a specialist, and Firebase
documents running both in the same project
for precisely that split.

That is the whole verdict. The rest of this guide is the evidence, because the
official comparison page
is studiedly neutral and the numbers buried in it are not.

The one-table answer

Every row above comes from Firebase's own
rtdb-vs-firestore page
and the Realtime Database locations list.

Queries: the dealbreaker dimension

Realtime Database can sort or filter on a property in a single query — not
both. Anything shaped like "unpaid invoices for this customer, newest first"
means client-side filtering or denormalising a combined key into your JSON
tree. Its queries are also deep by default: fetch a node and you fetch the
whole subtree under it, which is why RTDB data modelling advice is dominated by
flattening techniques.

Firestore supports compound sorting and filtering in one indexed query, and its
performance is a function of your result set, not your dataset — a query
returning 20 documents costs the same over 60 documents or 60 million. That
property alone removes a whole category of scaling rewrites later. If you have
debugged the equivalent problem in Postgres, this is the
first-row-per-group pattern
class of query — trivially expressible in Firestore and SQL, painful in a JSON
tree.

Pricing: two completely different meters

• Realtime Database bills bandwidth and storage, at comparatively high rates. Operation count is free; bytes are not.
• Firestore bills per operation — every document read, write and delete — with storage and bandwidth at lower rates.

The practical consequence cuts both ways. A presence system pinging tiny
payloads thousands of times a minute is cheap on RTDB (small bytes) and
expensive on Firestore (every ping is a billed write). A dashboard that renders
200 documents per page load is predictable on Firestore and can become a
bandwidth bill on RTDB, because deep queries pull whole subtrees whether you
render them or not. Model your read/write mix before trusting either free tier
— the same discipline applies to
Supabase's usage-based limits or any
metered backend.

Scaling: automatic vs sharded

Firestore scales automatically with no connection cap and no per-database write
ceiling you have to plan around. Realtime Database documents hard per-instance
limits — around 200,000 concurrent connections and 1,000 writes/second —
beyond which the documented answer is sharding across multiple database
instances, and shards are something you operate: cross-shard queries and
transactions become your application's problem.

Regions: the quiet EU problem

This one matters more than the comparison page's phrasing suggests, especially
for European teams. Realtime Database exists in exactly three regions —
us-central1, europe-west1 (Belgium) and asia-southeast1 — is zonal (not
even multi-zone redundant within its region), and
the location is immutable once provisioned.
Firestore offers a proper spread of regional locations plus multi-region
deployments with multi-datacentre redundancy — which is where its 99.999%
uptime figure against RTDB's 99.95% comes from.

If your users are in Europe and your compliance posture cares where data
lives, Firestore gives you real options; RTDB gives you Belgium, chosen
irrevocably at creation time.

Decision scenarios

A SaaS dashboard (auth, lists, filters, billing). Firestore, no caveats.
Compound queries, web offline persistence and per-operation pricing all match
list-heavy CRUD. RTDB's query model would fight you from the first filtered
view.

A chat or collaboration app. Both — the documented pattern. Messages,
threads and profiles in Firestore; presence, typing indicators and live
cursors in RTDB, where high-frequency tiny writes are at home on the
bandwidth meter and 10 ms latency is perceptible.

IoT telemetry / high-frequency ingestion. Neither is ideal at serious
scale, but between the two: RTDB absorbs frequent small writes cheaply until
the 1,000 writes/s ceiling, after which you are sharding by hand. Past that,
you are in time-series-database territory, not Firebase territory.

A game leaderboard with live updates. RTDB for the live tick, Firestore
for the durable record — the same split as chat.

If you are choosing a backend from scratch

The Firestore-vs-RTDB question assumes Firebase is already decided. If it is
not, note what both options lack: SQL. Joins, aggregates and row-level
authorisation policies are exactly the features whose absence drives the
denormalisation gymnastics above — and they are standard Postgres, which is
what Supabase puts in
front of you, with
row-level security instead of rules-tree debugging
and EU regions across several providers rather than one Belgian instance. We
keep a running comparison in
why developers are switching from Firebase to Supabase.

Firebase remains the better choice when your app is mobile-first and leans on
the wider kit — FCM push, Crashlytics, Remote Config, anonymous auth with
zero setup — or when RTDB's presence primitives are the product. For a
query-heavy web application, the honest 2026 default is Firestore if you are
staying in Firebase, and Postgres if you are not.

---

Originally published at https://www.iloveblogs.blog