Databases

Quick Selection Guide

Start here. Each entry is one sentence on when to reach for that database. Read the full service page before committing.

• Cloud SQL — relational workloads on PostgreSQL, MySQL, or SQL Server. The right starting point for most teams.
• AlloyDB — PostgreSQL when you have measured a real performance limit on Cloud SQL.
• Spanner — SQL with ACID transactions at global scale and horizontal write scaling. A different architecture, not a faster Cloud SQL.
• BigQuery — analytical queries over large datasets. Not a transactional database.
• Firestore — document-structured data in mobile or web apps that need real-time sync and offline support.
• Bigtable — very high-throughput time series, IoT telemetry, and operational analytics with known key access patterns.
• Memorystore — caching, session storage, and any workload that needs sub-millisecond latency.

The two most common database selection mistakes: choosing based on familiarity rather than workload fit, and over-anticipating scale requirements that never arrive.

Relational · SQL

Cloud SQL — Postgres, MySQL, SQL Server; regional. AlloyDB — Postgres-only, higher throughput. Spanner — horizontal and global with strong (external) consistency.

Document & wide-column

Firestore — document DB with strong per-document reads and managed scaling; server-side or mobile/web with offline sync. Bigtable — wide-column, very high throughput, low latency for known key patterns; strongly consistent within a cluster.

Analytical

BigQuery — serverless warehouse for large scans and aggregations. Not transactional, not for low-latency lookups.

In-memory cache

Memorystore — Redis/Valkey, sub-millisecond. A cache or session store, not a primary persistent database; Cluster mode shards horizontally.

Pick by data model and scale first. Consistency is often a setting, not a fixed trait — Spanner is strongly consistent, Bigtable is strong within a cluster — so choose it deliberately rather than reading it off a position.

Services in This Chapter