Firestore is a fully managed, serverless document database from Google Cloud, built for web, mobile and server applications that need to scale and stay in sync.

The Short Definition

A database is an organised place where an application keeps its information so it can find it again later. Firestore is a database where information is stored as documents, which are small bundles of named fields, grouped into collections. It is called serverless because you never create, size, patch or restart any servers. You create a database, start reading and writing, and Google runs the machinery and scales it up and down for you.

Why It Exists

Traditional databases were designed for a world where one big server sat in one room and a few applications talked to it. Modern apps are different. Millions of phones and browsers connect at once. Users expect screens to update live, like a chat that shows a new message instantly. Teams do not want to spend their days tuning servers. Firestore was built for this world: it scales automatically, keeps data in sync across devices, and can be reached safely straight from client apps when you add the right rules.

Where It Is Used

Firestore is used in chat and collaboration apps, shopping carts and product catalogues, user profiles and settings, game state and leaderboards, task and booking systems, internet-of-things dashboards, and the back ends of many mobile apps. It suits data that is naturally shaped like records with fields, where reads and writes are frequent but each one is small.

To use Firestore well, first see how thinking in documents differs from thinking in tables.

The Table Way

In a relational database, data lives in tables made of rows and columns, like a spreadsheet. Every row in a table has the same columns. If a customer has several orders, the orders go into a separate table, and a “join” combines the two when you ask a question. This is powerful and precise, and it has served the world for decades.

The Document Way

In a document database, one record is one document: a self-contained bundle of fields. Documents in the same collection do not have to share the same fields. A document can hold simple values such as text, numbers and dates, and also richer values such as lists and small nested groups of fields. Related data is often stored together or placed under the parent document, so that one read gives you everything a screen needs.

Eight words unlock almost every document and conversation about Firestore.

How a Path Looks

Every document has a path made of alternating collection and document names, such as a collection of rooms, then a room, then its collection of messages, then one message. Paths always alternate: collection, document, collection, document. A path that ends on a collection names a group of documents, and a path that ends on a document names exactly one record.

flowchart TD
  DB["Database"] --> C1["Collection: rooms"]
  C1 --> D1["Document: room A"]
  C1 --> D2["Document: room B"]
  D1 --> F1["Fields: name, topic, created"]
  D1 --> SC["Subcollection: messages"]
  SC --> M1["Document: message 1"]
  SC --> M2["Document: message 2"]
  M1 --> F2["Fields: text, sender, time"]
        

Firestore comes in two editions and, within them, different ways of talking to the data. Choosing early matters, because some choices cannot be changed later.

Two Editions

Firestore is offered in a Standard edition and an Enterprise edition. Both are managed, serverless databases that share many abilities. They differ in the query engine, indexing, performance, document size limits and the way charges are counted. Both editions can exist in the same project, and data is compatible between them, so you can try one beside the other.

Shared Abilities

Choosing a Data Access Mode

When you create a database you also choose how applications talk to it. Standard supports the Native mode, which has the rich client SDKs with real-time sync, and the Datastore mode, which is an older style aimed at server-side applications. Enterprise supports Native mode and a MongoDB-compatible mode. This choice is made at creation and cannot be changed afterwards, so decide carefully.

You never see the machines, but knowing the shape of what runs underneath helps you make better design choices.

The Layers

At the top are your clients: phones, browsers and servers using Google’s libraries. Next is the Firestore service, a managed front end that authenticates requests, applies security rules where relevant, routes each request, and coordinates transactions. Below it is a distributed storage layer that stores your documents and indexes in several places at once, so that the loss of a machine, or even a whole building, does not lose data. Google handles splitting data into pieces, moving pieces between machines and balancing load as you grow.

flowchart TD
  CL["Clients: mobile, web, servers"] --> FE["Firestore front end"]
  FE --> AUTH["Identity and rules check"]
  AUTH --> TX["Transaction and query coordination"]
  TX --> IDX["Index storage"]
  TX --> DOC["Document storage"]
  DOC --> REP["Replicated across zones or regions"]
  IDX --> REP
  FE --> LIS["Real-time listener service"]
  LIS --> CL
        

Replication and Durability

Each write is stored in more than one place before Firestore tells your app it succeeded. This replication is why the database survives hardware failure. It also means a write is a small distributed agreement, which explains why there is a limit on how fast a single document can be updated over time.

Strong Consistency

Consistency is the promise about what you see after a write. Firestore gives strong consistency for reads: once a write has succeeded, any later read sees it. This makes the database simpler to reason about than systems that promise only “eventually.” Your app does not need extra tricks to avoid reading stale data from the server.

Automatic Scaling and Splitting

