Theory
A cloud database from Firebase
You have already used Firebase for authentication and hosting. Firebase also offers a database: Firestore, a NoSQL, cloud-hosted store that FestConnect can use directly, sometimes instead of a separate MongoDB backend, and that can update the app in real time as data changes.
Firestore's data model will feel familiar from MongoDB: documents grouped into collections. This lesson covers setting it up, its collections-and-documents structure (including subcollections), and basic CRUD. It rounds out FestConnect's data options.
Theory
Collections, documents, subcollections
Firestore organises data in a clear hierarchy.
A collection is a group of documents (think 'events'). A document is a JSON-like record with fields (one event's name, date, seats) and a unique id. Crucially, a document can itself contain subcollections, nested collections, so an event document could hold a 'registrations' subcollection of who signed up.
This nesting lets you model related data naturally: top-level collections for main entities, subcollections for things that belong to a specific document. It is a NoSQL model, flexible and JSON-shaped, like MongoDB but hosted and managed entirely by Firebase.
Practical
Firestore CRUD (modular Web SDK)
import { getFirestore, collection, addDoc,
getDocs, updateDoc, deleteDoc, doc } from 'firebase/firestore';
const db = getFirestore();
// create: add a document to the 'events' collection
await addDoc(collection(db, 'events'), { name: 'Robotics', seats: 50 });
// read: get all documents in the collection
const snap = await getDocs(collection(db, 'events'));
snap.forEach(d => console.log(d.id, d.data()));
// update / delete a specific document by id
await updateDoc(doc(db, 'events', id), { seats: 40 });
await deleteDoc(doc(db, 'events', id));This example runs in Gri-Learn on the web, where you can edit it and see the output.
Formula
Firestore vs the Realtime Database
Firebase actually offers two databases. Firestore is the newer, document-and-collection store with richer querying and structure, the recommended default for most apps. The Realtime Database is the older one, which stores everything as one big JSON tree; it is simple and very fast for basic real-time syncing but harder to structure and query as data grows.
Both can push live updates, but Firestore's organised model (collections, documents, subcollections) scales better. For FestConnect, Firestore is the sensible choice. Know that both exist, and that Firestore is the modern, structured option.
Quiz
In Firestore, how is data organised?
- As tables with fixed rows and columns, like SQL
- As collections of documents (JSON-like records), where a document can contain nested subcollections
- As a single flat text file
- As images only
Show the answer
As collections of documents (JSON-like records), where a document can contain nested subcollections
Firestore is a document NoSQL database: data lives in collections of documents (JSON-like records with fields and an id), and a document can contain subcollections, allowing natural nesting (e.g. an event document with a registrations subcollection). Option A describes a relational/SQL model with rigid tables, rows, and columns, which is not how Firestore (a NoSQL store) works. Option C is wrong: it is a structured, queryable database, not a single flat file. Option D is nonsense; Firestore stores structured data of any kind, not just images. Remember the hierarchy: collections contain documents, and documents can contain subcollections.
Think first
What does 'real-time' actually give you compared with a normal request?
Firestore can update your app in real time. How is that different from fetching data with a normal request, and why does it matter? Then tap.
Show the answer
A normal request is a ONE-TIME pull: you ask for the data, you get its current state, and you are done, if the data changes afterward, your app has no idea until it asks again. Real-time listening (Firestore's onSnapshot) is a standing SUBSCRIPTION: you tell Firestore 'notify me whenever this data changes', and it PUSHES every update to your app automatically, so your UI stays in sync with the database live, without you polling. Why this matters: for collaborative or live features, it is transformative. Imagine FestConnect showing how many seats remain for an event. With one-time fetches, one user's screen could say '5 seats left' long after they have all been taken by others, stale and misleading, unless the user manually refreshes. With a real-time listener, the instant someone registers and the count drops, every viewer's screen updates by itself to '4 left', then '3', giving an always-current view. The same power drives live chats, collaborative documents, dashboards, and notifications, anywhere multiple users or devices must see the latest state promptly. The trade-off is that live listeners consume a connection and should be managed (unsubscribed when not needed), and not every screen needs real-time. But when freshness matters, real-time updates turn a static snapshot into a living view, which is one of Firebase's standout strengths. Subscribe once, and the data keeps itself current.
Summary
Key takeaways
- Firestore is Firebase's document-based NoSQL cloud database.
- Data is organised as collections of documents (JSON-like records); a document can contain nested subcollections.
- Set up a Firebase project, enable Firestore, then use the SDK for CRUD.
- CRUD: addDoc/setDoc (create), getDocs/getDoc (read), updateDoc (update), deleteDoc (delete).
- Firestore can push real-time updates (onSnapshot) so the UI stays in sync with the database live.
- Firebase's older Realtime Database stores one JSON tree; Firestore is the newer, more structured, recommended option.
- Memory hook: collections hold documents, documents can hold subcollections; Firestore can update the app in real time.