Skip to main content
Google Cloud Platform (GCP)
CHAPTER 12

Firestore and NoSQL Databases

Updated: May 15, 2026
20 min read

# CHAPTER 12

Firestore and NoSQL Databases

1. Introduction

Relational databases (SQL) are excellent for structured data (like banking ledgers), but they are incredibly rigid. If you want to add a new "favoritecolor" column to a massive SQL table, you have to lock the table and alter the schema. Modern mobile and web applications require flexibility and massive horizontal scalability. Enter Firestore—Google's flagship serverless, NoSQL document database. In this chapter, we will explore the schema-less paradigm, understand Documents and Collections, and witness the magic of real-time data synchronization.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Differentiate between SQL (Relational) and NoSQL (Document) databases.
  • Understand the hierarchical structure of Firestore (Collections and Documents).
  • Recognize the benefits of a Serverless database architecture.
  • Identify the use cases for Real-time listeners.
  • Build a basic database structure in the Firestore Console.

3. Beginner-Friendly Explanation

Imagine keeping medical records.
  • SQL (The Rigid Spreadsheet): Every patient MUST have a row, and every row MUST have the exact same columns (Name, Age, Blood Type). If a patient doesn't know their blood type, you leave an awkward blank space. If you want to add "Allergies," you have to redesign the entire spreadsheet for everyone.
  • NoSQL Firestore (The Filing Cabinet): You have a drawer (Collection) labeled "Patients". Inside the drawer are individual manila folders (Documents). Inside John's folder is a piece of paper saying "Age: 30." Inside Mary's folder is a piece of paper saying "Age: 25, Allergies: Peanuts, HasDog: True". The folders don't have to match. They just hold flexible JSON data!

4. Collections and Documents

Firestore is fundamentally structured as a tree.
  1. 1. Collections: Containers for Documents. (e.g., users, messages).
  1. 2. Documents: The actual data, formatted as a JSON object (Key-Value pairs).

*Crucial Rule:* A Collection can only contain Documents. A Document can contain data, AND it can contain "Sub-Collections." Example hierarchy: Collection(users) -> Document(Alice) -> Sub-Collection(orders) -> Document(Order123).

5. Serverless and Real-time Magic

Unlike Cloud SQL, where you provision a specific Virtual Machine (e.g., 4 CPUs, 16GB RAM), Firestore is Serverless. You do not pick hardware. You just start writing data. Google automatically scales the backend from 1 user to 10 million users instantly.

Furthermore, Firestore supports Real-time Listeners. A React or iOS application can "listen" to a specific Document. If the data in the database changes, Firestore instantly pushes the update to the user's phone in milliseconds, without the app needing to refresh! (This is how live chat apps and multiplayer games work).

6. Mini Project: Build a NoSQL Structure

Let's build a flexible database in the console.

Step-by-Step Tutorial:

  1. 1. In the GCP Console, navigate to Firestore.
  1. 2. Click Create Database.
  1. 3. Choose Native mode (The modern standard for web/mobile apps).
  1. 4. Choose a location (e.g., nam5 (United States)). Click Create.
  1. 5. Once initialized, click Start Collection.
  1. 6. Collection ID: type cities.
  1. 7. Document ID: Click "Auto-id" to generate a random string, or type new-york.
  1. 8. Add your flexible data (Fields):
  • Field: name | Type: string | Value: New York City
  • Field: population | Type: number | Value: 8400000
  • Field: iscapital | Type: boolean | Value: false
  1. 9. Click Save.
  1. 10. Click "Add Document" again.
  1. 11. Document ID: type tokyo.
  • Field: name | Type: string | Value: Tokyo
  • Field: hasbullettrain | Type: boolean | Value: true *(Notice how Tokyo has a totally different field than New York? That is the power of NoSQL!)*
  1. 12. Click Save. You have successfully built a flexible NoSQL database!

7. Real-World Scenarios

A startup is building a live food delivery tracking app (like UberEats). They use Firestore. The delivery driver's app constantly updates their GPS coordinates in a Firestore Document. The customer's app is "listening" to that exact Document. As the GPS coordinates change in the database, Firestore instantly pushes the new data to the customer's phone, causing the little car icon to move smoothly across the map in real-time.

8. Best Practices

  • Denormalization: In SQL, you split data into multiple tables and use JOIN statements. Firestore does not support JOINs. If you need to display a user's name next to their comment, you must duplicate (denormalize) the user's name directly inside the comment document. Storage is cheap; database queries are expensive. Optimize for fast reads!

9. Security Tips

  • Firestore Security Rules: If you access Firestore directly from a frontend application (like an iOS app), you MUST write strict "Security Rules." Otherwise, any user can download the entire database. Security Rules evaluate the user's authentication token and explicitly allow/deny reads and writes (e.g., allow read, write: if request.auth.uid == resource.data.authorid).

10. Cost Optimization Tips

  • Pay per Read/Write: Firestore billing is not based on CPU time; it is based on the *number of operations*. You are charged per 100,000 document reads. If you write a bad query that accidentally downloads 50,000 documents just to find one user, you will get a massive bill. Always use specific queries and pagination!

11. CLI / Code Examples

Firestore is generally interacted with via code SDKs. Here is an example in Node.js:
javascript
1234567891011
const { Firestore } = require('@google-cloud/firestore');
const db = new Firestore();

async function addCity() {
  const docRef = db.collection('cities').doc('london');
  await docRef.set({
    name: 'London',
    population: 8900000,
    country: 'UK'
  });
}

12. Exercises

  1. 1. Explain why you cannot perform a SQL JOIN operation in Firestore, and how NoSQL database designers compensate for this limitation.
  1. 2. What is the fundamental billing difference between Cloud SQL (Relational) and Firestore (Serverless NoSQL)?

13. FAQs

Q: Is Firestore the same thing as Firebase? A: Cloud Firestore is the database product. Firebase is Google's massive suite of tools for mobile developers (which includes Authentication, Crash Analytics, Hosting, AND Firestore). You can use Firestore purely through GCP, or seamlessly through the Firebase ecosystem.

14. Interview Questions

  • Q: Contrast the scaling paradigms of a relational database (Cloud SQL) and a serverless document database (Firestore). Why is Firestore inherently more suited for massive, unpredictable read-heavy mobile workloads?
  • Q: A developer has designed a Firestore schema where every time a user logs in, the application downloads the entire users collection, filters it locally on the client, and returns the specific user profile. Identify the catastrophic flaw in this architecture regarding both performance and cost.

15. Summary

In Chapter 12, we broke the rigid rules of relational schemas. We introduced Firestore as a massively scalable, serverless NoSQL database designed for modern web and mobile applications. We explored the flexible hierarchy of Collections and JSON-like Documents, demonstrating how different documents can safely hold completely different data structures. Finally, we recognized the immense power of real-time synchronization and the necessity of optimizing queries to manage operation-based billing.

16. Next Chapter Recommendation

We have a serverless database that scales infinitely without managing servers. Can we do the same thing for our application code? Yes! Proceed to Chapter 13: Cloud Functions Serverless Computing.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·