As data and traffic grow, Firestore automatically splits ranges of data across more machines. This works best when traffic is spread across many documents. If every write targets the same narrow range, such as keys that increase one by one, a single piece becomes the bottleneck. This is called a hotspot, and we return to it in the design chapters.

What can a document hold, and how should you shape it?

Field Types

Size Limits

In the Standard edition, and in Enterprise’s Native mode, a document may be at most about one mebibyte in size. That is room for a lot of text, but not for images or videos. Store large files in a file storage service such as Cloud Storage and keep only the file’s path in the document. Very large documents are slow to read, cost more per read and, because they are read whole, waste effort when a screen needs only two fields.

Update Speed of a Single Document

Because writes are replicated, a single document can be updated only at a limited sustained rate, roughly once per second on average. For a counter or a “likes” total that many people change at once, a single document will become a bottleneck. We will see a technique called sharded counters for this later.

Flexible Fields, But Be Consistent

Documents in one collection may have different fields, but your app code and your queries will be happier if documents of the same kind follow the same shape. Treat the flexibility as a way to evolve data gently over time, such as adding a new optional field, not as permission for chaos.

Everything an app does comes down to a few kinds of operation.

The Basic Operations

Batched Writes and Transactions

Sometimes several changes must succeed or fail together. Moving money between two accounts is the classic case: subtracting from one without adding to the other would be a disaster. Firestore offers two tools for this.

Pagination

A screen rarely needs every result at once. Pagination fetches results in pages. The recommended approach is to remember the last document of the current page and ask for the next set starting after it, using a cursor. Skipping a number of results with an offset still counts and charges for the skipped documents, so cursors are both faster and cheaper.

sequenceDiagram
  participant A as App
  participant F as Firestore
  A->>F: Query first 20 messages by time
  F-->>A: Page 1 and last document marker
  A->>F: Query next 20 after the marker
  F-->>A: Page 2 and new marker
  A->>F: Continue as user scrolls
        

Firestore is fast because every query is answered from sorted indexes rather than by scanning data.

What an Index Is

An index is like the index at the back of a book. Instead of reading every page to find a topic, you jump to the topic in the index and follow it to the right pages. A database index keeps a sorted list of field values with pointers to the documents that contain them, so a query can jump straight to the matching range.

Single-Field and Composite Indexes

The Golden Rule of Queries in Standard

In the Standard edition, every query must be answerable from an index. The database never scans through documents to look for matches. This is why queries stay fast no matter how large the collection grows: the cost of a query depends on how many results it returns, not on how much total data you have. It also means that if you want a new kind of query, you may need to create a new index first, and the error message will usually offer a link to create it.

Typical Query Powers

What Queries Cannot Do Well

Classic Firestore queries do not perform joins across collections, free-text search inside words, or arbitrary reporting across huge data. For text search, many teams add a dedicated search service. For reporting, they export data to an analytics warehouse. The Enterprise edition lists text and geospatial search among newer capabilities that may be in preview, so check the current status before relying on them.

This is the feature that makes Firestore feel magical in apps.

Real-Time Listeners

Instead of asking “has anything changed?” again and again, an app can attach a listener to a document or to the results of a query. Firestore sends the current data right away, and then sends small updates whenever something changes. The app simply redraws what changed. A chat screen, a live scoreboard and a shared to-do list all work this way.

Offline Persistence

The client SDKs for mobile and web can keep a local cache of the data your app has used. When the network drops, reads are served from the cache and writes are queued on the device. When the connection returns, queued writes are sent to the server and the cache is refreshed. Users see the app keep working, and developers write the same code online and offline.

Good modelling is what separates a fast, cheap app from a slow, expensive one.

Start from the Screens

List every screen of your app and the data each one shows. Then decide how to store the data so that each screen needs only one or two reads. This is the reverse of how table databases are usually taught, where you first model the world neatly and then write queries to rebuild each screen.

Three Ways to Store Related Data

Denormalisation: Copying on Purpose

In table databases, copying the same fact in many places is considered a bad habit called duplication. In Firestore it is often a deliberate technique. If a comment list screen needs the author’s name and photo, you may copy those two fields into each comment so that showing the list needs one query instead of one query plus a lookup per author. The price is that when the author changes their name, you may need to update the copies, often with a background function.

Choosing What to Duplicate

flowchart LR
  S1["Screen: product page"] --> P["Product document with embedded summary"]
  S2["Screen: review list"] --> R["Reviews subcollection with author name copied"]
  S3["Screen: seller dashboard"] --> Q["Collection group query across reviews"]
  U["Author renames profile"] --> FN["Background function"]
  FN --> R
        

Document Identifiers

