But before you can confidently create, read, update, or delete data, you need to understand how Firestore actually organizes information. It doesn't look like a SQL database, and treating it like one is the fastest way to end up with a messy, hard-to-query data structure.

In this tutorial, you'll learn how Firestore's NoSQL data model works, then build a small task management app to practice every CRUD operation with the Firebase Web SDK (v9+, modular). By the end, you'll be able to add tasks, query them, update nested fields and arrays, and delete data safely without leaving orphaned subcollections behind.

Table of Contents

• Prerequisites

• How Firestore Structures Data

• Step 1 – Set Up Your Firebase Project

• Step 2 – Initialize the SDK

• Step 3 – Create: Adding Tasks

• Step 4 – Read: Querying Tasks

• Step 5 – Update: Modifying Tasks

• Step 6 – Delete: Removing Tasks

• Debugging Common Issues

• Conclusion

Prerequisites

Before you start, make sure you have the following:

• Node.js v18 or later (node --version)

• A Google account to create a Firebase project (the free Spark plan is enough for this tutorial)

• Basic familiarity with JavaScript, including async/await and ES modules

• A code editor and a terminal

You don't need prior experience with Firebase or NoSQL databases, as this guide builds that understanding from the ground up.

How Firestore Structures Data

If you're coming from a relational (SQL) background, the first thing to unlearn is the idea of tables with a fixed schema and foreign key joins. Firestore is a document-oriented NoSQL database, and it organizes data around two core concepts: collections and documents.

• A collection is a named bucket that holds documents. Think tasks, users, or orders.

• A document is a single record inside a collection, identified by a unique ID. It stores data as key-value pairs, similar to a JSON object.

Here's the catch that trips up a lot of newcomers: documents don't need to share the same fields. One task document can have a dueDate field while another doesn't. Firestore doesn't enforce a schema at the database level, that responsibility shifts to your application code.

Nesting and subcollections

Documents can hold two kinds of nested data:

• Maps, which are objects nested directly inside a document (for example, a metadata field containing { priority, dueDate })

• Subcollections, which are entire collections nested under a specific document (for example, every task can have its own comments subcollection)

This gives you a structure that looks like a tree:

tasks (collection)
 └── taskId (document)
      ├── title: "Article title"
      ├── completed: false
      ├── tags: ["writing", "firebase"]
      ├── metadata: { priority: "high", dueDate: <timestamp> }
      └── comments (subcollection)
           └── commentId (document)
                ├── text: "CRUD Article"
                └── createdAt: <timestamp>

Supported data types

Firestore documents can store several native types. The ones you'll use most often are:

Why this matters before writing CRUD code

Every CRUD operation you'll write later depends on this structure:

• Create means adding a document to a collection, with an auto-generated or custom ID.

• Read means fetching either a single document by ID or a set of documents matching a query.

• Update means modifying fields on an existing document, including nested maps and arrays.

• Delete means removing a document, and Firestore will not automatically clean up its subcollections (a common gotcha you'll see in Step 6).

With the mental model in place, let's set up a project and start writing code.

Step 1 – Set Up Your Firebase Project

Head to the Firebase console and create a new project.

1. Click Add project, give it a name (for example: crud-tasks-demo), and follow the setup wizard (Google Analytics is optional for this tutorial).

2. Once the project is created, open the left sidebar and click Databases and Storage and then Firestore.

3. Click Create database. Choose a location close to you, and for this tutorial, start in test mode so you can read and write without configuring security rules yet.

Note: Test mode leaves your database open to anyone for 30 days. Never ship an app to production without proper Firestore security rules, we'll touch on this in the Debugging section.

You should now see an empty Firestore database, ready to receive your first collection.

Step 2 – Initialize the SDK

Create a new project folder and install the Firebase Web SDK:

mkdir firestore-crud-demo && cd firestore-crud-demo
npm init -y
npm install firebase

Grab your project's config object from Project settings - General - Your apps - Web app in the Firebase console (register a new web app if you haven't yet).

Create a firebase-config.js file:

// firebase-config.js
import { initializeApp } from "firebase/app";
import { getFirestore } from "firebase/firestore";

const firebaseConfig = {
  apiKey: "YOUR_API_KEY",
  authDomain: "YOUR_PROJECT_ID.firebaseapp.com",
  projectId: "YOUR_PROJECT_ID",
  storageBucket: "YOUR_PROJECT_ID.appspot.com",
  messagingSenderId: "YOUR_SENDER_ID",
  appId: "YOUR_APP_ID",
};

