Cloud SQL, Spanner, or Firestore? Start With the Data Problem

Cloud database decisions often go wrong when teams begin with product reputation rather than workload behavior. Cloud SQL, Spanner, and Firestore can all store application data, but they solve different problems. The choice should follow transaction semantics, access patterns, scale, consistency, schema shape, regional requirements, and operating model.

That decision style is central to the Professional Cloud Architect exam and the Google Professional Cloud Architect role. An architect should be able to explain why a familiar relational database is sufficient, why horizontal relational scale is required, or why a document model removes friction. Choosing the most powerful service by default is not architecture.

Start by writing down what the application must guarantee. Database names should appear later.

Cloud SQL is often the right answer when ordinary relational behavior is enough

Cloud SQL provides managed MySQL, PostgreSQL, and SQL Server. It fits applications that benefit from familiar relational schemas, SQL transactions, established tools, and ecosystem compatibility without needing to operate the database engine themselves.

The basic distinction between an operational database and a data warehouse matters here. Cloud SQL is designed for transactional application workloads, not as a replacement for an analytical warehouse such as BigQuery. Mixing those purposes can create contention and unnecessary complexity.

Cloud SQL still requires architectural decisions around machine sizing, high availability, read replicas, backups, connection management, maintenance, and regional placement. Managed does not mean consequence-free.

Spanner is for relational correctness at much larger distributed scale

Spanner keeps relational concepts and strong transactional consistency while scaling horizontally. It is appropriate when an application needs SQL semantics and transactions but must grow beyond the practical single-instance shape of a conventional relational database or operate across wider geographic boundaries.

That capability is valuable, but it changes schema and access considerations. Keys, hotspots, index design, query shape, and locality all affect performance. A team should choose Spanner because distributed scale or availability is a real requirement, not because it is the premium Google database.

Strong data modeling is especially important because the physical consequences of keys and relationships remain relevant even in a managed distributed system. The cloud can automate replication without making an inefficient access pattern disappear.

Firestore fits document-oriented application state

Firestore is a serverless document database suited to applications that naturally read and write document-shaped entities and value automatic scaling with minimal database administration. It can simplify development when the application’s access pattern maps cleanly to documents and collections.

The document model should be intentional. If the team constantly needs relational joins, complex cross-entity transactions, or reporting queries that fight the document shape, a relational database may produce a simpler system.

Conversely, forcing rapidly changing, nested application state into highly normalized relational tables can add unnecessary joins and development overhead. Data model and access pattern should agree.

Transaction boundaries reveal the real requirement

Ask which changes must succeed or fail together. A financial transfer may require strict transactional semantics across several records. A user preference update may only need one document write. An event log may accept append-oriented storage and downstream processing.

Foundational database skills are still relevant in cloud design because isolation, indexes, constraints, transactions, and query planning do not disappear when infrastructure becomes managed. Service selection should reinforce the required correctness model.

If the application needs strong invariants, write them down in business language. ‘Inventory must never go below zero’ is more useful than ‘we need ACID’ because it points directly to the transaction that architecture must protect.

Scale is multidimensional

Teams often say they need a database that ‘scales,’ but scale can mean storage size, read throughput, write throughput, geographic distribution, connection count, tenant count, or unpredictable bursts. Different services address those dimensions differently.

Estimate the current and expected workload, then identify which limit is likely to matter first. A modest application with a few thousand transactions per second does not need the same architecture as a global ledger with continuously distributed writes.

Design for credible growth, not imaginary infinity. Over-engineering for a scale the business may never reach can slow delivery and increase cost for years.

Availability and geography affect data choice

Database placement changes latency and failure behavior. A single-region application may favor a regional design with straightforward operations. A global application may need replicas, routing, and a consistency model that remains useful across distance.

Do not assume multi-region is free reliability. Cross-region writes can increase latency, and application behavior during partition or failover still needs to be understood. The database can provide replication, but the user experience must tolerate the chosen topology.

The broader Google Cloud database engineering discipline includes reliability, backup, performance, security, and migration—not just product selection. Those operational characteristics should be evaluated before committing to a data service.

