Interactive Google Cloud Database Chooser

Choose AlloyDB for PostgreSQL for demanding enterprise PostgreSQL and hybrid transactional/analytical (HTAP) workloads (99.99% SLA). Choose Cloud Spanner when you need limitless horizontal SQL write scale or multi-region active-active external consistency (up to 99.999% SLA). Choose Cloud SQL for standard single-region MySQL, PostgreSQL, or SQL Server databases (up to 64TB). Choose Firestore for serverless JSON documents, secondary attribute indexes, and real-time web/mobile sync. Choose Cloud Bigtable for petabyte-scale single row-key or time-series workloads at single-digit millisecond latency. Choose BigQuery for serverless petabyte OLAP analytics, and Memorystore for sub-millisecond in-memory Redis/Valkey caching.

All three are fully managed relational SQL databases with ACID transactions, but they use different compute and storage architectures. Cloud SQL runs managed MySQL, PostgreSQL, and SQL Server on a regional primary VM attached to persistent disk (scaling vertically up to 128 vCPUs and 64TB). AlloyDB disaggregates PostgreSQL compute from a regional log-structured storage layer—delivering 4x faster transactional writes, 99.99% availability inclusive of maintenance, and up to 100x faster analytical queries via an in-memory columnar engine. Cloud Spanner shards relational tables horizontally across unlimited Paxos splits and regions using Google TrueTime for external consistency and a 99.999% SLA.

In standard Cloud SQL PostgreSQL, the primary backend modifies pages in shared_buffers, flushes the write-ahead log (WAL), and periodically writes full dirty 8KB data pages back to persistent disk during checkpoints. In AlloyDB, the primary instance only flushes WAL records to regional log storage on commit and never writes data pages to disk; a disaggregated log-processing service materialises data blocks in the background while streaming WAL updates directly to read pool caches. For reads, AlloyDB checks shared buffers, an in-memory columnar engine (for analytical scans), and a local SSD ultra-fast cache before fetching from storage.

For a strong read, the Spanner frontend routes your SQL query to the nearest replica holding the target data splits; the replica obtains a TrueTime timestamp, confirms with the Paxos split leader that it has applied all writes up to that timestamp, and reads a lock-free multi-version snapshot from Colossus in milliseconds. For a read-write transaction, affected split leaders acquire write locks, coordinate via two-phase commit if multiple splits are involved, assign a TrueTime commit timestamp, replicate the commit log across a Paxos majority quorum, and perform a brief commit wait so the timestamp is guaranteed to be in the past everywhere.

Match your target to how your application queries DynamoDB. Choose Firestore if your DynamoDB tables store nested JSON documents and rely on Global Secondary Indexes (GSIs) or multi-attribute filtering. Choose Cloud Bigtable only if 100% of your reads and writes address a single deterministic Row Key or contiguous Row Key prefix at high throughput (>50,000 ops/sec). Choose Cloud Spanner if you need relational SQL joins, secondary indexes, multi-row ACID transactions, and 99.999% multi-region consistency.

Cloud Bigtable is a wide-column key-value store that indexes strictly by a single lexicographically sorted Row Key. Unlike Firestore, AlloyDB, or AWS DynamoDB (which supports up to 20 GSIs), Bigtable treats column cell values as uninterpreted byte arrays and has no secondary indexes. If you store JSON payloads in a Bigtable cell and filter by a non-key attribute (such as status = "FAILED"), Bigtable cannot use an index and must scan every row across every tablet node.

On a read, BigQuery parses your GoogleSQL query, applies partition and cluster pruning, and fans executionstages out across thousands of parallel Dremel compute slots that read only the referenced Capacitor columnar strips from Colossus storage, exchanging intermediate results through an in-memory shuffle tier. On a streaming write, the BigQuery Storage Write API appends protocol-buffer batches into durable write-optimised storage—making rows queryable via SQL within seconds—before converting and compacting them into compressed columnar files in the background.

Use Cloud Bigtable for operational, high-concurrency, single-digit millisecond (<10ms) point reads, row-key prefix scans, and high-velocity streaming writes (such as IoT telemetry, financial ticks, or ML feature serving). Use BigQuery for analytical (OLAP) SQL queries that aggregate millions or billions of rows across columns in seconds for BI dashboards, reporting, and data warehousing. BigQuery can also query Bigtable directly in place via federated external tables without ETL.

Choose Cloud SQL for MySQL when migrating existing MySQL or AWS RDS/Aurora MySQL applications, CMS platforms, or e-commerce backends that rely on InnoDB clustered primary-key B-trees and binary log replication. Choose Cloud SQL for PostgreSQL when your application needs rich ANSI SQL joins, complex cost-based query plans, MVCC snapshot isolation, JSONB indexing, PostGIS geospatial extensions, or pgvector embeddings on a single regional primary instance.

Yes, qualifying workloads are eligible for Google Cloud migration funding. As a Google Cloud Premier Partner and 2026 Partner of the Year for Australia and New Zealand, Aviato Consulting secures Google Cloud funding to cover upfront database discovery assessments, workload benchmarking, and migration engineering from AWS RDS, Aurora, DynamoDB, Oracle, SQL Server, and Snowflake.