You can choose your own document identifiers or let Firestore generate random ones. Random identifiers spread writes evenly across the database and are almost always the safest choice. Identifiers that increase steadily, such as simple counters or timestamps at the start of the name, tend to send all new writes to the same narrow range and can create hotspots at high volume.

Firestore can be reached straight from a phone, which is wonderful and dangerous. Security is not optional.

Two Ways In, Two Systems

This split is crucial. Security rules protect requests that come from client libraries. Server libraries using a service account are controlled by IAM instead and are not checked by the rules. So a leaked service account key is far more dangerous than a flaw in a single rule.

Security Rules

Rules are short written conditions stored with the database. They can look at who is signed in, which path is being touched, the data already stored, the data being written, and even other documents. The default stance is “deny unless allowed.” Common rule ideas include letting a user read and write only their own profile, letting members of a group read group data, and requiring that a new document has certain fields with valid values.

Layers of Defence

Data changes are often just the start of something that needs to happen next.

Change-Based Triggers

Firestore can announce events when documents are created, updated or deleted. You attach small pieces of server code, such as Cloud Functions, that run automatically in response. This is called event-driven design, and it lets you add behaviour without changing the app.

flowchart LR
  W["Document written"] --> EV["Change event"]
  EV --> F1["Function: send notification"]
  EV --> F2["Function: update copies"]
  EV --> F3["Function: update counters"]
  EV --> F4["Function: sync to search or analytics"]
        

Everyday Jobs for Triggers

Other Google Cloud Partners

Firestore scales a long way on its own, but a few habits keep it smooth.

Spread the Load

Because Firestore divides data into ranges, work that is evenly spread scales best. Avoid steady streams of writes to documents whose identifiers or indexed values sort next to each other, and avoid a single document that every user updates constantly.

Ramp Up Gradually

When you suddenly send very heavy traffic to a new collection, the database needs a little time to split and rebalance data. Google’s guidance for sudden new heavy workloads is to increase traffic gradually, following a rule of thumb of starting modestly and raising the rate in steady steps. Check the current best-practice page for exact numbers, since the guidance is updated over time.

Sharded Counters

A single document can handle only a limited sustained update rate, so a popular “likes” counter can choke. The fix is to split one counter into several small counter documents, called shards. Each update picks one shard at random, and to show the total, you add up the shards. Writes spread out, and reading a handful of shards is still cheap.

flowchart TD
  U1["Likes from many users"] --> R["Pick a shard at random"]
  R --> S1["Shard 1"]
  R --> S2["Shard 2"]
  R --> S3["Shard 3"]
  R --> S4["Shard 4"]
  S1 --> T["Add shards to show total"]
  S2 --> T
  S3 --> T
  S4 --> T
        

Keep Reads Small and Few

Where you place the database decides speed, resilience and sometimes legal compliance.

Regional and Multi-Regional Locations

When creating a database you choose a location. A regional location keeps data in several zones inside one region, which protects against the failure of a building and usually costs less and serves nearby users with low delay. A multi-regional location spreads data across several regions, which protects against the loss of an entire region and offers higher availability, at a higher price. The location cannot be changed later, so choose with care.

Match Location to Your Compute

Place the database in the same region as your servers and functions that use it most. Every round trip across oceans adds delay. For legal reasons, confirm that the chosen location satisfies the rules about where your users’ data may be stored.

High Availability Is Built In

Because data is replicated and managed for you, there is no failover to configure. Google publishes availability commitments for the service, which differ by location type. Read the current service level agreement to see the figures that apply to your choice.

Replication keeps you safe from hardware failure. It does not protect you from your own mistakes.

Three Safety Nets

Automatic Expiry of Old Data

Time-to-live policies let you mark a date field as an expiry time. Documents whose time has passed are deleted automatically in the background. This is perfect for sessions, temporary codes, logs and caches, and it saves both storage cost and the effort of writing clean-up jobs.

Deleting Properly

Deleting a document does not delete its subcollections. For account deletion and privacy requests, plan a proper clean-up that visits the document and everything beneath it, including copies and exports. Test it before you need it.

A database that quietly runs for months deserves a few good instruments.

The Tools

Cloud Monitoring charts usage and lets you set alerts. Query insights and query explain show how queries behave. A database fleet view helps teams with many databases compare health. Cloud Logging and audit logs record administrative actions and, if you enable them, data access. A simple dashboard with reads, writes, errors, latency and storage, plus a few alerts, covers most needs.

Firestore bills for what you use, so understanding the meter lets you shape the bill.

What You Pay For

In the Standard edition, operations are counted by documents read and written. In the Enterprise edition, they are counted in chunks of bytes read and written. Storage includes the data and the index entries that support queries. Both editions offer committed use discounts for longer terms and a daily free usage allowance. Exact prices vary by edition and location and change over time, so always check the current pricing page.

