Google Cloud Database Decision Tree

High-Level Breakdown: Every Google Cloud Database & What It Is Optimised For

Walking the Google Cloud database decision tree comes down to matching your data structure, query access pattern, and scaling model to the right storage engine. Below is an engineering breakdown of every database and storage service in the flowchart, what each engine is optimised for, and where teams commonly make mistakes during AWS to Google Cloud or Azure to Google Cloud migrations.

1. Relational SQL Databases (Structured → Operational → Relational)

When your application relies on structured schemas, SQL joins across multiple tables, foreign key constraints, and strict ACID transactions, Google Cloud provides three distinct relational tiers:

Cloud Spanner — Optimised for Global Horizontal Write Scale & 99.999% Availability

• What it is: A globally distributed, strongly consistent relational database service engineered around Google's atomic clock and GPS hardware infrastructure (TrueTime).
• What it is optimised for: Workloads that have outgrown a single primary writer node or require active-active multi-region writes with zero failover downtime and a 99.999% availability SLA (less than 5.26 minutes of permitted downtime per year). Spanner automatically shards tables into splits across nodes as traffic grows, without manual application-level sharding.
• Ideal use cases: Global financial ledgers, high-volume e-commerce inventory and order management, multi-region SaaS control planes, and gaming backends.

AlloyDB for PostgreSQL — Optimised for High-Performance Enterprise PostgreSQL, HTAP & AI

• What it is: A 100% PostgreSQL-compatible database built on a Google-engineered compute layer and a disaggregated, log-structured regional storage engine.
• What it is optimised for: Demanding transactional workloads (4x faster than standard PostgreSQL), real-time operational reporting without ETL via its built-in autopilot in-memory columnar engine (up to 100x faster analytical queries), and enterprise AI applications using pgvector with Google's ScaNN index.
• Ideal use cases: Replacing commercial Oracle or SQL Server licences, upgrading bottlenecked AWS Aurora PostgreSQL clusters, and running hybrid transactional/analytical (HTAP) workloads with a 99.99% SLA that includes maintenance windows.

Cloud SQL — Optimised for Standard Regional PostgreSQL, MySQL & SQL Server

• What it is: A fully managed regional relational database service supporting open-source PostgreSQL, MySQL, and commercial Microsoft SQL Server.
• What it is optimised for: Lift-and-shift migrations and standard cloud-native applications that fit comfortably on a single primary instance (up to 128 vCPUs, 864 GB RAM, and 64 TB storage) with automated regional high-availability standby failover and cross-zone read replicas.
• Ideal use cases: Microservices, CRM/ERP backends, content management systems, and migrating AWS RDS or Azure SQL Database instances with minimal code changes.

2. Non-Relational NoSQL & In-Memory Databases (Structured → Operational → Non-Relational)

When your data is modeled as hierarchical JSON documents, key-value pairs, or ephemeral session state—and you do not require cross-table SQL joins—the decision tree branches across three purpose-built engines:

Firestore (Successor to Cloud Datastore) — Optimised for Serverless JSON Documents & Secondary Indexes

• What it is: Google Cloud's serverless NoSQL document database, superseding legacy Cloud Datastore.
• What it is optimised for: Storing nested JSON documents organized into collections, with automatic indexing on every document attribute and composite indexes for complex multi-field filtering and sorting. Uniquely among serverless document databases, Firestore provides strong global consistency and serializable ACID transactions, plus native iOS, Android, Flutter, and Web SDKs with offline persistence.
• Ideal use cases: Mobile and web application backends, user profiles, product catalogs, and migrating AWS DynamoDB or MongoDB workloads that query on secondary attributes.

Firebase Realtime Database — Optimised for Millisecond WebSocket State Synchronisation

• What it is: A low-latency JSON tree database that synchronises state changes in real time across connected client devices over persistent WebSocket connections.
• What it is optimised for: Tiny, high-frequency state updates (such as online/offline presence indicators, live typing indicators, collaborative whiteboard cursors, and multiplayer game state) where sub-50ms fan-out latency matters more than rich multi-field querying.

Memorystore (for Redis, Valkey & Memcached) — Optimised for Sub-Millisecond In-Memory Caching

• What it is: A fully managed in-memory key-value data store supporting open-source Valkey, Redis, Redis Cluster, and Memcached.
• What it is optimised for: Microsecond-latency read/write operations at millions of requests per second—offloading repetitive queries from primary databases, managing distributed locks, rate limiting API gateways, and serving real-time leaderboards.

3. Analytical & High-Throughput Time-Series Engines (Structured → Analytics)

When your workload ingests, scans, or aggregates massive volumes of structured records for analytics, telemetry, or machine learning, the decision tree splits on a single question: Do you need millisecond single-key updates and point lookups, or serverless SQL scans across columns?

Cloud Bigtable — Optimised for Petabyte Wide-Column Streams & Sub-10ms Key Lookups

• What it is: Google's sparsely populated wide-column NoSQL store (the engine underneath Google Search, Maps, and Gmail), backed by Google's Colossus file system.
• What it is optimised for: Sustained high-throughput writes and reads (10,000 to millions of operations per second) at single-digit millisecond latency, indexed strictly by a single lexicographically sorted Row Key.
• Critical architectural note: Because Bigtable only indexes the Row Key, never store unindexed JSON blobs in Bigtable cells if you intend to filter on nested JSON fields—doing so forces a full-table scan. (Explore this in our Interactive Database Chooser.)

BigQuery — Optimised for Serverless Petabyte SQL Warehousing, BI & Lakehouses

• What it is: A serverless, distributed columnar enterprise data warehouse that decouples storage (Colossus Capacitor format) from compute (Dremel execution trees over Google's Jupiter petabit network).
• What it is optimised for: Ad-hoc ANSI SQL aggregations over terabytes to petabytes of data, Looker business intelligence dashboards (accelerated in-memory via BI Engine), real-time change data capture (Datastream CDC), Apache Iceberg open lakehouses, and in-warehouse machine learning.

4. Unstructured Object & File Storage (Structured → NO)

When storing images, video streams, PDFs, backups, Parquet files, or shared application directories, choose between POSIX file storage and object storage:

• Filestore (Managed NFS): Optimised for workloads that require a traditional POSIX file system mounted simultaneously across multiple Compute Engine VMs or Google Kubernetes Engine (GKE) pods (ReadWriteMany PersistentVolumeClaims) with low-latency file locking.
• Cloud Storage: Optimised for infinitely scalable, 11-nines durable object/blob storage accessed over HTTP/gRPC APIs—powering BigQuery lakehouses, archival backups (Autoclass tiering), CDN media delivery, and Vertex AI training sets.
• Cloud Storage for Firebase: Optimised for mobile and web apps that upload and download user-generated media directly from client devices using Firebase SDKs and user-identity security rules, backed by Google Cloud Storage buckets.