Databases / Google Cloud

Google Cloud databases.

Google Cloud spans conventional managed SQL, distributed transactions, document applications, large key-oriented datasets, and analytics. The right service depends on the workload and the engine your application already expects.

← All databases and providers

How to build the shortlist.

  1. Start with Cloud SQL when an established PostgreSQL, MySQL, or SQL Server engine fits. Compare AlloyDB for a PostgreSQL workload with measured reasons to evaluate a different managed architecture.
  2. Evaluate Spanner when distributed relational writes and regional placement justify the coordination. Global readers alone do not establish that need.
  3. Keep Firestore documents, Bigtable row-key access, BigQuery analytics, and Memorystore caching tied to their distinct application jobs.

Review the exact product, region, version, and service configuration before making a production decision. Sources checked September 8, 2026.

Provider’s database overview ↗

7 engines and services to compare.

Google Cloud · Managed service

Google AlloyDB for PostgreSQL

Relational

Google Cloud; PostgreSQL-compatible service

When to consider it

Consider AlloyDB for a PostgreSQL application whose measured transactional or mixed query workload justifies evaluating a specialized managed service. Compare it directly with Cloud SQL using the same queries.

What to check

PostgreSQL compatibility does not make every extension or operating procedure identical. Check supported features, instance sizing, migration effort, and total service cost.

Official documentation ↗

Google Cloud · Analytics platform

Google BigQuery

Analytics

Google Cloud; managed analytical warehouse

When to consider it

Consider BigQuery for shared SQL analysis over large datasets, recurring reporting, and data engineering workloads. It separates the analytical job from the database serving application transactions.

What to check

Control scans, partition data around actual queries, and evaluate the chosen compute pricing model. Ingestion freshness, workload concurrency, and transfer costs belong in the design.

Official documentation ↗

Google Cloud · Managed service

Google Cloud Bigtable

Wide-column / Time series

Google Cloud; distributed wide-column store

When to consider it

Evaluate Bigtable for large key-oriented datasets, high ingestion rates, and access over ordered row-key ranges. Telemetry and event histories can fit when their query patterns drive the key design.

What to check

Row-key design is central: hot ranges and unbounded scans can dominate behavior. Wide-column storage is different from an analytical columnar warehouse and does not provide a relational join model.

Official documentation ↗

Google Cloud · Managed service

Google Cloud Firestore

Document

Google Cloud; document database with distinct editions and modes

When to consider it

Useful for applications organized around documents, including web and mobile backends. Its managed model and client-facing capabilities can reduce the amount of backend infrastructure you operate.

What to check

Choose the edition and mode deliberately. Query indexes, transaction limits, security rules, read charges, and client access patterns matter; do not treat a document store as an automatic substitute for relational joins.

Official documentation ↗

Google Cloud · Managed service

Google Cloud Memorystore

Cache / Key-value

Google Cloud; managed Valkey, Redis, and Memcached offerings

When to consider it

A managed option for caching hot records, session access, and other memory-oriented operations alongside an authoritative database. Select the particular engine and deployment that match the application.

What to check

Command support, persistence, failover, and clustering vary by offering. Define eviction and cache rebuilding; a fast managed cache does not remove invalidation or durability decisions.

Official documentation ↗

Google Cloud · Managed service

Google Cloud Spanner

Relational / Distributed SQL

Google Cloud; distributed database with GoogleSQL and PostgreSQL dialects

When to consider it

A candidate for relational transactions that need horizontal distribution and coordinated consistency across a regional or multi-region deployment. Evaluate it when a single primary database becomes a demonstrated constraint.

What to check

Distributed transactions add coordination. Model keys and locality carefully, and verify SQL dialect, feature support, regional configuration, and cost before assuming an existing PostgreSQL application will transfer unchanged.

Official documentation ↗

Google Cloud · Managed service

Google Cloud SQL

Relational

Google Cloud; PostgreSQL, MySQL, or SQL Server engine

When to consider it

A managed home for applications using established relational engines. Consider it when you want conventional SQL, transactions, and familiar drivers while Google handles infrastructure maintenance.

What to check

Select the engine first. Extensions, administrative access, high availability, supported versions, and recovery options differ from an unrestricted self-managed installation.

Official documentation ↗

Compare other providers.

Continue your work

Take the next step.