What Drives Cost Up

Ways to Reduce Cost

Every design has a price. Here is an honest balance sheet.

The Decision in One Sentence

Choose Firestore when your app needs a scalable, flexible database for record-like data with live updates and offline support, and keep heavy analysis and complex relational work in other systems built for them.

Google Cloud offers many databases. Choose by the shape of your data and your questions.

A Simple Way to Decide

Ask four questions. First, is the data naturally record-shaped and driven by screens? If yes, Firestore is a candidate. Second, do I need complex joins and constraints? If yes, a relational database is likelier. Third, is the main job analysis over huge data? Use a warehouse. Fourth, do I need extreme global scale with relational rules? Look at Spanner.

A pattern is a proven shape for a solution. These appear again and again in healthy Firestore apps.

flowchart LR
  APP["Client app"] --> RULES["Security rules"]
  RULES --> FS["Firestore"]
  FS --> TRG["Triggers"]
  TRG --> SUM["Summary documents"]
  TRG --> CPY["Refresh copies"]
  TRG --> EXP["Export to analytics"]
  APP --> SRV["Trusted server for sensitive actions"]
  SRV --> FS
        

An anti-pattern looks like a good idea but quietly causes trouble. These are the most common.

A checklist of habits shared by teams that run Firestore calmly.

Test Rules Like an Attacker

It is easy to test that the right user can reach the right data. It is just as important to test that the wrong user cannot. Try reading another person’s data, writing malformed documents, and acting while signed out. All of these should fail. Use the local emulator during development so you can test safely.

Treat Rules and Indexes as Code

Keep security rules and index definitions in version control, review changes like any other code, and deploy them through a repeatable process. That way a missing index or a loosened rule shows up in review, not in production.

Plan Schema Evolution

Because documents are flexible, old and new shapes will live side by side for a while. Write app code that tolerates missing fields, add new fields gradually, and run background jobs to update old documents when you need consistency.

Watch for Changes in Editions and Pricing

Cloud products evolve. Editions, limits and prices can change. Review the official documentation and your billing page regularly, especially before a launch or a campaign that may bring many new users.

These are illustrative scenarios showing how organisations typically use Firestore, not claims about specific companies.

Not exactly. Firestore is a database that is part of Google Cloud and is also used through Firebase. Firebase provides app-focused tools and libraries on top of Google Cloud services, including access to Firestore.

No. Firestore is serverless. Google handles scaling, replication, patching and maintenance.

They differ in the query engine, indexing options, performance characteristics, document size limits, MongoDB compatibility and how operations are priced. Many core abilities, such as client libraries with sync, triggers, backups and encryption choices, are shared. Check the current editions overview before choosing.

No. The data access mode and the location are set when the database is created. To change either, create a new database and migrate the data.

In the Standard edition every query must be answered from an index. Simple queries use automatic single-field indexes, while queries that combine fields need a composite index, which you create once and then reuse.

Not in the way a relational database does. You model related data by embedding, using subcollections, copying small pieces or storing references, and you assemble data with a few reads.

An app attaches a listener to a document or query. Firestore sends current data, then pushes changes as they happen. Each delivered change counts as a read.

Yes in the mobile and web client libraries. They keep a local cache, serve reads from it, queue writes, and sync when the network returns.

No. Rules apply to requests from client libraries. Server libraries use IAM permissions on service accounts, so guard those accounts and keys carefully.

Use a sharded counter: several small counter documents, with writes spread randomly among them and a sum taken when reading.

Documents have a size limit and are read whole, so store images in Cloud Storage and keep only their path in the document.

Use scheduled backups or point-in-time recovery to restore data. Turn these on before you need them, and rehearse a restore.

Model for few reads per screen, limit and page queries with cursors, detach unused listeners, exempt unneeded fields from indexing, expire temporary data, and set budget alerts.

Designing the data like tables and launching with permissive rules. Start from the screens, write narrow rules, and turn on backups and budget alerts before release.

Firestore is a serverless document database that stores records as documents inside collections, answers every query from indexes, keeps data strongly consistent and replicated, and pushes live updates to apps while letting them work offline. It comes in Standard and Enterprise editions with a shared core of client libraries, triggers, backups and encryption choices, and different query engines, indexing and pricing units. Security is split between rules for client libraries and IAM for servers, and both must be right.

Success comes from a few habits. Model data around the screens, keep documents lean, use subcollections and sharded counters, prefer random identifiers, write narrow rules, use triggers to keep copies fresh, and watch the meter through operations, listeners and indexes. Protect data with backups, point-in-time recovery and delete protection. With these in place, a small team can build apps that feel instant, stay in sync and scale to millions of users.