2.2 Google Cloud Data Management Solutions

Relational, Non-Relational, and Object Storage

Quick Answer: Google Cloud data management products fall into three families. Relational systems (Cloud SQL, Cloud Spanner) store structured rows with strict schemas and SQL (Structured Query Language). Non-relational systems (Firestore, Cloud Bigtable) store flexible, schemaless records optimized for scale or developer speed. Object storage (Cloud Storage) stores blobs of any type and size, accessed by a key rather than queried.

Google Cloud Data Management Product Decision Matrix

A practical rule: if the workload is transactional and relational, start with Cloud SQL; if it must be global and strongly consistent, choose Spanner; if it is high-throughput and schema-flexible, use Bigtable or Firestore; if it is analytics, use BigQuery; if it is a file or blob, use Cloud Storage.

Updated-exam addition - AlloyDB. The exam guide effective August 12, 2026 adds AlloyDB to the products you must be able to place. AlloyDB is Google Cloud's PostgreSQL-compatible database built for demanding enterprise workloads: it keeps full PostgreSQL compatibility (so migration is a replatform, not a rewrite) while delivering substantially higher transactional throughput than standard Cloud SQL and adding a built-in columnar engine that runs analytical queries on live operational data. Position it between Cloud SQL and Spanner: choose Cloud SQL for ordinary managed PostgreSQL, AlloyDB when PostgreSQL compatibility must be preserved but performance has outgrown Cloud SQL, and Spanner when the requirement is globally distributed strong consistency.

BigQuery: Serverless, Managed, Multicloud Analytics

BigQuery is Google Cloud's serverless, fully managed enterprise data warehouse and analytics engine. Its defining properties:

• Serverless: no infrastructure to provision, patch, or scale. Capacity is allocated automatically per query.
• Managed warehouse: storage, indexing, caching, and compute are handled by Google. You load or stream data in, then query it with standard SQL.
• Analytics engine: BigQuery is not just storage. It runs fast, distributed SQL across petabytes, supports ML (BigQuery ML), geospatial analysis, and federated queries against external data.
• Pay-per-query: pricing is based on bytes processed (for queries) and bytes stored (for storage), not on idle servers. This aligns cost to actual use.
• Multicloud via BigQuery Omni: BigQuery Omni lets you run BigQuery analytics against data stored in AWS S3 or Azure Blob without moving it into Google Cloud, addressing multicloud and data-residency constraints.

Common use cases: replacing an on-prem data warehouse, building a single source of truth, ad-hoc exploration, dashboard backends for Looker, and training ML models without exporting data.

Cloud Storage Classes: Match Cost to Access Frequency

Cloud Storage stores immutable objects in buckets. Classes differ in price, access frequency assumptions, minimum storage duration, and availability SLA. Choosing the right class is one of the most common exam scenarios.

Two price components matter: storage price (lower for colder classes) and retrieval price (higher for colder classes). The right choice minimizes the combined cost. An object accessed daily should be Standard; an object accessed once a year should be Archive. Misclassifying hot data as Archive can cost more in retrieval fees than the storage savings - and because every class carries a minimum storage duration, deleting or rewriting an Archive object before 365 days still bills you for the full 365.

Exam trap - all four classes are equally fast. Cloud Storage classes differ in price, not in access speed. Google states that Archive data "is available within milliseconds, not hours or days," which is a deliberate contrast with the multi-hour thaw times other cloud providers impose on their coldest tiers. If a question offers "retrieval takes several hours" as a property of Archive, that option is wrong. What actually changes as you go colder is the storage price (down), the retrieval price (up), and the minimum storage duration (up).

Updated-exam addition - Autoclass. The exam guide that takes effect on August 12, 2026 adds Autoclass to this list. Autoclass is a bucket-level setting that moves each object between Standard, Nearline, Coldline, and Archive automatically based on that object's own access pattern, with no early-deletion or retrieval charges. It is the right answer when a customer wants class-based savings but cannot predict or does not want to manage access patterns per object.

Database Migration and Modernization Paths

Organizations rarely build greenfield; they migrate existing databases. Google Cloud supports multiple paths:

1. Lift-and-shift — move a database to a managed service with minimal change, for example, on-prem MySQL to Cloud SQL. Lowest risk, fastest, but leaves the schema and architecture as-is.
2. Refactor / modernize — change the schema or engine to a cloud-native option, for example, moving from a single-region relational database to Cloud Spanner for global scale, or from a custom key-value store to Bigtable. Higher effort, greater long-term benefit.
3. Database Migration Service (DMS) — a managed migration service that streamlines moving databases to Google Cloud with minimal downtime, using continuous replication to keep source and target in sync until cutover.
4. Native tools — engine-specific tools such as pg_dump/pg_restore for PostgreSQL, SQL Server Import/Export, and third-party ETL (Extract, Transform, Load) for large-scale reshaping.

The right path depends on urgency, risk tolerance, and the desired end state. Many migrations start with lift-and-shift to retire data-center contracts quickly, then refactor over time.