What is Managed Databases — Cloud SQL, Spanner & Firestore in Google Cloud?

4 / 24

Google Cloud

Managed Databases — Cloud SQL, Spanner & Firestore

Pick managed relational (Cloud SQL), global relational (Spanner), or serverless NoSQL (Firestore).

Four options, and the interview is about matching one to the requirement.

Cloud SQL is a well-run local bank branch. Spanner is a single global bank that somehow keeps every branch perfectly in sync to the microsecond (TrueTime) while serving the whole planet. Firestore is a live shared notebook that instantly reflects edits on every device.

Key Concepts

    Cloud SQL  managed MySQL, PostgreSQL, SQL Server. Regional.
    Spanner    relational AND horizontally scalable, global,
               strongly consistent.
    Firestore  serverless document store, real-time listeners.
    Bigtable   wide-column, petabyte scale, key-range access.

Cloud SQL is the ordinary answer and usually the right one. Managed backups, replicas and failover, with the engine you already know. Its ceiling is vertical: one primary, scaled by machine size.

    HA          a synchronous standby in another zone, automatic failover
    read replicas  asynchronous, for read scaling, can be cross-region

Those two solve different problems, and conflating them is a common error: HA is availability, replicas are throughput, and a replica is not a backup.

Spanner is the one worth explaining properly. It offers SQL, relational schemas and transactions while scaling horizontally, with external consistency across regions — the strongest guarantee available, achieved using TrueTime, where GPS and atomic clocks bound clock uncertainty so the system can order transactions globally.

The cost of that is real money, so Spanner is justified by a genuine need for global scale with relational semantics, not by preference.

Its schema design matters as much as any NoSQL store. Primary keys that increase monotonically — timestamps, sequential ids — create hotspots in the key space, so you hash or reverse them. Interleaved tables physically co-locate child rows with their parent to make joins local.

Firestore for application data with live updates and offline support. Bigtable for enormous append-heavy time series read by key range.

And BigQuery is not in this list — it is an analytical warehouse, not a transactional database, however tempting its SQL makes it look.

What the interviewer is probing.1. "When is Spanner justified?" Probing: whether you can resist reaching for it. Stalls: "When you need scale." Moves up: when you genuinely need relational semantics with horizontal scale and multi-region strong consistency — it is expensive, and Cloud SQL covers most workloads.

2. "What is external consistency and how does Spanner achieve it?" Probing: TrueTime. Stalls: "It is just strong consistency." Moves up: transactions are globally ordered as if serial; TrueTime uses GPS and atomic clocks to bound clock uncertainty so the ordering holds across regions.

3. "Is a read replica a backup?" Probing: a dangerous conflation. Stalls: "Yes, it is a copy." Moves up: no — a delete replicates too; replicas are for read scaling and backups are for recovery.

4. "What breaks a Spanner schema at scale?" Probing: hotspotting. Stalls: "Too much data." Moves up: a monotonically increasing primary key concentrates writes in one key range; hash or reverse it, and interleave child tables to keep joins local.