"Which database fits this situation?" is one of the most common question types in Cloud Digital Leader. In the August 2026 revision of the exam guide, Domain 2 (about 18%) asks you to choose the right product for a use case from Cloud Storage, Spanner, Cloud SQL, AlloyDB, Bigtable, BigQuery, and Firestore, to tell the storage classes and Autoclass apart by cost and access frequency, and to explain how to migrate or modernize an existing database in the cloud. Of these, AlloyDB and Autoclass are names that appear for the first time in this revision.
This post first sets out the terms you must know, then covers a decision flow that narrows the choice with four questions, a product-by-product comparison, AlloyDB, storage classes and Autoclass, database migration, and data products for hybrid and multicloud. The basics of each service are covered first in Data Transformation, and the conceptual differences between databases, data warehouses, and data lakes in Data Fundamentals.
---
Terms You Need First
Just as every dish has the right bowl, every kind of data has the right store. You serve soup in a bowl and cake on a plate; once you know the shape and use of the data, the store follows. The exam guide checks whether you can define these terms.
| Term | Meaning | |------|------| | Relational database | Stores data in tables and the relationships between them; the structure is defined in advance and consistency is strong | | Non-relational database (NoSQL) | Stores data in flexible structures such as documents, key-value pairs, or wide columns; strong at large-scale growth | | SQL | The standard language for querying and changing relational data | | Object storage | Stores files as objects that bundle data and metadata, with unlimited capacity and access by URL | | Transaction | A unit of work in which several operations all succeed or are all canceled, so the data never ends up inconsistent (for example, a bank transfer) | | Vertical vs. horizontal scaling | Making one server more powerful vs. adding more servers |
Exam tip: "Several steps, like a bank transfer, must succeed or fail together" is a relational database transaction. "Flexible data whose structure changes often, at large scale" is NoSQL.
---
Which Store? Narrow It Down with Four Questions
There are seven options, but asking just four questions in order narrows most cases down to one.
!A flow that uses four questions to choose among Cloud Storage, BigQuery, three relational options, and two NoSQL options
Is it an object such as a file, image, video, or backup? Then Cloud Storage Is the goal large-scale analytics and BI reporting? Then BigQuery Do you need relational structure and transactions? Then choose among Cloud SQL, AlloyDB, and Spanner by scale and performance If what remains is NoSQL, choose by the kind of data: large volumes such as time series and IoT go to Bigtable, and document data for mobile and web apps goes to Firestore
---
Product-by-Product Comparison
| Product | Type | When it fits | Clues in the question | |------|------|------|------| | Cloud Storage | Object storage | Images, video, backups, data lakes | "Unstructured files," "no capacity limit," "archive" | | Cloud SQL | Managed relational | Typical web apps and business systems on MySQL, PostgreSQL, or SQL Server | "Keep our existing MySQL as is," "reduce management overhead" | | AlloyDB | High-performance PostgreSQL-compatible relational | Performance-critical business systems, running analytical queries directly on transactional data | "PostgreSQL compatible," "transactions and analytics together," "high performance" | | Spanner | Globally distributed relational | Services such as global finance, inventory, and gaming that need strong consistency worldwide | "Worldwide," "scale out horizontally," "99.999% availability" | | Bigtable | Wide-column NoSQL | IoT sensors, time series, ad tech, large-scale personalization | "Millions of operations per second," "millisecond latency," "time series" | | Firestore | Document NoSQL | Mobile and web apps, real-time collaboration, offline sync | "Mobile app," "real-time sync," "serverless" | | BigQuery | Serverless data warehouse | Petabyte-scale SQL analytics and BI | "Large-scale analytics," "SQL without managing servers" |
Exam tip: Once you know you need relational, the last step is scale and performance. A typical app uses Cloud SQL; PostgreSQL compatibility with higher performance and analytics too means AlloyDB; and horizontal scaling at global scale means Spanner.
---
AlloyDB: Faster PostgreSQL, Analytics Included
AlloyDB for PostgreSQL is a fully managed database that is fully compatible with PostgreSQL. Its hallmark is that you keep using existing PostgreSQL tools (psql, pgAdmin) and code while getting much higher performance and analytics capabilities.
Transactions and analytics together (HTAP): run complex analytical queries on live transactional data with less impact on performance and availability Columnar engine: keeps the data analytics needs in memory in a columnar format to speed up analytical queries Read pools: attach read-only instances to spread the read load Index advisor: suggests schema improvements that boost performance AlloyDB Omni: a version you download and run on-premises, in other clouds, or in Kubernetes environments
| Aspect | Cloud SQL | AlloyDB | Spanner | |------|------|------|------| | Engine | MySQL, PostgreSQL, SQL Server | PostgreSQL compatible | Google's distributed database | | How it scales | Mainly a bigger server, plus read replicas | A high-performance primary instance and read pools | Scales both reads and writes horizontally, distributed across regions | | Analytics | Used alongside a separate analytics system | Columnar engine accelerates real-time analytics | Large-scale operational data integrated with analytics | | When it fits | The usual case of moving an existing app as is | Performance-critical business systems, moving off commercial databases | You need one consistent database worldwide |
Exam tip: "PostgreSQL compatible, faster than standard PostgreSQL, and we want to analyze transactional data directly" is AlloyDB. "Regulations require us to run the same database on-premises too" is AlloyDB Omni.
---
Cloud Storage Classes and Autoclass
Cloud Storage lets you choose a storage class based on how often you take data out to use it. It is like keeping the clothes you wear often in the closet and off-season clothes in a storage unit. The storage unit is cheaper to keep things in, but getting them out takes effort.
| Class | Minimum storage duration | Retrieval fees | Access frequency it suits | Example | |------|------|------|------|------| | Standard | None | None | Frequent access | Website images, data under active analysis | | Nearline | 30 days | Yes | About once a month or less | Monthly backups | | Coldline | 90 days | Yes | About once a quarter or less | Disaster recovery copies | | Archive | 365 days | Yes | About once a year or less | Records kept for legal reasons, long-term archives |
Every class has the same durability (99.999999999% per year), and retrieval latency is the same too, in milliseconds. The differences are storage cost, retrieval fees, and minimum storage duration. If you delete data before its minimum storage duration, you are charged for the remaining time.
Autoclass: A Closet That Organizes Itself
With Autoclass turned on, Cloud Storage looks at each object's actual access pattern in the bucket and changes its class automatically.
New objects start in Standard Objects that are not read for a while move to progressively colder classes (the default final class is Nearline, or Archive if you configure it) Objects that are read move back to Standard There are no retrieval fees or early deletion fees; a management fee applies instead Objects smaller than 128 KiB stay in Standard
Exam tip: "Access patterns are unpredictable and we want to cut storage costs without management overhead" is Autoclass. Changing classes by a fixed rule, such as "move to Coldline after 30 days," is Object Lifecycle Management.
---
Ways to Move a Database to the Cloud
There are several ways to move an existing database to the cloud, depending on the effort you put in and the benefit you want. It is like deciding whether to move your furniture as is, buy new furniture, or remodel the house.
| Approach | What it means | Example | Characteristics | |------|------|------|------| | Move as is (rehost) | Install the database as is on a Compute Engine VM | An existing database server moved to a VM | Fastest, but you still handle patching and backups | | Move to a managed service with the same engine | Migrate to a managed service for the same database engine | MySQL → Cloud SQL for MySQL | Google takes over patching and backups | | Modernize to a different engine | Change the database engine as you migrate | Oracle → Cloud SQL for PostgreSQL or AlloyDB | Lower licensing costs, but schema and code must be converted | | Re-architect as cloud native | Redesign the parts that need to scale on a new database | A global order system → Spanner | Biggest benefit, but also the biggest effort |
Database Migration Service is a serverless service that helps you migrate into Cloud SQL and AlloyDB for PostgreSQL. It supports both migrations between the same engine (homogeneous) and between different engines such as Oracle to PostgreSQL (heterogeneous). It copies the full data first, keeps replicating only the changes, and switches over once source and target are in sync, which keeps downtime to a minimum. In heterogeneous migrations, Gemini helps convert schemas and code.
Exam tip: "Move a MySQL database to Cloud SQL with minimal downtime" is Database Migration Service. "We want to get rid of the licensing costs of a commercial database" means modernizing to PostgreSQL-based Cloud SQL or AlloyDB.
---
Data Products f