Firebase Firestore

Google's document database with real-time sync and tight Firebase-platform integration.

VISIT FIREBASE FIRESTORE

Key takeaway: Firestore is a mobile and Firebase-platform decision more than a database decision. If you are shipping an app where the client SDK, offline persistence, and Google auth do most of the work, it is hard to beat on time to first release. For a web product with relational data, Supabase or Convex serve you better and lock you in less.

Quick facts

  • CategoryNoSQL / document
  • EngineJS-native
  • PricingFreemium
  • LicenseProprietary
  • Created2014
  • GitHub starsclosed
  • PostgresNo
  • Edge-readyNo

Bundled features: Real-time sync Tight Firebase integration

What it is

Firestore is Google's document database with real-time sync as a primary feature. Tight integration with the Firebase platform, auth, storage, cloud functions, FCM. Generous free tier (1GB storage, 50k reads/day). The default for Firebase-stack apps.

Best for

  • Firebase-platform apps using auth + storage + functions
  • Mobile apps where Firestore SDK is the path of least resistance
  • Real-time-first apps (chat, collab, live updates)

When not to pick it

Skip Firestore for relational data, the document model fights against it. Skip if vendor lock-in to Google Cloud is a concern.

My take

Firestore is good for Firebase-stack apps. For non-Firebase projects, the lock-in is real and modern alternatives (Supabase, Convex) usually win.

The client SDK does work your backend usually does

Firestore's real feature is that the client talks to the database directly, safely. Security rules sit between the SDK and the data, so a mobile app can read and write without you building and hosting an API tier at all. Offline persistence is built in: the SDK caches locally, queues writes, and reconciles when the connection returns, which is behaviour you would otherwise spend months implementing badly. Real-time sync means listeners update as data changes, so chat, presence, and live collaboration come close to free. Combined with Firebase auth, storage, and cloud functions, a small team gets a working product in front of users faster here than almost anywhere else. The cost is that your security model lives in rules files rather than in reviewable server code, and rules are easy to write permissively and genuinely awkward to test properly.

Queries you cannot write, and a bill shaped like document reads

Firestore's query model is deliberately limited so every query stays fast regardless of collection size. There are no joins, only a narrow set of aggregation operations, and real constraints on combining filters, which pushes you toward denormalising data across collections and maintaining duplicated copies with functions. That is a coherent design, and it is also why relational data fights this database at every step. The pricing model compounds it: cost tracks document reads, writes, and deletes rather than compute time, so a screen that reads a hundred documents to render one view is an ongoing expense, and denormalisation that multiplies writes shows up on the invoice. Migration out is the hard part. There is no SQL to port, the data is documents shaped around your query limits, and you are typically restructuring the model as well as moving it.

Frequently asked questions

Is Firestore free?

There is a free tier generous enough for prototypes and small apps, after which pricing tracks document reads, writes, deletes, and storage rather than compute hours. That is the important structural point: cost follows access patterns, so a chatty screen or a denormalised write fan-out can cost more than you would guess from the data volume alone.

Firestore or Supabase?

Firestore for mobile apps already on the Firebase platform, where offline sync and the direct client SDK save the most work. Supabase for web products with relational data, SQL, and a portable exit. The lock-in difference is real: Postgres data moves with a dump, whereas leaving Firestore usually means redesigning the data model as well.

How hard is it to migrate off Firestore?

Harder than it looks. Documents are typically shaped around Firestore's query limits and denormalised across collections, so the export is not a schema anyone else would have designed. Expect to restructure the model, rewrite every query, and replace security rules with server-side access control. Plan it as a project, not a data transfer.

Links

Compare Firebase Firestore side-by-side

Firebase Firestore vs Supabase → Firebase Firestore vs MongoDB Atlas →

Similar tools you should also consider

MongoDB Atlas

The hosted MongoDB platform. Document-oriented, mature, serverless tier available.

Read the take →

Supabase

Postgres-based platform: database, auth, storage, edge functions, realtime, vectors. Open source.

Read the take →

Convex

JS-first reactive database, functions are the API, real-time queries by default.

Read the take →

If Firebase Firestore is your pick, the next conversation is short

The 30-min call is where your database choice becomes a real architecture, a migration plan if you are switching, and a price range you can take to your stakeholders. Describe your stack, your scale, your data shape. I tell you whether Firebase Firestore is genuinely your fit.