Operational compatibility can be more important than feature depth

Existing applications may depend on PostgreSQL extensions, SQL Server behavior, drivers, stored procedures, ORM assumptions, or third-party tools. A database that looks architecturally elegant can be an expensive migration if those dependencies have to be rewritten.

Cloud SQL can preserve much of a familiar engine while removing infrastructure management. Spanner or Firestore may offer stronger long-term platform qualities but require more application change. The architect should price that change rather than treating modernization as free.

Team expertise also influences incident response. A database that nobody understands under load can be riskier than a simpler service whose behavior the team can diagnose confidently.

Security should follow the data, not the brand

For each candidate, evaluate IAM, network access, encryption, secrets, auditing, backup permissions, and administrative separation. The highest-risk privilege is often not the application account but the human role that can export, delete, restore, or reconfigure the database.

Sensitive data may require stronger project separation, customer-managed keys, retention controls, or access review. Those needs can narrow the acceptable services or change the operational design around them.

Logging should capture meaningful administrative and access events without becoming an uncontrolled store of sensitive query content.

Migration friction should be scored explicitly because it can change the practical answer. A workload that already depends on PostgreSQL extensions, stored procedures, familiar backup tooling, and relational reporting may gain more from a managed Cloud SQL deployment than from a theoretically more scalable redesign. Conversely, an application whose core requirement is globally distributed relational transactions may justify the engineering work needed to adopt Spanner’s model. Firestore can be compelling when application state naturally maps to documents and access paths can be designed around known queries, but forcing a relational workload into documents can shift complexity into application code. For each candidate, include data conversion, query changes, connection behavior, testing, observability, backup and restore, and operator skill requirements in the estimate. Architecture is not only the steady-state product feature set; it is also the cost and risk of getting the workload there and running it correctly afterward.

Make the decision with a workload scorecard

A useful scorecard includes data model, transaction scope, query patterns, scale, regional footprint, consistency, latency, compatibility, migration effort, backup and recovery, security, cost, and team operating skill. Weight the categories that actually affect the business.

Run a proof of concept for the uncertain part. If Spanner is being considered for scale, test the real key design and write distribution. If Firestore is being considered for developer velocity, prototype the hardest query and transaction. If Cloud SQL is the default, load-test connection behavior and failover expectations.

Also define the exit conditions. Cloud SQL may be perfect until write scale or global availability becomes a hard requirement. Firestore may be excellent until a new analytical or relational workload dominates. A decision is safer when the team knows which future signal would cause reevaluation.

Cloud SQL, Spanner, and Firestore are not a maturity ladder. They are different tools. The strongest architecture selects the database whose consistency, model, scale, and operational behavior fit the application—and leaves the others unused unless the workload genuinely needs them.

Migration risk should be part of database selection from the beginning. Moving from a familiar relational engine to a distributed or document model can require schema changes, rewritten queries, new transaction boundaries, and a different testing strategy. Estimate that work before comparing steady-state platform benefits, because the migration may be the largest cost and risk in the first year.

For an existing database, capture a workload profile rather than relying on averages: busiest write periods, largest transactions, hottest tables or documents, long-running queries, connection spikes, storage growth, and recovery behavior. A service that easily handles the average can still fail the real workload if one concentrated pattern exceeds its assumptions.

Build a data-exit plan as well. Backups, exports, change streams, and documented schemas make it easier to recover from a bad application release, migrate later, or meet portability requirements. Managed services reduce administration, but the organization should still know how it would extract authoritative data if the architecture changes.

Cost models should include more than storage and compute. Connection proxies, replicas, cross-region traffic, backup retention, export pipelines, operational tooling, and engineering time can change the economic comparison. A database that is cheaper per unit may be more expensive if it needs custom sharding or continuous manual care.

Test recovery before finalizing the choice. Measure backup restore, point-in-time recovery, replica promotion where applicable, and the application behavior while the database is degraded. Database architecture is partly a promise about how quickly correct state can be restored after something goes wrong.