const app = initializeApp(firebaseConfig);
export const db = getFirestore(app);

Every CRUD example from here on imports db from this file. Keep your actual config values out of version control (use environment variables in a real project).

Step 3 – Create: Adding Tasks

Firestore gives you two ways to create a document: let Firestore generate the ID, or set your own.

Auto-generated ID with addDoc()

// create-task.js
import { collection, addDoc, Timestamp } from "firebase/firestore";
import { db } from "./firebase-config.js";

async function createTask() {
  try {
    const docRef = await addDoc(collection(db, "tasks"), {
      title: "Write CRUD article",
      completed: false,
      tags: ["writing", "firebase"],
      metadata: {
        priority: "high",
        dueDate: Timestamp.fromDate(new Date("2026-09-15")),
      },
      createdAt: Timestamp.now(),
    });
    console.log("Task created with ID:", docRef.id);
  } catch (error) {
    console.error("Error creating task:", error);
  }
}

createTask();

Custom ID with setDoc()

Use this when you want to control the document ID yourself, for example, matching it to an ID from another system.

import { doc, setDoc } from "firebase/firestore";
import { db } from "./firebase-config.js";

async function createTaskWithId(taskId) {
  await setDoc(doc(db, "tasks", taskId), {
    title: "Review pull request",
    completed: false,
    tags: ["code-review"],
  });
}

createTaskWithId("task-001");

Adding a document to a subcollection

To add a comment under a specific task, you reference the parent document first:

import { collection, addDoc, Timestamp } from "firebase/firestore";
import { db } from "./firebase-config.js";

async function addComment(taskId, text) {
  await addDoc(collection(db, "tasks", taskId, "comments"), {
    text,
    createdAt: Timestamp.now(),
  });
}

addComment("task-001", "First draft done");

Step 4 – Read: Querying Tasks

Fetching a single document

import { doc, getDoc } from "firebase/firestore";
import { db } from "./firebase-config.js";

async function getTask(taskId) {
  const snapshot = await getDoc(doc(db, "tasks", taskId));
  if (snapshot.exists()) {
    console.log(snapshot.id, snapshot.data());
  } else {
    console.log("No such task.");
  }
}

getTask("task-001");

Fetching an entire collection

import { collection, getDocs } from "firebase/firestore";
import { db } from "./firebase-config.js";

async function getAllTasks() {
  const snapshot = await getDocs(collection(db, "tasks"));
  snapshot.forEach((doc) => {
    console.log(doc.id, doc.data());
  });
}

getAllTasks();

Filtering with queries

import { collection, query, where, orderBy, limit, getDocs } from "firebase/firestore";
import { db } from "./firebase-config.js";

async function getUrgentPendingTasks() {
  const q = query(
    collection(db, "tasks"),
    where("completed", "==", false),
    orderBy("metadata.priority"),
    limit(10)
  );

  const snapshot = await getDocs(q);
  snapshot.forEach((doc) => console.log(doc.id, doc.data()));
}

getUrgentPendingTasks();

Heads up: combining where() on one field with orderBy() on another often requires a composite index. Firestore will throw an error in your console with a direct link to create it. More on this in Debugging.

Real-time updates with onSnapshot()

Instead of fetching once, you can subscribe to live changes. This is useful for a task list that updates instantly across devices:

import { collection, onSnapshot } from "firebase/firestore";
import { db } from "./firebase-config.js";

const unsubscribe = onSnapshot(collection(db, "tasks"), (snapshot) => {
  snapshot.docChanges().forEach((change) => {
    console.log(change.type, change.doc.id, change.doc.data());
  });
});

// Call unsubscribe() when you no longer need updates (e.g., component unmount)

Step 5 – Update: Modifying Tasks

Partial update with updateDoc()

Unlike setDoc(), updateDoc() only touches the fields you specify. Everything else on the document stays untouched.

import { doc, updateDoc } from "firebase/firestore";
import { db } from "./firebase-config.js";

async function completeTask(taskId) {
  await updateDoc(doc(db, "tasks", taskId), {
    completed: true,
  });
}

completeTask("task-001");

Updating a nested field with dot notation

You don't need to rewrite the whole metadata map to change one property inside it:

await updateDoc(doc(db, "tasks", "task-001"), {
  "metadata.priority": "low",
});

Updating arrays safely

Directly overwriting an array field is risky in concurrent scenarios. Use arrayUnion() and arrayRemove() instead:

import { doc, updateDoc, arrayUnion, arrayRemove } from "firebase/firestore";
import { db } from "./firebase-config.js";

async function addTag(taskId, tag) {
  await updateDoc(doc(db, "tasks", taskId), {
    tags: arrayUnion(tag),
  });
}

async function removeTag(taskId, tag) {
  await updateDoc(doc(db, "tasks", taskId), {
    tags: arrayRemove(tag),
  });
}

arrayUnion() won't add a duplicate value, and arrayRemove() removes every matching instance. Both operate atomically on the server.

Step 6 – Delete: Removing Tasks

Deleting a document

import { doc, deleteDoc } from "firebase/firestore";
import { db } from "./firebase-config.js";

async function deleteTask(taskId) {
  await deleteDoc(doc(db, "tasks", taskId));
}

deleteTask("task-001");

The subcollection trap

Here's the gotcha mentioned earlier: deleting tasks/task-001 does not delete its comments subcollection. Those comment documents become orphaned, they still exist in your database. They're just unreachable through the UI unless you know the path.

To clean up properly, delete the subcollection's documents first, then the parent:

import { collection, getDocs, doc, deleteDoc, writeBatch } from "firebase/firestore";
import { db } from "./firebase-config.js";

async function deleteTaskWithComments(taskId) {
  const commentsRef = collection(db, "tasks", taskId, "comments");
  const commentsSnapshot = await getDocs(commentsRef);

  const batch = writeBatch(db);
  commentsSnapshot.forEach((commentDoc) => {
    batch.delete(commentDoc.ref);
  });
  batch.delete(doc(db, "tasks", taskId));

  await batch.commit();
}

deleteTaskWithComments("task-001");

writeBatch() groups multiple deletes into one atomic operation. Either all of them succeed, or none do.

Deleting a single field

If you only want to remove one field without deleting the whole document, use deleteField():

import { doc, updateDoc, deleteField } from "firebase/firestore";
import { db } from "./firebase-config.js";

await updateDoc(doc(db, "tasks", "task-001"), {
  metadata: deleteField(),
});

Debugging Common Issues

FirebaseError: Missing or insufficient permissions

Your security rules are blocking the request. If you're still in test mode, check whether your 30-day window expired (rules revert to deny-all after that). For a real app, review your rules in Firestore and then Rules and make sure they match the paths you're reading/writing, including subcollections, which need their own rule blocks.

Function addDoc() called with invalid data. Unsupported field value: undefined

Firestore rejects undefined values outright, unlike null, which is allowed. This usually happens when a form field is empty and you pass it straight into your write call. Filter out undefined fields before writing, or default them to null.

The query requires an index

This shows up when you combine where() and orderBy() on different fields, as in the Step 4 example. Firestore can't serve that query with automatic indexes. The error message includes a direct link that pre-fills the composite index for you in the console, click it, wait a minute or two for the index to build, and rerun your query.

Reads adding up fast / quota warnings

Every document returned by getDocs() counts as a read, even inside a loop calling getDoc() repeatedly. Avoid fetching a whole collection just to filter it client-side, push filtering into your query with where() instead, and use limit() on anything that could grow unbounded.

Orphaned subcollections after delete

If you notice documents you thought you deleted still consuming storage or showing up in exports, check for subcollections under the deleted document's path. As shown in Step 6, deleteDoc() never cascades, cleanup is always your responsibility.

Conclusion

You now have a working mental model of Firestore's structure and hands-on experience with every CRUD operation using the Web SDK v9+. Here's a quick recap:

From here, there are a few natural next steps once you're comfortable with the basics:

• Transactions, for reads and writes that must succeed or fail together (for example, transferring a task between two users)

• Batch writes, which you already saw in Step 6. They're useful anytime you need to touch multiple documents atomically

• Composite indexes, for more advanced filtering and sorting combinations

• Pagination with startAfter(), for loading large collections in chunks instead of all at once

If you haven't already, it's worth revisiting how to model your data before you write queries against it. Decisions made at the modeling stage (like whether to nest data or use a subcollection) directly shape which of these CRUD patterns will feel natural versus awkward later on.

