Subcollections in Firebase - Deep Dive

Overview - Subcollections

What is it?

Subcollections are smaller groups of data nested inside a document in a database. They let you organize related information under a main item, like chapters inside a book. Each subcollection can have its own documents and data. This helps keep data tidy and easy to find.

Why it matters

Without subcollections, all data would be mixed together in one big list, making it hard to find or manage related information. Subcollections solve this by grouping data logically, so apps run faster and users get the right info quickly. This structure also helps when scaling apps with lots of data.

Where it fits

Before learning subcollections, you should understand basic collections and documents in Firebase. After mastering subcollections, you can explore advanced querying, security rules for nested data, and data modeling best practices.

Mental Model

Core Idea

Subcollections are like folders inside a file that hold related smaller files, helping organize data neatly under a main document.

Think of it like...

Imagine a filing cabinet where each drawer is a collection, each folder inside a drawer is a document, and inside that folder, you have smaller folders (subcollections) holding related papers. This keeps everything organized and easy to find.

Collection (Drawer)
│
├─ Document (Folder)
│  ├─ Subcollection (Smaller Folder)
│  │  ├─ Document (Paper 1)
│  │  └─ Document (Paper 2)
│  └─ Document (Another Paper)
└─ Document (Another Folder)

Build-Up - 6 Steps

1

Foundation

Understanding Collections and Documents

Concept: Learn what collections and documents are in Firebase to build a base for subcollections.

In Firebase, data is stored in collections, which are like lists of items. Each item is a document that holds data as fields. For example, a 'users' collection holds documents for each user, with fields like name and email.

Result

You can store and retrieve simple data organized in collections and documents.

Knowing collections and documents is essential because subcollections build directly on this structure.

2

Foundation

What Are Subcollections?

Concept: Introduce subcollections as collections inside documents.

A subcollection is a collection nested inside a document. For example, a user document can have a subcollection called 'orders' that holds all orders made by that user. Each order is a document inside the subcollection.

Result

You understand that data can be nested, allowing more detailed organization.

Recognizing that documents can contain collections helps you model complex data naturally.

3

Intermediate

Accessing Subcollections in Code

🤔Before reading on: do you think you access subcollections the same way as top-level collections or differently? Commit to your answer.

Concept: Learn how to read and write data in subcollections using Firebase SDK.

To access a subcollection, you first get a reference to the parent document, then call the subcollection method. For example, in JavaScript: const userRef = firestore.collection('users').doc('user123'); const ordersRef = userRef.collection('orders'); You can then add or get documents from 'ordersRef'.

Result

You can programmatically work with nested data, not just flat lists.

Understanding the two-step reference process prevents confusion and errors when working with nested data.

4

Intermediate

Why Use Subcollections Instead of Big Documents?

🤔Before reading on: do you think storing all data in one big document is better or worse than using subcollections? Commit to your answer.

Concept: Explore the benefits of splitting data into subcollections versus one large document.

Big documents can become slow to read or write because Firebase downloads the whole document each time. Subcollections let you split data into smaller parts, so you only load what you need. For example, loading a user’s profile separately from their orders improves speed.

Result

You know when to break data into subcollections for better performance.

Knowing how data size affects performance helps you design efficient databases.

5

Advanced

Security Rules for Subcollections

🤔Before reading on: do you think security rules for subcollections are the same as for top-level collections? Commit to your answer.

Concept: Learn how to write security rules that protect subcollections properly.

Firebase security rules apply to collections and subcollections separately. You must write rules for each subcollection path. For example: match /users/{userId}/orders/{orderId} { allow read, write: if request.auth.uid == userId; } This ensures only the user can access their orders.

Result

You can secure nested data correctly, preventing unauthorized access.

Understanding path-based rules prevents security holes in nested data.

6

Expert

Subcollections and Query Limitations

🤔Before reading on: can you query across multiple subcollections at once in Firebase? Commit to your answer.

Concept: Discover the limits of querying subcollections and how to work around them.

Firebase does not support queries that span multiple subcollections directly. Each subcollection is separate. To get data across many subcollections, you must query each one individually or use collection group queries, which search all subcollections with the same name across documents. Example: firestore.collectionGroup('orders').where('status', '==', 'pending') This finds all 'orders' subcollections with pending status.

Result

You know how to query nested data efficiently despite limitations.

Knowing collection group queries unlocks powerful cross-subcollection searches.

Under the Hood

Firebase stores data in a hierarchical tree structure. Each document is a node that can have child collections as branches. When you access a subcollection, Firebase uses the full path including parent document IDs to locate data. This design allows flexible nesting but treats each collection as a separate entity internally.

Why designed this way?

This structure balances flexibility and performance. It avoids huge documents by splitting data, and the path-based addressing makes security and queries straightforward. Alternatives like deeply nested JSON would be harder to secure and query efficiently.

