Creating collections and documents in Firebase - Mechanics & Internals

Overview - Creating collections and documents

What is it?

Creating collections and documents in Firebase means organizing and storing data in a structured way. Collections are like folders that hold documents, and documents are like files that contain your actual data. Each document can have fields with different types of information, such as text, numbers, or lists. This structure helps you keep your data neat and easy to find.

Why it matters

Without collections and documents, storing data would be messy and hard to manage, like throwing all your papers in one big pile. This system lets apps quickly find and update data, making them faster and more reliable. It also helps keep data safe and organized, which is important for apps that many people use at the same time.

Where it fits

Before learning this, you should understand basic database ideas like data and records. After this, you can learn about querying data, security rules, and how to update or delete documents. This topic is a foundation for building apps that save and use data in Firebase.

Mental Model

Core Idea

Collections are containers for documents, and documents hold your data as fields, forming a simple, flexible tree structure for storing app information.

Think of it like...

Think of collections as folders in a filing cabinet, and documents as individual files inside those folders. Each file holds specific information, just like a document holds data fields.

Root
 ├─ Collection (e.g., 'users')
 │    ├─ Document (e.g., 'user123')
 │    │     ├─ Field: name = 'Alice'
 │    │     ├─ Field: age = 30
 │    │     └─ Field: hobbies = ['reading', 'hiking']
 │    └─ Document (e.g., 'user456')
 └─ Collection (e.g., 'posts')
      ├─ Document (e.g., 'post789')
      │     ├─ Field: title = 'Hello World'
      │     └─ Field: content = 'My first post'
      └─ Document (e.g., 'post101')

Build-Up - 7 Steps

1

Foundation

Understanding collections and documents

Concept: Learn what collections and documents are and how they organize data in Firebase.

In Firebase, data is stored in collections and documents. A collection is a group of documents, and a document is a set of key-value pairs called fields. Collections can contain many documents, but documents cannot directly contain other documents. This creates a simple hierarchy to organize data.

Result

You understand that collections hold documents, and documents hold data fields.

Knowing this basic structure helps you visualize how Firebase organizes data, which is different from traditional tables.

2

Foundation

Creating a document inside a collection

Concept: Learn how to add a new document with data to a collection.

To create a document, you first pick a collection name. Then you add a document with a unique ID and fields with data. For example, to add a user, you create a 'users' collection and add a document with fields like name and age. Firebase can generate a random ID or you can specify one.

Result

A new document with your data appears inside the chosen collection.

Understanding how to create documents is the first step to saving data in your app.

3

Intermediate

Automatic vs manual document IDs

🤔Before reading on: do you think using automatic IDs or manual IDs is better for all cases? Commit to your answer.

Concept: Learn the difference between letting Firebase create document IDs or setting your own IDs.

Firebase can create a random unique ID for each document, which is easy and avoids conflicts. Alternatively, you can set your own ID, like a username or email, which helps you find documents by known keys. Choosing depends on your app's needs.

Result

You can create documents with either random or custom IDs, affecting how you access them later.

Knowing when to use automatic or manual IDs helps you design your data for easy access and uniqueness.

4

Intermediate

Nested collections inside documents

🤔Before reading on: do you think documents can contain other documents directly? Commit to your answer.

Concept: Learn that documents can have their own collections, creating deeper data layers.

Documents cannot hold other documents directly, but they can have subcollections. For example, a 'users' document can have a 'posts' collection inside it. This lets you organize related data hierarchically and query it efficiently.

Result

You can build multi-level data structures with collections inside documents.

Understanding nested collections helps you model complex data relationships naturally.

5

Intermediate

Data types in document fields

Concept: Learn about the types of data you can store in document fields.

Fields in documents can hold strings, numbers, booleans, arrays, maps (objects), timestamps, and more. This flexibility lets you store rich data. For example, a 'hobbies' field can be an array of strings, and an 'address' can be a map with street and city.

Result

You can store various data types inside documents to represent real-world information.

Knowing supported data types helps you design documents that fit your app's needs.

6

Advanced

Atomic writes and batch operations

🤔Before reading on: do you think creating multiple documents at once is always safe without special handling? Commit to your answer.

Concept: Learn how to create multiple documents safely in one operation.

Firebase supports batch writes, letting you create or update many documents together. This means either all changes succeed or none do, preventing partial updates. This is important when your data depends on multiple documents being consistent.

Result

You can create multiple documents atomically, ensuring data integrity.

Understanding batch writes prevents bugs from partial data updates in your app.

7

Expert

Performance considerations for collections and documents

🤔Before reading on: do you think having very large documents or collections always improves performance? Commit to your answer.

Concept: Learn how document size and collection structure affect app speed and costs.

Large documents with many fields or deeply nested collections can slow down reads and writes. Also, very large collections can increase query times. Experts design data to keep documents small and collections manageable, sometimes splitting data or using references to optimize performance.

Result

You understand how to structure data for fast, cost-effective app behavior.

