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.