Cloud SQL, Spanner, and Firestore are all managed Google Cloud databases, but they represent different contracts with the application. Cloud SQL preserves familiar MySQL, PostgreSQL, or SQL Server relational engines. Spanner provides strongly consistent transactions with horizontal scale and regional or multi-region configurations. Firestore is a serverless document database that scales without capacity provisioning. For Professional Cloud Architect, the correct choice follows the workload’s data model, consistency, scale, query, availability, and operating requirements.
Database selection becomes unreliable when teams start with one headline attribute such as ‘relational,’ ‘global,’ or ‘serverless.’ Modern services overlap. Spanner now supports relational and non-relational patterns; Firestore provides ACID transactions; Cloud SQL can scale reads through replicas and offers managed high-availability options. The decision has to identify which guarantees are required together.
A useful baseline comes from understanding both SQL fundamentals and NoSQL data models. The application contract should state what data looks like, how it is queried, which transactions must be atomic, what latency and consistency users need, how traffic grows, and how much database-specific operational work the team is prepared to own.
Cloud SQL is the natural fit for familiar relational applications
Cloud SQL runs managed MySQL, PostgreSQL, or SQL Server and handles many administrative tasks such as backups, patching, replication, encryption, storage, monitoring, and high-availability mechanisms. It is a strong fit for applications built around standard relational schemas, drivers, SQL features, and ecosystem tooling.
Choose it when the workload fits within the scaling and topology model of a managed relational instance and when engine compatibility matters. Migrating an existing application can be substantially simpler when the application does not need to redesign its data model around a distributed database.
The contract should also name which database capabilities the application cannot easily emulate elsewhere. Complex relational joins, globally consistent multi-row transactions, offline-capable document clients, or engine-specific extensions can become decisive constraints and create migration cost later.
Spanner is for scale and availability without giving up strong transactions
Spanner distributes data and compute across machines and, depending on configuration, regions while maintaining strong transactional consistency. It supports GoogleSQL and PostgreSQL dialects and combines relational semantics with horizontal scaling.
That capability is valuable for global ledgers, large transactional platforms, inventory, identity, or other mission-critical systems where sharding a conventional database would become a major engineering project. The cost is that schema design, key choice, query patterns, and distributed-system behavior still need to be understood.
Cloud SQL is also attractive when application teams need mature ecosystem tooling, familiar extensions, and straightforward compatibility with existing frameworks. The managed service reduces administration without asking developers to relearn the entire data-access model, which can be more valuable than theoretical horizontal scale a workload does not need.
Connection behavior is part of the Cloud SQL contract. Traditional database drivers and connection pools can create limits or operational patterns that serverless application platforms must manage carefully. The managed database removes server administration, not the need for sensible client connection design.
Firestore is a document database with serverless operations
Firestore stores document-oriented data, scales automatically, and uses a pay-per-use model without requiring customers to provision database servers. It can work well for mobile and web applications, user profiles, application state, content, catalogs, and workloads naturally expressed as documents and indexed queries.
Do not choose Firestore merely to avoid schema design. Document databases still require deliberate key structure, document boundaries, index planning, transaction scope, and query modeling. Flexibility moves schema responsibility into the application; it does not remove data architecture.
Spanner schema design still matters because distribution is not free. Primary-key choice, hotspot avoidance, interleaving or locality patterns, and query shape influence performance. Choosing Spanner to avoid sharding does not eliminate the need to understand how the distributed database places and accesses data.
Spanner’s strong consistency does not imply every query should be globally distributed. Location configuration, leader placement, schema keys, and workload geography influence latency. Use global deployment when the business needs it; regional Spanner can be a better fit when data and users are concentrated.
Start with the transaction boundary
Ask which updates must commit atomically and how many records or logical entities the transaction spans. A traditional relational application with joins and familiar transaction semantics may map naturally to Cloud SQL. A globally scaled transactional system may justify Spanner. A document-centric workflow whose atomic operations fit document or supported transaction patterns may fit Firestore.
Model the hardest transaction before choosing the service. A design that handles reads beautifully but cannot express one critical write safely is not a fit.
Firestore document boundaries should follow the application’s access patterns. Embedding everything in one large document can hit size or contention limits, while splitting related state too aggressively can require many reads and more complex transactions. The model should optimize the operations users perform most often.
Firestore indexing requirements should be designed with query needs. Queries generally depend on indexes, and automatic or composite indexes can add storage and write cost. A document model that looks simple can become expensive if every new query shape requires broad indexing over high-write collections.
Query shape can eliminate attractive options
List the most important read paths: point lookups, range scans, joins, ad hoc reporting, indexed document queries, aggregation, geographic access, and operational analytics. Cloud SQL provides mature relational SQL and joins. Spanner supports SQL and large distributed datasets. Firestore expects queries that align with document structure and indexes.
Readers comparing traditional engines can use MySQL and PostgreSQL as background because even within relational systems, query behavior and operational tooling influence architecture. The choice is not just syntax; it is the execution and scaling model behind the query.
Transaction design should include contention. Two services can both support transactions but behave differently when thousands of writers update the same logical key or counter. Model the highest-contention operation, not only the average transaction size.
Cross-entity invariants are a useful decision test. If the application frequently needs complex relational constraints or transactions spanning many logical entities, Cloud SQL or Spanner may express the model more naturally. If most operations address self-contained documents, Firestore can reduce relational overhead.
Scale means write rate, data size, geography, and growth shape
A database described as ‘small today’ may still have one property that drives architecture: bursty writes, global users, high read fan-out, or rapid multi-tenant growth. Estimate the expected range rather than the current point.
Cloud SQL can scale vertically and use replicas for read patterns, but an application expecting enormous horizontally distributed transactional load may outgrow that model. Spanner is designed around scale-out. Firestore automatically scales without capacity provisioning, but its document and index design must fit the access patterns.
Query requirements should include ad hoc and operational support. A database chosen purely for application point reads may later frustrate incident responders or analysts who need flexible investigation. If those workflows matter, decide whether the operational database must support them or whether a separate analytical path is part of the architecture.
Availability and locality have to match the business impact
Cloud SQL supports high availability and read replicas, with topology depending on engine and edition. Spanner supports regional and multi-region configurations with automated synchronous replication and very high availability options. Firestore supports highly available regional or multi-region database configurations.
Availability should be translated into failure scenarios: zone loss, regional disruption, maintenance, client failover, and data recovery. A larger SLA number is not a substitute for understanding how the application reconnects and whether dependent services share the same failure domain.
Growth assumptions should include tenant concentration and key distribution. A million evenly distributed users and one customer generating half the writes stress a system differently. Test the skew that is plausible in production because distributed databases and indexes often reveal hotspots under nonuniform demand.
Data growth should also include index growth and backup history, not only primary records. A database with modest live data can still consume significant cost through replicas, indexes, retained versions, and exports. Compare the complete storage and compute footprint.
Operating model and portability have real value
Cloud SQL keeps familiar open-source or SQL Server engines, which can reduce migration and skills friction. Spanner is a distinct distributed database with GoogleSQL or PostgreSQL dialect options and requires teams to learn its scaling and schema patterns. Firestore has its own document API and query model, although it also offers current compatibility options for some MongoDB-style workloads.
The simplest managed service can still create the highest application lock-in if the data model is tightly coupled to unique APIs. Portability may or may not matter, but it should be a conscious trade-off rather than an assumption.
Recovery objectives should consider logical corruption as well as infrastructure failure. Backups, point-in-time recovery, export, and application-level repair can be more important than automatic replica failover when a bad deployment writes incorrect data consistently to every replica.
Choose from the data contract, then prove it under load
Write a short contract: data model, critical transactions, query shapes, consistency, peak read/write volume, geography, availability, recovery, compliance, team skill, and cost sensitivity. Use that to narrow the options, then test representative data distribution and failure behavior rather than a toy dataset.
The broader Professional Cloud Architect certification mindset is to treat database choice as architecture, not product preference. Cloud SQL, Spanner, and Firestore can each be the right answer for a different workload. The right fit is the service whose native guarantees match the application’s hardest requirements with the least unnecessary complexity.
Migration and lock-in should be evaluated against business lifespan. A short-lived internal service may reasonably optimize for developer speed, while a core platform expected to run for a decade may place greater value on familiar interfaces, portability, or a database that can absorb several orders of magnitude of growth without re-platforming.
Before final selection, build one realistic slice of the workload on the leading option. Include schema, writes, reads, failover or retry, observability, migration tooling, and operational access. The purpose is to validate the hardest assumptions, not to benchmark every product exhaustively.
