Learn Google Cloud's serverless NoSQL database by doing: create a database, model data as collections and documents, query with composite indexes, and understand how it scales without capacity planning.
Firestore is a serverless NoSQL document database that scales automatically and syncs in real time. Unlike SQL there are no joins, and you design around how you will READ the data. Why: it scales seamlessly with no servers or capacity to plan, but queries must be backed by an index, so you think about access patterns up front.
Create a Firestore database in Native mode
gcloud firestore databases create \
--location us-central1Firestore stores "documents" (JSON-like records with fields) inside "collections" (named groups). Documents can themselves contain subcollections, forming a hierarchy. Why: this maps naturally to app entities — a "users" collection of user documents, each with an "orders" subcollection.
The model, by example: collection "users" -> document "u-100" -> fields {name, email} subcollection "orders" -> document "order-1" -> {total, status} A document path looks like: users/u-100/orders/order-1
echo "Collections hold documents; documents can hold subcollections."Apps usually read and write Firestore through the client SDKs, but gcloud can manage data too. Why know the shape: a write targets a document path and sets fields; a read fetches by path. Point reads are fast and cheap because Firestore goes straight to the document.
Most apps use the SDK; with the CLI you can inspect collections:
gcloud firestore databases listExport a collection to Cloud Storage (handy for backups/inspection)
gcloud firestore export gs://learn-uploads-7f3k/firestore-backup \
--collection-ids users,ordersFirestore auto-indexes every single field, so simple queries just work. But a query that filters/sorts on multiple fields needs a "composite index" you define. Why: the index is what keeps the query fast at any scale — Firestore refuses queries that would require a slow full scan.
Save this as index.json — a composite index for querying orders by userId and sorting by createdAt
{
"indexes": [{
"collectionGroup": "orders",
"queryScope": "COLLECTION",
"fields": [
{ "fieldPath": "userId", "order": "ASCENDING" },
{ "fieldPath": "createdAt", "order": "DESCENDING" }
]
}]
}Create the index from the definition
gcloud firestore indexes composite create \
--collection-group=orders \
--field-config field-path=userId,order=ascending \
--field-config field-path=createdAt,order=descendingFirestore scales automatically — there is no throughput to provision; you pay per read, write, and delete plus storage. Why this is freeing: you never plan capacity, and it handles traffic spikes for you. Scheduled backups and exports protect against accidental data loss.
Schedule a daily backup, retained for 7 days
gcloud firestore backups schedules create \
--database="(default)" \
--recurrence=daily \
--retention=7d