The result? Complex queries, skyrocketing read costs, and a database structure that becomes a nightmare to maintain after just a few features.

To understand how Firestore works, we first need to look at our point of comparison: the relational model. Once we map out how SQL does things, we can see exactly where Firestore diverges, and how to structure NoSQL data correctly.

In this guide, we'll cover NoSQL design principles, embedding vs. referencing, and relationship modeling (1-1, 1-N, N-N). We'll also walk through a concrete blog case study.

Table of Contents

1. Prerequisites

2. The Relational Mindset: How SQL Handles Data

3. The Firestore Paradigm: NoSQL with Relationships

4. The Core Building Blocks: Documents and Collections

5. The Golden Rule: Model for Reads, Not Writes

6. Embedding vs. Referencing (Denormalization)

7. How to Model Relationships (1-1, 1-N, N-N)

8. Best Practices and Pitfalls to Avoid

9. Case Study: Designing a Scalable Blog Database

Prerequisites

This guide is conceptual, so you don't need a running Firestore project to follow along. A little context is enough. You will need:

• Basic JavaScript syntax, since every code example uses the modular Firebase JS SDK (v9+)

• Basic familiarity with JSON objects (keys, values, nested objects, arrays)

• Some exposure to SQL or relational databases helps, since the guide leans on that comparison throughout (but it's not required)

• (Optional) A free Firebase project, if you want to try the examples yourself. The Firestore quickstart walks you through setting one up.

No prior NoSQL or Firestore experience is needed.

The Relational Mindset: How SQL Handles Data

In a relational database, data is organized into tables linked by explicit relationships. This approach relies on normalization to eliminate data redundancy.

For example, to store users and their respective countries, we split the data into two tables:

• Users: columns id (PK), last_name, first_name, #country_id (FK a foreign key)

• Countries: columns country_id (PK), country_name

With a row like 1, MINTOUMBA, Caleb, 1 in Users and 1, Canada in Countries, we automatically know that Caleb belongs to Canada through the foreign key #country_id. We never had to write the word "Canada" inside the Users table itself.

The SQL trade-off: writes are lightweight (you only update data in one place), but reads are heavier, because you have to perform a database join (JOIN) every time you want to display a user's country name.

That's exactly the opposite of how Firestore works, as we'll see next.

The Firestore Paradigm: NoSQL with Relationships

Firestore is a NoSQL document database – literally Not Only SQL. It stores JSON-like documents grouped into collections, with no enforced schema.

For most of Firestore's history, that also meant no native joins and no GROUP BY. The standard query engine simply didn't support them, and any aggregation beyond count(), sum(), and average() had to happen in your application code.

That's still true today for Standard edition, which remains the default and the one most mobile/web apps run on and the one this guide focuses on.

Google has since introduced Firestore Enterprise edition, built around a new Pipeline query engine that reached general availability in April 2026. Pipelines add a multi-stage query syntax and hundreds of new functions, including relational-style joins through correlated subqueries and a real aggregate(...) step with grouping Firestore's equivalent of SQL's GROUP BY.

Does this mean data modeling doesn't matter anymore? Not for most apps. Pipeline queries run within a 60-second timeout and a 128 MiB working-memory limit, can fall back to full collection scans when no index exists, and critically, Enterprise edition drops real-time listeners and offline support (which most Firestore client apps depend on).

Pipelines are a genuine escape hatch for analytical, admin, or reporting queries. They're not a drop-in replacement for the read-optimized structure your app's everyday screens still need.

If you're building a typical client-facing app on Standard edition, the embedding and denormalization strategies below are still how you model relationships.

But NoSQL doesn't mean "no relationships" even on Standard edition. You can and should build robust relationships between your collections. The difference is that Firestore won't enforce or resolve them for you the way a JOIN does by default. It's up to you, the developer, to build and query those relationships explicitly, and to maintain data integrity through your application code or Cloud Functions unless you've specifically opted into Enterprise edition for Pipeline-powered joins.

The Core Building Blocks: Documents and Collections

Before designing any schema, let's define Firestore's two core building blocks:

• Document: the basic unit of storage. It's a JSON-like object, identified by a unique ID, containing typed fields (strings, numbers, booleans, timestamps, geopoints, or references to other documents).

• Collection: a container for documents. Unlike SQL tables, documents in the same collection don't need to share the same structure.

What makes Firestore unique is its hierarchical nature: a document can contain sub-collections, which contain more documents, which can themselves contain more sub-collections, and so on.

In the diagram above, the root posts collection contains the document post_001, which itself hosts a comments sub-collection containing the individual comment documents comment_001 and comment_002. You can nest collections and documents several levels deep, but as we'll see later, it's best to do so sparingly.

Crucial rule: sub-collections are never retrieved automatically when you read a parent document. Unlike a SQL JOIN, you must always perform a separate, explicit query to read a sub-collection.

The Golden Rule: Model for Reads, Not Writes

This is the single most important concept in NoSQL modeling, and the one developers coming from SQL forget most often: structure your data based on how your app queries it, not on how it gets written.

Before writing any database code, ask yourself:

• Which screens in my app will display this data?

• Do I need this piece of data on its own, or always alongside another one?

• Do I read this information significantly more often than I write or update it?

If your users view a writer's profile 10,000 times for every single time that writer updates their username, optimize for the reads: duplicate the username directly inside each post. That's the exact opposite of the SQL instinct we saw earlier, where you normalize first to avoid redundancy, even if it makes reads heavier.

Embedding vs. Referencing (Denormalization)

There are two primary strategies for representing a relationship in Firestore.

Option A: Embedding (Nesting)

You store the related data directly inside the parent document, as an array or a map (object).

// A post with its comments embedded
{
  title: "Introduction to Firestore",
  author: "Caleb",
  comments: [
    { user: "Ama", text: "Great post!" },
    { user: "Kofi", text: "Thanks for the examples" }
  ]
}

• Pros: a single read retrieves everything, and consistency is guaranteed.

• Cons: Firestore documents have a hard 1 MB size limit. If the nested list grows indefinitely (comments on a viral post, for instance), your writes will start failing once you hit that limit and every write to the parent document also re-sends the whole document to any client listening in real time.

• Best for: small, bounded lists (tags on an article, a user's settings, a short list of favorites).

Option B: Referencing (Denormalization)

You split the entities into separate collections or sub-collections, and deliberately duplicate a few fields to avoid a second read.

// posts/post_001
{
  title: "Introduction to Firestore",
  authorId: "uid_123",
  authorName: "Caleb",      // denormalized: avoids a second read to "users"
  authorAvatar: "https://...",
  commentCount: 12          // denormalized counter
}

// posts/post_001/comments/comment_001
{
  userId: "uid_456",
  userName: "Ama",
  text: "Great post!",
  createdAt: Timestamp
}

Here, we duplicate the author's name and avatar into every post so we don't need an extra read to users every time the post list is displayed.

That's denormalization: we accept controlled redundancy in exchange for faster reads the exact opposite of SQL normalization. The cost is that these copies need updating if the user changes their name (usually handled by a Cloud Function triggered when the users document is updated).

• Pros: no document size limits, and entities can be queried independently.

• Cons: requires multiple reads if you didn't denormalize enough. If a duplicated value changes, you need code (often a Cloud Function) to propagate the update everywhere it's copied.

• Best for: dynamic, fast-growing data (comments, order history, activity logs).

A more precise rule of thumb: whether to reference instead of embed depends on volume. Sub-collections handle unbounded growth (comments, order history) better than arrays.

Whether to denormalize a given field depends on the cost of keeping it in sync, not how often it changes: a counter you update in place with an atomic increment (commentCount, likeCount) has no other copy to synchronize, so it's cheap to denormalize regardless of frequency.

A copied value like authorName, on the other hand, is duplicated across every document that references it. It's safe to denormalize only if it changes rarely, since any change means propagating the update everywhere it's been copied.

How to Model Relationships (1-1, 1-N, N-N)

One-to-One (1-1)

Either embed the fields in the same document, or store them in a separate collection using the exact same document ID, for example users/uid_123 and privateProfiles/uid_123. This is perfect for separating public data from sensitive data that needs different security rules.

One-to-Many (1-N)

There are three main options, depending on volume and query direction:

1. A sub-collection (posts/post_001/comments/*) is ideal when you almost always query comments through their parent post, and volume can be large.

2. A root collection with a reference (comments with a postId field) is useful if you also need to query all comments by a given user, independently of the post (where("userId", "==", uid)).

3. Use an embedded array only if the volume stays small and bounded (see Option A above).

Many-to-Many (N-N)

This is the trickiest one in NoSQL, since there's no automatic join table like in SQL. There are three common patterns:

(1). Junction collection the equivalent of a SQL pivot table:

// memberships/{membershipId}
{
  userId: "uid_123",
  groupId: "group_789",
  role: "admin",
  joinedAt: Timestamp
}

You can then query .where("userId", "==", uid) to find all groups a user belongs to, or .where("groupId", "==", gid) to find all members of a group.

(2). ID arrays on both sides (cross-denormalization):

// users/uid_123      -> groupIds: ["group_789", "group_456"]
// groups/group_789   -> memberIds: ["uid_123", "uid_456"]

Fast to read from either side, but reserve this for lists that stay small the 1 MB document limit and the cost of atomically updating long arrays both work against you at scale.

(3). Hybrid approach, which is the most common pattern in practice: an array for a lightweight relationship rarely queried from the other side (a user's favorite posts), and a junction collection for a relationship queried frequently in both directions and prone to frequent changes (team memberships).

Best Practices and Pitfalls to Avoid

• Limit nesting depth: Firestore allows sub-collections to be nested indefinitely, but beyond two or three levels, your queries and security rules become genuinely hard to maintain. Prefer flattening the structure with references when you can.

• Avoid auto-incremented document IDs: Sequential IDs (user_1, user_2, user_3...) can cause hotspotting: writes pile up on a narrow range of the index, which degrades performance at scale. Let Firestore generate random, evenly distributed IDs unless you have a specific reason not to.

• Watch out for composite indexes: Any query combining multiple .where() filters, or a .where() with an .orderBy() on a different field, requires a composite index. Plan for these during design rather than discovering them in production (Firestore's error messages include a direct link to auto-generate the missing index).

• Mind the write rate on "hot" documents: The recommended maximum sustained write rate to a single document is about 1 write per second. A document updated very frequently by many different users a global like counter, for example becomes a bottleneck well before that. Firestore can absorb short bursts (5, 10, even 50 writes in one second) by queuing them, but sustained traffic above ~1 write/sec will start producing contention errors. The standard fix is a sharded counter: split the count across several sub-documents and sum them at read time.

• Use sub-collections deliberately: They're convenient, but they always require a separate query. If you almost always need the data together, embedding or denormalization will perform better.

• Design security rules alongside your data model: Firestore's security rules (firestore.rules) should be designed at the same time as your schema a poorly thought-out structure usually makes precise rules much harder to write.

Case Study: Designing a Scalable Blog Database

Let's bring every principle from this guide together with a concrete example: a blog with posts, comments, and likes.

// posts/{postId}
{
  title: "Modeling Firestore",
  slug: "modeling-firestore",
  authorId: "uid_123",
  authorName: "Caleb",         // denormalized: avoids a second read to "users"
  content: "...",
  tags: ["firebase", "nosql"], // embedded: small, bounded list
  commentCount: 3,             // denormalized counter
  likeCount: 47,               // denormalized counter (shard it if traffic is high)
  createdAt: Timestamp
}

// posts/{postId}/comments/{commentId}  → sub-collection: read together with the post
{
  userId: "uid_456",
  userName: "Ama",
  text: "Excellent article",
  createdAt: Timestamp
}

// likes/{likeId}  → root collection + reference
{                    // lets you quickly check if ONE user liked ONE post
  postId: "post_001",
  userId: "uid_456"
}

Each choice here answers a specific read pattern. Tags are always displayed alongside the post, so they're embedded. Comments can grow large in number and are almost always fetched together with their parent post, so they live in a sub-collection. Likes need to be queried both by post and by user to check whether this user already liked this post so they sit in a root collection with two indexable fields.

Conclusion

In SQL, you normalize to eliminate redundancy, and you pay for that choice at read time, via joins. In Firestore, it's the opposite: you accept controlled redundancy (denormalization) to make reads instant and cheap, at the cost of slightly heavier writes.

Modeling data in Firestore isn't about applying relational habits with a different syntax. It's a genuinely different way of thinking, centered on your app's read patterns.

Always ask "how will I read this data, and how often?" before choosing between embedding, referencing, or a sub-collection. Also, keep Firestore's concrete limits in mind (1 MB per document, composite indexes, hotspotting) from the design phase rather than discovering them in production.

That balance between read simplicity and write cost is what separates a Firestore database that scales gracefully from one you'll be rewriting six months from now.