9.1 Deploying Data Products: Cloud SQL, Firestore, Spanner, BigQuery & AlloyDB

Why This Section Matters

Domain 3, "Deploying and implementing a cloud solution," is the single heaviest domain on the Associate Cloud Engineer (ACE) exam at 25% of the exam weight, and the official exam guide's data-solutions bullet -- "Deploying data products (e.g., Cloud SQL, Firestore, BigQuery, Spanner, Pub/Sub, Dataflow, Cloud Storage, AlloyDB)" -- names eight products in a single sentence. That density is a signal: expect several ACE questions that hand you a workload description and ask which database or data product to deploy, then follow up with the exact gcloud/bq command or console setting needed to stand it up correctly. This section covers the five stateful data stores from that bullet -- Cloud SQL, Firestore, Spanner, BigQuery, and AlloyDB. Pub/Sub, Dataflow, and Cloud Storage-based data loading are covered in the next section (9.2), since they behave more like data-movement products than data stores.

The ACE exam does not test SQL syntax or deep database administration theory. It tests which product fits which requirement and what the deployment options are called -- machine tier vs. processing units vs. read pools. Missing this section usually shows up as choosing Cloud SQL for a workload that actually needs Spanner's horizontal scale, or forgetting that Firestore ships in two incompatible modes chosen only once, at creation time.

Core Deployment Concepts by Product

Cloud SQL -- Managed Relational Database

Cloud SQL is Google Cloud's fully managed service for MySQL, PostgreSQL, and SQL Server. You deploy an instance, not a cluster:

gcloud sql instances create orders-db \
  --database-version=POSTGRES_15 \
  --tier=db-custom-4-16384 \
  --region=us-central1 \
  --storage-type=SSD \
  --storage-size=100GB \
  --availability-type=REGIONAL

• --tier selects the machine type (either the older db-n1-standard-* family or the newer db-custom-CPU-RAM naming).
• --storage-type is SSD (default; lower latency) or HDD (cheaper; for rarely accessed data) -- availability depends on the machine series.
• --availability-type=REGIONAL provisions a synchronous standby in a second zone that Cloud SQL fails over to automatically. The default, ZONAL, has no standby.
• Storage auto-increases up to a configurable limit -- no manual disk resizing during normal operation.
• Read replicas (including cross-region replicas) scale reads, but Cloud SQL as a whole scales vertically only: a hard per-instance CPU/RAM ceiling, no built-in horizontal write scaling.

Firestore -- Serverless Document Database

Firestore is a serverless NoSQL document database offered in two mutually exclusive modes, chosen once at database-creation time:

• Native mode -- the modern document model with real-time listeners, mobile/web SDKs, and offline sync. Google recommends Native mode for all new applications.
• Datastore mode -- retained for legacy applications built against the original Datastore API; it removes several old Datastore limits (queries are now strongly consistent, and the 25-entity-group transaction cap is gone).

gcloud firestore databases create \
  --database='catalog-db' \
  --location=nam5 \
  --type=firestore-native

A single project can host multiple Firestore databases -- a (default) database plus additional named ones -- and each independently picks Native or Datastore mode; teams use this to isolate a QA database from production without a second project. --location accepts a single region or a multi-region value (nam5, eur3); multi-region trades a small latency cost for continent-wide durability.

Spanner -- Globally Distributed Relational Database

Cloud Spanner is the product to reach for when a workload needs relational (SQL) semantics at global scale with strong, externally consistent transactions -- something Cloud SQL cannot do, because Cloud SQL is bound to a single region and scales only vertically.

Compute capacity is expressed in processing units (PU):

The instance configuration is chosen at creation and is not something you casually change afterward:

• Regional -- all resources live in a single region (minimum 3 replica servers per node).
• Dual-region -- resources span two regions within one country.
• Multi-region -- resources span multiple regions/continents (minimum 5 replica servers per node) for the strongest availability and the lowest read latency for globally distributed users.

gcloud spanner instances create sales-instance \
  --config=regional-us-central1 --processing-units=100 \
  --description="Sales OLTP"
gcloud spanner databases create sales-db \
  --instance=sales-instance --ddl='CREATE TABLE Orders (...)'

BigQuery -- Serverless Data Warehouse

Deploying a BigQuery workload starts with a dataset -- a top-level container that sets the default location for every table inside it. That location choice is immutable: a dataset created in US cannot later be moved to EU; you must recreate it and copy the data. Inside a dataset you create native tables (data stored in BigQuery), external tables (query data in place in Cloud Storage or Bigtable without loading it first), or views.

bq mk --dataset --location=US myproject:sales_ds
bq mk --table sales_ds.orders schema.json

Two deployment-time features matter for the exam: partitioning (splitting a table by a date/timestamp column, by ingestion time, or by an integer range so queries scan fewer bytes) and clustering (sorting data within each partition by up to four columns). Both reduce bytes scanned -- and therefore cost -- and both are configured only when the table is created.

AlloyDB -- PostgreSQL-Compatible, Disaggregated Architecture

AlloyDB for PostgreSQL separates compute from storage. A cluster contains exactly one primary instance (the writer -- either HA, with an active node and a standby node in different zones, or Basic, a single node for non-production use) plus zero or more read pool instances (up to 20 nodes total across the cluster). Read pool instances all read from the same underlying storage as the primary, so they achieve near-zero replication lag rather than the lag typical of traditional replicas.

gcloud alloydb clusters create sales-cluster --region=us-central1 --network=default
gcloud alloydb instances create sales-primary --cluster=sales-cluster \
  --region=us-central1 --instance-type=PRIMARY

Decision Table: Which Product to Deploy

Exam Scenario

A retailer's checkout service currently runs on a single Cloud SQL for PostgreSQL instance. As the company expands to simultaneous storefronts in the US and the EU, the team needs strict transactional consistency across regions for shared inventory counts, with no single point of failure. Cloud SQL cannot meet this requirement -- it is bound to one region and scales only vertically, and cross-region read replicas would only be eventually consistent. The correct deployment is a Spanner multi-region instance configuration, sized in processing units, which delivers horizontally scalable SQL with cross-region strong consistency.