Cloud SQL & Firestore
GCP Fundamentals
Chapter 6 · Cloud SQL & Firestore
AWS Fundamentals Chapter 6 covered RDS (managed relational) alongside DynamoDB (managed NoSQL). Azure Fundamentals Chapter 6 covered Azure SQL Database alongside Cosmos DB. This chapter closes the third leg of that same relational-plus-NoSQL pairing — Cloud SQL and Firestore — and delivers this three-course arc's own most striking consistency-model finding yet.
Cloud SQL: Managed Relational Databases
Cloud SQL is GCP's managed relational database service, supporting three real engines: MySQL, PostgreSQL, and SQL Server — the same three-engine spread as AWS RDS's own core offering, and directly comparable to Azure SQL Database's own single-engine (SQL Server-based) scope.
High Availability: The Regional Instance
A Cloud SQL instance configured for high availability is called a real regional instance — it runs a primary and a standby in two different zones within the same region, kept in sync via real synchronous replication to each zone's own persistent disk, so every committed write genuinely exists in both zones before the write is confirmed.
Failover itself is real and automatic: a heartbeat system checks the primary's health every second, and if several heartbeats are missed, failover begins. The standby takes over as the new primary using the instance's own shared static IP address, so a connected application reconnects with zero configuration change — real observed unavailability during failover is around 60 seconds. The old primary is then destroyed and rebuilt as the new standby.
Firestore: A Serverless NoSQL Document Database
Firestore is GCP's fully managed, serverless NoSQL document database — data is organized into collections of documents rather than tables of rows, the same real document model as AWS DynamoDB and Azure Cosmos DB's own Core (SQL) API.
A new Firestore database is created in one of two real modes: Native mode, the modern, recommended choice with real-time client sync and offline support, or Datastore mode, kept for compatibility with applications originally built on the older Cloud Datastore service — both modes share the same real underlying infrastructure.
Firestore scales automatically and horizontally, partitioning data across many servers and load-balancing requests with no manual capacity planning, and bills on a real pay-per-request model that can scale down to zero when unused.
A Real, Major Consistency Difference
This is a genuinely different, and genuinely simpler, real design than either sibling course's own NoSQL database. DynamoDB (AWS Fundamentals Chapter 6) makes the reader choose per-request — eventually consistent by default, with a real, roughly one-in-three documented chance of returning briefly stale data, or strongly consistent at double the read cost if explicitly requested. Cosmos DB (Azure Fundamentals Chapter 6) goes even further the other way, exposing a real five-level consistency spectrum the developer configures at the account or container level. Firestore skips that whole decision entirely: consistency is always strong, with nothing to configure and nothing to get wrong.
Three Managed NoSQL Databases, Compared
| Property | AWS DynamoDB | Azure Cosmos DB | GCP Firestore |
|---|---|---|---|
| Consistency model | Choose per-request (eventual default, strong optional) | Five-level spectrum, set at account/container level | Always strong — no choice to make |
| Real API surface | DynamoDB API | Six wire-compatible APIs | Native mode or Datastore-compatible mode |
| Scaling model | Provisioned or on-demand capacity | Provisioned or serverless throughput (RU/s) | Fully automatic, pay-per-request |
Relational vs. NoSQL: When to Use Which
- Cloud SQL (relational) — structured, related data that benefits from real joins, transactions, and a fixed schema — the same use case AWS Fundamentals and Azure Fundamentals both already reach for RDS and Azure SQL Database.
- Firestore (NoSQL) — flexible, hierarchical, or rapidly-changing data, especially where real-time client sync or offline support matters, such as a mobile app's own live data feed.
Hands-On Exercises
A team scales up read traffic on their Cloud SQL instance and routes some of that traffic to the HA standby instance to spread the load. Explain, in your own words, why this will not work, and what they should use instead.
📄 View solutionA developer moving from DynamoDB to Firestore looks for a way to explicitly request an eventually consistent read, expecting it to be cheaper than a strongly consistent one, the way it is on DynamoDB. Explain, in your own words, what they will find, and why.
📄 View solutionA team is migrating an existing application that was built directly on the older Cloud Datastore service, and does not want to rewrite its data-access code. Explain, in your own words, which Firestore mode lets them do this, and why.
📄 View solutionChapter 6 Quick Reference
- Cloud SQL — managed MySQL, PostgreSQL, or SQL Server; HA via a regional instance (primary + standby in different zones, synchronous replication, ~60s automatic failover)
- The HA standby cannot serve reads — use a separate read replica for that
- Firestore — serverless NoSQL document database; Native mode (modern) or Datastore mode (compatibility)
- Real, major finding: Firestore is always strongly consistent — genuinely simpler than DynamoDB's per-request choice or Cosmos DB's five-level spectrum
- Relational (Cloud SQL) for structured/related data; NoSQL (Firestore) for flexible, hierarchical, or real-time-synced data