DevOps Peach

GCP Basics · Storage & Databases – Cloud Storage, Cloud SQL and Choosing a Database · Lesson 4 of 5

Choosing a Database: Firestore, Bigtable, Spanner, AlloyDB, Memorystore

Match the data model and scale to the service: Cloud SQL or AlloyDB for relational apps, Spanner for global relational scale, Firestore for documents, Bigtable for huge key-value time series, Memorystore for caching and BigQuery for analytics.

Practice interactively →

Google Cloud has a managed database for almost every data shape. The right choice depends on the data model, the scale and the consistency you need.

flowchart LR
  Q["What does the workload need?"] --> REL["Relational, SQL, transactions"]
  Q --> DOC["JSON documents, mobile/web, serverless"]
  Q --> KV["Huge key-value, time series, low latency"]
  Q --> CACHE["Sub-millisecond cache"]
  Q --> ANA["Analytics over TBs"]
  REL --> SQL["Cloud SQL, AlloyDB, Spanner"]
  DOC --> FS["Firestore"]
  KV --> BT["Bigtable"]
  CACHE --> MS["Memorystore"]
  ANA --> BQ["BigQuery"]
  %% step Q: Start with the access pattern, not with the product you already know.
  %% step SQL: Relational data: Cloud SQL for standard apps, AlloyDB for demanding PostgreSQL, Spanner for global scale.
  %% step FS: Firestore stores documents and syncs them to mobile and web clients in real time.
  %% step BT: Bigtable serves billions of rows with single-digit millisecond latency by row key.
  %% step MS: Memorystore (Valkey, Redis, Memcached) caches hot data in memory.
  %% step BQ: BigQuery is a serverless data warehouse for analytics, not an OLTP database.

The options

Service Model Strengths Watch out
Cloud SQL MySQL, PostgreSQL, SQL Server Familiar engines, easy migration Scales up, not out; one primary for writes
AlloyDB for PostgreSQL PostgreSQL-compatible Much faster transactions and built-in columnar engine for analytics, vector search PostgreSQL only; higher price
Spanner Relational, horizontally scalable Strong consistency across regions, up to 99.999% SLA, no sharding work Schema and key design matter; minimum cost
Firestore Document (collections, documents) Serverless, real-time listeners, offline mobile sync, ACID transactions Query limits; design around access paths
Bigtable Wide-column NoSQL Petabyte scale, high write throughput, HBase API; IoT, ad tech, time series Single-row transactions; everything depends on the row key
Memorystore In-memory key-value Caching, sessions, leaderboards Not a system of record
BigQuery Columnar data warehouse SQL analytics over TBs/PBs Not for many small transactional writes

Quick decision rules

  1. Existing MySQL/PostgreSQL app, one region → Cloud SQL.
  2. PostgreSQL with heavy load or mixed transactions + analytics → AlloyDB.
  3. Global users, relational, must never lose consistency, very large scale → Spanner.
  4. Mobile/web app with flexible documents → Firestore.
  5. Telemetry from millions of devices, read by key and time range → Bigtable.
  6. Speed up reads of anything above → Memorystore.
  7. Reports and dashboards over all of it → BigQuery.

Database Center gives one view of the health, security and cost of your fleet of Cloud SQL, AlloyDB, Spanner, Bigtable, Firestore and Memorystore databases.

Command Meaning
gcloud spanner instances create shop-global --config=regional-asia-southeast1 --processing-units=100 --description=… Small Spanner instance
gcloud firestore databases create --location=asia-southeast1 Firestore database
gcloud bigtable instances create iot --display-name=IoT --cluster-config=id=iot-c1,zone=asia-southeast1-a,nodes=1 Bigtable instance
gcloud redis instances create cache --size=1 --region=asia-southeast1 Memorystore for Redis

Traps: Bigtable with sequential row keys (timestamps first) creates hotspots; Firestore is not for heavy analytics; Spanner is not “just a bigger Cloud SQL” – design the schema for it.

Practice interactively →