Knowing these limits helps you avoid slow or expensive database operations in production.

Under the Hood

Firebase stores data in a NoSQL document database where collections are containers for documents. Each document is a JSON-like object stored with a unique ID. When you create a document, Firebase writes it to its distributed storage system, indexing it for fast retrieval. Subcollections are stored as separate collections linked to their parent document's path. This design allows flexible, scalable data storage without fixed schemas.

Why designed this way?

Firebase chose a document-based model to support flexible, hierarchical data that fits many app needs without rigid tables. This allows developers to evolve their data structure easily. The separation of collections and documents supports scalability and fast queries. Alternatives like relational databases require fixed schemas and complex joins, which can slow down mobile and web apps.

Firebase Database
┌─────────────────────────────┐
│ Collections (containers)    │
│ ┌───────────────┐           │
│ │ Document 1    │           │
│ │ ┌───────────┐ │           │
│ │ │ Fields    │ │           │
│ │ └───────────┘ │           │
│ │ └─ Subcollection ─┐       │
│ │                   │       │
│ │ Document 2        │       │
│ └───────────────────┘       │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Can documents contain other documents directly inside them? Commit to yes or no.

Common Belief: Documents can hold other documents directly inside them like folders.

Reality: Documents cannot contain other documents directly; they can only have subcollections which hold documents.

Why it matters: Thinking documents hold documents directly leads to wrong data models and errors when trying to nest data.

Quick: Is it always better to use manual document IDs instead of automatic ones? Commit to yes or no.

Common Belief: Using manual document IDs is always better because you control the keys.

Reality: Automatic IDs avoid conflicts and are easier for many cases; manual IDs are useful only when you need meaningful keys.

Why it matters: Choosing manual IDs without need can cause ID conflicts and harder scaling.

Quick: Does storing large amounts of data in one document improve performance? Commit to yes or no.

Common Belief: Putting all related data in one big document makes reads faster.

Reality: Large documents slow down reads and writes; splitting data into smaller documents and collections is better.

Why it matters: Ignoring this leads to slow app performance and higher costs.

Quick: Are batch writes just a convenience and not important for data consistency? Commit to yes or no.

Common Belief: Batch writes are only for convenience and don't affect data safety.

Reality: Batch writes ensure atomic operations, preventing partial updates and keeping data consistent.

Why it matters: Not using batch writes can cause inconsistent data and bugs in multi-document updates.

Expert Zone

1

Subcollections are stored separately but linked by path, allowing flexible queries without nested document overhead.

2

Choosing document size affects network usage and latency; smaller documents mean faster sync but more reads.

3

Batch writes have limits on size and number of operations, requiring careful design for large-scale updates.

When NOT to use

Avoid using deeply nested collections when flat data structures with references suffice, as deep nesting can complicate queries. For relational data with complex joins, consider using a SQL database instead of Firestore.

Production Patterns

In production, developers often use automatic IDs for user-generated content and manual IDs for user profiles. They design data with shallow nesting and use batch writes for transactions like order processing. Indexes are created to optimize common queries on collections.

Connections

Relational Databases

Contrast with document-based storage

Understanding collections and documents helps grasp how NoSQL differs from tables and rows, showing tradeoffs in flexibility and querying.

File Systems

Similar hierarchical organization

Knowing how folders and files work in computers clarifies how collections and documents organize data in Firebase.

JSON Data Format

Documents store data as JSON-like objects

Recognizing that documents are JSON objects helps understand data types and nesting in Firebase.

Common Pitfalls

#1 Trying to nest documents directly inside other documents.

Wrong approach:

db.collection('users').doc('user1').doc('post1').set({title: 'Hello'})

Correct approach:

db.collection('users').doc('user1').collection('posts').doc('post1').set({title: 'Hello'})

Root cause:

Misunderstanding that documents cannot contain documents directly; subcollections must be used.

#2 Using manual document IDs without ensuring uniqueness.

Wrong approach:

db.collection('users').doc('john').set({age: 25}); db.collection('users').doc('john').set({age: 30});

Correct approach:

db.collection('users').add({name: 'John', age: 25}); db.collection('users').add({name: 'John', age: 30});

Root cause:

Assuming manual IDs won't conflict; automatic IDs prevent overwriting.

#3 Storing too much data in one document causing slow reads.

Wrong approach:

db.collection('users').doc('user1').set({profile: {...}, posts: [...], comments: [...]})

Correct approach:

db.collection('users').doc('user1').set({profile: {...}}); db.collection('users').doc('user1').collection('posts').add({...});

Root cause:

Not splitting data into smaller documents and collections for performance.

Key Takeaways

Firebase organizes data in collections and documents, like folders and files, for flexible storage.

Documents hold fields with various data types and can have subcollections for nested data.

Choosing between automatic and manual document IDs affects data access and uniqueness.

Batch writes allow multiple document changes to happen safely together, preventing partial updates.

Designing data with small documents and shallow collections improves app performance and scalability.