Lesson 1: Every Google Cloud Database on One Page

Why start with a map

When someone asks you to "pick a database on Google Cloud", the first trap isn't technical. It's vocabulary. Old blog posts say Cloud Spanner, Terraform modules say google_datastore_*, and a colleague swears Memorystore "only does Redis". Before you can compare services, you need one up-to-date page that shows what exists, what each service is compatible with, what it used to be called, and whether you can still start new work on it.

Think of this level as the floor plan of a building before you tour the rooms. Each service gets its own level later. Here you only learn where everything sits.

The lineup, grouped by type

Three things the table makes clear:

• Graph and time series are not separate products. Graph is a capability inside Spanner. Time-series data usually goes to Bigtable, because a row key such as sensor#2026-10-25T10:00 suits its sorted, wide-column design.
• "Omni" means you run it yourself. AlloyDB Omni and Spanner Omni are the same engines, packaged so you can run them in your own data centre, on a laptop or in another cloud. Google does not operate them for you.
• Firestore is one product with several faces. Native mode, Datastore mode and MongoDB compatibility all sit on the same storage layer. Which one you get depends on the mode and edition you pick when you create the database.

Name changes that confuse searches and code

Cloud Spanner        -> Spanner            (same product, shorter brand)
Cloud Bigtable       -> Bigtable           (same product)
Cloud Datastore      -> Firestore in Datastore mode
                        (same Datastore API, now on Firestore storage)
Memorystore for Redis  ->  NOT renamed. Memorystore for Valkey is a
                        newer sibling and the default recommendation
                        for new in-memory work; Redis remains available.

Gotcha: API and resource names often keep the old brand. Firestore in Datastore mode still answers on datastore.googleapis.com, and many Terraform resources still use datastore or redis in their names. Search the docs for both names.

Datastore mode removed the old Datastore limits. Queries are strongly consistent by default, transactions no longer stop at 25 entity groups, and the one-write-per-second limit per entity group is gone. If an old design document cites those limits, it was written for the pre-Firestore product.

Walkthrough: see what a project already uses

Before you choose anything, check what is already running. This read-only check is safe to run in any project you can view.

# 1. Which database APIs are switched on? (read-only)
gcloud services list --enabled \
  --filter="config.name~(sqladmin|alloydb|spanner|bigtable|firestore|datastore|memorystore|redis|memcache|oracledatabase|datamigration|baremetalsolution)" \
  --format="value(config.name)"

# 2. Ask each service for its instances
gcloud sql instances list                 # Cloud SQL (all engines)
gcloud spanner instances list             # Spanner
gcloud bigtable instances list            # Bigtable
gcloud firestore databases list           # Firestore, any mode or edition
gcloud memorystore instances list --location=us-central1   # Valkey
gcloud memcache instances list --region=us-central1        # deprecated service!

Sample output from a typical inherited project:

sqladmin.googleapis.com
firestore.googleapis.com
memcache.googleapis.com     <- flag this: deprecated service in use
redis.googleapis.com

The memcache line deserves a ticket today, not in 2028.

Lifecycle red flags: check before you commit

Memorystore for Memcached is deprecated. Key dates from Google's notice:

• 20 Jan 2026: no longer a recommended service.
• 1 Feb 2027: you can't create instances in new projects unless the project already has them.
• 31 Jan 2029: support ends and the service can no longer be used.

Google recommends moving to Memorystore for Valkey, or to Memorystore for Redis or Redis Cluster.

Bare Metal Solution is moving to an allowlist-only model. Google is steering existing customers towards its Oracle partnership offerings, and in practice that means Oracle Database@Google Cloud. For new Oracle workloads, start there.

Best practice: in any design review, add a "lifecycle status" column next to each component and link the vendor's deprecation page. A service that works fine today can still block your next region or your next project.

Edition gates are not deprecations, but they still matter. Spanner Graph, full-text search and vector search need Spanner Enterprise or Enterprise Plus. MongoDB compatibility needs Firestore Enterprise edition. If you pick the wrong edition, the feature you planned on won't be there.

Key takeaways

• The groups are: relational (Cloud SQL, AlloyDB), distributed SQL (Spanner), document (Firestore in its three forms), wide-column (Bigtable), in-memory (Memorystore), Oracle (Oracle Database@Google Cloud) and migration (Database Migration Service, Datastream).
• Graph is a Spanner feature. Time series has no dedicated service and usually goes to Bigtable.
• Cloud Spanner became Spanner, Cloud Bigtable became Bigtable, and Cloud Datastore became Firestore in Datastore mode. Memorystore for Valkey is a newer sibling of Memorystore for Redis, not a rename.
• "Omni" editions (AlloyDB Omni, Spanner Omni) are self-managed and run anywhere.
• Memorystore for Memcached is deprecated (no new projects from 1 Feb 2027, end of life 31 Jan 2029). Bare Metal Solution is going allowlist-only.