Root
│
├─ Collection: users
│  ├─ Document: user123
│  │  ├─ Subcollection: orders
│  │  │  ├─ Document: orderA
│  │  │  └─ Document: orderB
│  │  └─ Subcollection: messages
│  │     └─ Document: msg1
│  └─ Document: user456
│     └─ Subcollection: orders
│        └─ Document: orderC

Myth Busters - 4 Common Misconceptions

Quick: Do you think subcollections are stored inside the parent document's data? Commit to yes or no.

Common Belief: Subcollections are just fields inside the parent document.

Reality: Subcollections are separate collections stored independently, not inside the parent document's data fields.

Why it matters: Thinking subcollections are inside documents leads to wrong assumptions about data size limits and performance.

Quick: Can you query all subcollections with different names in one query? Commit to yes or no.

Common Belief: You can query across any subcollections regardless of their names.

Reality: Firebase only supports collection group queries on subcollections with the same name across documents.

Why it matters: Expecting cross-subcollection queries without collection group queries causes inefficient or impossible data retrieval.

Quick: Do you think security rules on a parent collection automatically apply to its subcollections? Commit to yes or no.

Common Belief: Security rules on a parent collection cover all its subcollections.

Reality: Each subcollection needs its own security rules; parent rules do not cascade down.

Why it matters: Missing rules on subcollections can expose sensitive data unintentionally.

Quick: Is it better to store all related data in one big document instead of using subcollections? Commit to yes or no.

Common Belief: One big document is simpler and better for performance.

Reality: Large documents slow down reads and writes; subcollections improve performance by splitting data.

Why it matters: Ignoring this leads to slow apps and poor user experience.

Expert Zone

1

Subcollections do not count towards the parent document's size limit, allowing flexible data growth.

2

Collection group queries require careful indexing setup to maintain performance at scale.

3

Security rules for subcollections can be combined with custom claims for fine-grained access control.

When NOT to use

Avoid subcollections when your data is flat and simple; use single collections with documents instead. For complex queries across unrelated data, consider using a relational database or a different NoSQL design.

Production Patterns

In production, subcollections are used to model one-to-many relationships like users and their posts or orders. Collection group queries enable global searches like finding all pending orders across users. Security rules are layered per collection and subcollection to enforce strict access control.

Connections

Hierarchical File Systems

Subcollections mirror folder structures inside folders.

Understanding file systems helps grasp how nested data is organized and accessed in databases.

Relational Database Foreign Keys

Subcollections represent one-to-many relationships similar to foreign keys linking tables.

Knowing relational models clarifies why subcollections separate related data for efficiency and clarity.

Object-Oriented Programming Composition

Subcollections are like objects containing other objects as parts.

Seeing data as composed objects helps design nested data models intuitively.

Common Pitfalls

#1 Trying to store all related data inside one document causing size limits and slow performance.

Wrong approach:

firestore.collection('users').doc('user123').set({
name: 'Alice',
orders: [{id: 'order1', item: 'book'}, {id: 'order2', item: 'pen'}]
});

Correct approach:

const userRef = firestore.collection('users').doc('user123');
userRef.set({ name: 'Alice' });
userRef.collection('orders').doc('order1').set({ item: 'book' });
userRef.collection('orders').doc('order2').set({ item: 'pen' });

Root cause:

Misunderstanding that nested arrays inside documents are limited and inefficient compared to subcollections.

#2 Not writing security rules for subcollections, assuming parent rules cover them.

Wrong approach:

match /users/{userId} {
allow read, write: if request.auth.uid == userId;
}
// No rules for /users/{userId}/orders/{orderId}

Correct approach:

match /users/{userId} {
allow read, write: if request.auth.uid == userId;
}
match /users/{userId}/orders/{orderId} {
allow read, write: if request.auth.uid == userId;
}

Root cause:

Assuming security rules cascade automatically to nested collections.

#3 Trying to query multiple subcollections with different names in one query.

Wrong approach:

firestore.collectionGroup('orders').where('status', '==', 'pending').where('type', '==', 'special'); // expecting to query 'orders' and 'purchases'

Correct approach:

firestore.collectionGroup('orders').where('status', '==', 'pending'); // query one subcollection name at a time

Root cause:

Not knowing collection group queries only work on subcollections with the same name.

Key Takeaways

Subcollections let you organize related data nested inside documents, keeping your database clean and efficient.

They are separate collections stored independently, not fields inside documents, which helps with size limits and performance.

Accessing subcollections requires referencing the parent document first, then the subcollection.

Security rules must be written for each subcollection path to protect nested data properly.

Collection group queries enable searching across all subcollections with the same name, overcoming some query limitations.