Chapter 01 · Firestore Foundations, Firebase/Google Cloud, Editions, Modes, Locations, and Lab Setup
Firebase Projects, Google Cloud Projects, Databases, Regions / Multi-Regions, Billing, and Responsibility Boundaries
Separate Firebase projects, Google Cloud projects, Firestore database resources, immutable location choices, billing, free-tier limits, IAM, and managed-service responsibility boundaries.
Learning outcomes
A Firestore application has two planes at once: application developers see Firebase configuration and SDKs, while operators see Google Cloud projects, databases, IAM, locations, billing, logs and quotas. AtlasMart must connect those planes without treating them as the same resource.
Explain how a Firebase project relates to its backing Google Cloud project without collapsing the concepts.
Identify a Firestore database by project ID and database ID and understand the special role of the default database.
Choose a single-region or multi-region location from latency, availability, governance and cost requirements, recognizing that location cannot be changed in place.
Separate free-tier eligibility from the existence of a Firebase project and identify features that require billing.
Map mobile/web authorization, server IAM, database operations and Google-managed infrastructure to the correct responsibility boundary.
The reproducible lab pins Firebase CLI 15.30.0, Firebase JavaScript SDK 12.19.0, Firebase Admin Node.js SDK 14.4.0, and Node.js 22 or newer for the Admin SDK. These are a dated lab baseline, not permanent course guarantees. Firestore service capabilities, editions, pricing, locations, emulator fidelity and SDK support continue to evolve; re-check the official documentation before using the commands later.
The generation environment used to build this chapter does not run Firebase Emulator Suite or a billed Google Cloud project. Commands and API shapes were checked against current official documentation, but expected output is described by invariant and evidence shape rather than fabricated as captured output. The mandatory lab uses a Firebase demo project ID and local emulators. Optional production verification must use an isolated test project with explicit billing awareness.
1. One project identity, two product views
When you create a Firebase project, Firebase uses a Google Cloud project underneath. The same project ID appears in both ecosystems, but the consoles and APIs emphasize different capabilities. Firebase centers app configuration, Authentication, client SDKs and Security Rules. Google Cloud exposes IAM, service identities, billing, audit/monitoring surfaces, APIs and resource policies.
This dual view is useful: a web developer can initialize the Firebase SDK with a project ID while a platform engineer grants an IAM role to a workload identity in the same underlying Cloud project. It is dangerous only when teams assume Firebase client configuration is a secret or that Firebase Security Rules automatically govern server credentials.
2. A Firestore database is an explicit resource
A project can contain multiple Firestore databases. Each
database has a database ID; (default) is a special
conventional ID used by many SDK defaults. Named databases are
distinct database resources. Multi-database support is not
permission to hide environment boundaries inside undocumented
IDs: applications should record which database ID they target.
The production resource name conceptually includes both project and database identity. A debugging checklist therefore starts with project ID, database ID, edition/mode and location before it inspects documents. “The document is missing” can simply mean the client is connected to the wrong database or emulator.
| Identifier | Example | Operational question |
|---|---|---|
| Project ID | atlasmart-firestore-test | Which Google Cloud/Firebase project owns the resources? |
| Database ID | (default) or atlasmart-eu | Which Firestore database in that project? |
| Location | us-central1, nam5, … | Where is the database provisioned/replicated? |
| Edition/mode | Standard Native, Enterprise Native, Enterprise MongoDB compatibility | Which query/index/billing contract applies? |
3. Location is a design decision, not a deployment flag to flip later
Firestore requires a location when a database is provisioned. A regional location stores the database within one geographic region across zones. A multi-region location distributes replicas across a defined multi-region topology. Multi-region can increase resilience to regional failure but introduces cost and latency tradeoffs. The correct choice depends on user geography, compute placement, availability targets and governance requirements.
Current Firestore documentation warns that once a database instance is provisioned, its location setting cannot be changed. That makes location an architectural commitment. Migration/clone/export options can move data into a new database through explicit workflows, but that is not the same as editing an in-place location property.
The default Firestore database can share the project's default Google Cloud resource location dependency. If another service set that location first, the database location choice may already be constrained. Check before provisioning.
4. Billing account, pricing model, and free tier are separate concepts
A Firebase project can exist without billable Firestore usage, but production features and usage can require billing. Standard currently provides a free quota for one database per project, including daily document-operation quotas and 1 GiB stored data; features such as TTL deletes, PITR, backup data, restore and clone do not carry free usage under the Standard pricing rules. Enterprise has its own free-tier unit model and pricing.
The engineering rule is to re-check the live pricing page rather than freeze numeric prices in source code or architecture docs. A course lab should stay on emulators when possible. A production test should define a cost ceiling, expected operations and cleanup before it starts.
5. Responsibility boundaries: what Google manages and what AtlasMart owns
Google operates the managed Firestore service: physical database infrastructure, replication mechanisms, service availability and backend patching. AtlasMart still owns data modeling, query/index design, application correctness, Security Rules, IAM, App Check policy, service-account hygiene, retention, backup configuration, monitoring, budgets, incident response and regulatory choices.
High availability does not absolve logical recovery. A multi-region database can remain highly available while an authorized application deletes the wrong documents. Backup/PITR and tested restore procedures address a different failure class than infrastructure replication.
| Concern | Primary owner | Evidence |
|---|---|---|
| Backend infrastructure/replication service | Service documentation/SLA/status | |
| Document model/query/index choices | AtlasMart | Schema/query tests, Query Explain, load tests |
| Browser/mobile authorization | AtlasMart | Security Rules + Auth/App Check tests |
| Server permissions | AtlasMart | IAM policy + application authorization tests |
| Backup/PITR policy | AtlasMart config on managed service | Recovery drill |
| Billing/budgets | AtlasMart | Billing reports, budgets, usage metrics |
6. Optional cloud evidence path: inspect, do not mutate blindly
The mandatory lab stays local. If you have an explicitly disposable Google Cloud/Firebase test project, database-management commands can make identity and configuration observable. The following examples are read-oriented after provisioning; the creation command is shown so you understand the contract, not as a request to run it against an existing project.
# Example only: choose a disposable PROJECT_ID and LOCATION first.gcloud config set project PROJECT_ID# Create a Standard Native database with an explicit ID/location.gcloud firestore databases create \ --database=atlasmart-lab \ --location=LOCATION \ --edition=standard \ --type=firestore-native \ --delete-protection# Evidence commandsgcloud firestore databases listgcloud firestore databases describe --database=atlasmart-labfirebase firestore:databases:list --project PROJECT_IDRecord the returned project/database identity, edition, type, location and delete-protection state. Do not treat console screenshots alone as the audit record. Never delete or recreate a database simply to make a tutorial match your environment.
7. Wrong approach: “move the region later if latency is bad”
Location is not a casual tuning knob. If AtlasMart chooses a location far from its users and compute, the fix can require moving data to another database and changing application routing. This is a migration project with validation, not a property update.
The repair is to benchmark from representative user/backend regions before launch, document data-residency requirements, decide regional versus multi-region availability, and keep latency-sensitive compute near the database when appropriate. The cost of this planning is far lower than a rushed data migration.
8. Project/database checklist before any SDK code
# Chapter 01 resource identity recordfirebase_project_id: demo-atlasmart-firestoregoogle_cloud_project_id: demo-atlasmart-firestoredatabase_id: (default)mandatory_environment: emulatorfirestore_emulator_host: 127.0.0.1:8080auth_emulator_host: 127.0.0.1:9099production_location: NOT_PROVENproduction_edition: NOT_PROVENbilling_account: NOT_APPLICABLE_TO_DEMO_PROJECTclient_authz: Security Rulestrusted_server_authz: IAM + application authorizationUnknown production facts should remain marked unknown. Replacing unknowns with guesses makes a lab look complete while destroying its diagnostic value.
9. Production judgment and bridge
Before provisioning a real database, AtlasMart should have an approved location, edition/mode choice, owner, budget/alerts, Security Rules strategy, server IAM strategy, backup/recovery requirement and data-classification decision. The database creation event is then an implementation of a design—not the start of the design.
The next lesson turns that resource contract into working SDK/CLI configuration and verifies real read/write behavior against the local emulator.
Knowledge check
Check your understanding
- Can a Firebase project contain more than one Firestore database?
- Why is database location considered a long-lived architectural decision?
- Does a multi-region database eliminate the need for backups or PITR?
- Why should a demo-project emulator lab mark production location as unknown?
- Which control protects privileged server-library access to Firestore?
Review the answers
1. Yes. A project can contain multiple databases, each with its own database ID and configuration. The default database is simply a special conventional ID.
2. Firestore requires a location at provisioning time and current documentation says the database location cannot be changed in place. Moving later is an explicit migration/clone/export-and-cutover problem.
3. No. Replication addresses infrastructure availability; backups/PITR address logical deletion/corruption and recovery objectives. They solve different failure classes.
4. Because the emulator is local and has no production Firestore location. Claiming a region from local configuration would fabricate evidence.
5. Server client libraries use Google credentials and IAM; they bypass Firestore Security Rules. The application must also enforce its own business authorization.
Summary and next step
Chapter 01 keeps Firestore claims tied to an observable state surface: client versus server, emulator versus production, project versus database, and Standard versus Enterprise/mode. Preserve the lab evidence and do not convert unknown production facts into assumptions.
Next, continue to Create a Database, Configure SDKs/CLI, Use Emulator Suite Where Appropriate, and Verify Reads/Writes.
Authoritative references
- Cloud Firestore documentation — Official product documentation entry point.
- Firestore editions overview — Current Standard/Enterprise feature and indexing distinctions.
- Firestore Enterprise edition modes — Native Core/Pipeline and MongoDB compatibility mode boundaries.
- Firestore in Native mode / Pipeline operations — Current Enterprise Native operation model.
- Firestore security overview — Client Security Rules/App Check versus server IAM trust paths.
- Connect to the Firestore Emulator — Emulator connection guidance and documented differences from production.
- Firebase release notes — Current Firebase CLI and SDK versions.
- Manage Firestore databases — Database IDs, creation, listing, update and delete protection.
- Firestore locations — Current location semantics and immutability warning.
- Firestore Standard pricing — Current billing/free-quota model.
- Firestore quotas — Current limits and free-tier eligibility.