Google Cloud Database Solutions

Why Databases Matter for the Cloud Digital Leader

Every modern application — from a mobile banking app to an IoT fleet of delivery scooters — ultimately stores its state in a database. For the Cloud Digital Leader (CDL) exam, you are not expected to write SQL queries or design indexes. Instead, you are expected to act as a business translator: when a project manager describes a workload, you must point to the correct Google Cloud database service and justify why.

Google Cloud offers a deliberately wide portfolio because no single database can serve every workload well. A globally consistent financial ledger has fundamentally different requirements from a real-time chat application or an IoT telemetry stream. The CDL portfolio is divided across relational (Cloud SQL, AlloyDB, Cloud Spanner) and NoSQL (Firestore, Bigtable, Memorystore) families, plus the analytical world (BigQuery, covered separately in data-warehousing-bigquery).

This study note walks through each service at a business-leader altitude: the headline use case, the trade-offs, the migration story from on-premises systems, and the decision shortcuts that show up repeatedly on the CDL exam. By the end you should be able to confidently say "this workload belongs on Cloud Spanner" or "this team should consolidate on Firestore" without ever opening a query console.

The Decision Framework — Relational vs NoSQL, Regional vs Global

Before memorizing service names, internalize the four dimensions that determine which database fits a workload. These dimensions are the language of the CDL exam.

Dimension 1 — Data Model: Structured, Document, Wide-column, Key-value

The shape of your data is the first filter. Structured / relational data lives in rigid tables with foreign keys (a banking ledger, an ERP system). Document data is semi-structured JSON-like records (a user profile with flexible fields). Wide-column data is sparse, massive tables indexed by row key (IoT sensor readings). Key-value data is a simple lookup (a session cache).

Dimension 2 — Scale Boundary: Regional vs Global

Will users only access this data from one region (Taipei traffic for a Taiwan-only e-commerce app) or from every continent simultaneously (a global stock trading platform)? Cloud SQL, AlloyDB, Firestore, and Bigtable are regional or multi-regional within a continent. Cloud Spanner is the only Google Cloud database engineered to provide strong consistency across continents — that is its superpower and its price tag.

Dimension 3 — Workload Pattern: OLTP vs OLAP vs Cache

OLTP (Online Transaction Processing) workloads are short, fast writes and reads — a customer paying for a coffee. OLAP (Online Analytical Processing) workloads scan billions of rows to produce reports — last quarter's regional sales. Cache workloads need sub-millisecond reads of frequently accessed data — a logged-in user's session token. Cloud SQL, AlloyDB, Spanner, and Firestore are OLTP. BigQuery is OLAP (use a data warehouse instead, see data-warehousing-bigquery). Memorystore is the cache.

Dimension 4 — Consistency vs Scalability Trade-off

Strong consistency means every read sees the latest write — essential for money. Eventual consistency means reads may briefly lag — fine for a "likes" counter on a social app. Spanner uniquely offers strong consistency at global scale. Firestore offers strong consistency within a region. Bigtable offers row-level consistency but is optimized for throughput, not transactions.

白話文解釋（Plain English Explanation）

The Google Cloud database portfolio is easier to grasp when you stop thinking about CPUs and replication protocols and start thinking about real-world places where information is stored, organized, and retrieved. The three analogies below each illuminate a different facet of the portfolio.

Analogy 1 — A City Library System (Data Models and Specialization)

Imagine the Taipei Public Library system with its many branches. The main Main Branch has the most disciplined catalog: every book lives in a precise Dewey Decimal slot, every loan is recorded in a strict ledger, and the librarian can answer "how many copies of this exact ISBN are currently borrowed?" instantly. That is Cloud SQL and AlloyDB — disciplined relational databases for the bookkeeping of the business.

The Children's Picture Book Section does not care about Dewey codes. Each book is a flexible bundle of pictures, sounds, and tags. New formats are added every week — pop-up books, sticker books, AR books — without rebuilding the catalog. That is Firestore, a document store where each record can have a different shape, perfect for mobile apps whose user profiles grow new fields every release.

The Newspaper and Magazine Archive stores billions of clippings indexed by date and publication. Nobody asks "what is the total revenue?" — they ask "give me every clipping from this newspaper between these two dates." That is Bigtable, a wide-column store built for time-series and IoT data with petabyte scale.

The Front Desk Pencil Drawer holds the three most-borrowed books of the day for instant handout. No catalog lookup, no shelving — just grab and give. That is Memorystore, an in-memory cache that returns data in under a millisecond.

Finally, the Inter-Library Loan Network allows a reader in Taipei to instantly verify a book at the New York branch without ambiguity. That global, strongly consistent coordination is Cloud Spanner.

Analogy 2 — A Bank's Vault Network (Consistency and Global Scale)

Think of a multinational bank like HSBC with branches in Taipei, London, and New York. A traditional bank used to reconcile balances at the end of each day — if you withdrew NTD 10,000 in Taipei at 11 PM, the New York branch wouldn't see the update until the morning batch ran. That is eventual consistency, and it is unacceptable for money.

A modern global bank needs every branch, in every timezone, to see the same balance the instant the withdrawal completes. That is strong global consistency, and inside Google Cloud only Cloud Spanner provides it. Spanner uses Google's TrueTime API — a synchronized atomic-clock service running in every region — to give every transaction a globally ordered timestamp. This is why Spanner powers Google Ads (a multi-billion-dollar global ledger) and is recommended for financial systems, supply chain hubs, and gaming leaderboards where a player in Tokyo and a player in São Paulo must see the same scoreboard.

For workloads that don't need that global reach — say, a Taiwan-only ride-hailing app — Cloud SQL or AlloyDB is far cheaper and equally reliable within one region. The CDL exam regularly tests this trade-off: do not "over-engineer" with Spanner for a local workload, but do not "under-engineer" with Cloud SQL for a true global transactional system.

Analogy 3 — A 24-Hour Convenience Store Logistics Network (Workload Specialization)

A 7-Eleven convenience store chain runs on at least four different information systems, each tuned for a different job. The point-of-sale (POS) register records every transaction in milliseconds — a structured, transactional database. That is Cloud SQL or AlloyDB.

The customer loyalty app on each shopper's phone stores flexible profiles — favorite drinks, redeemed coupons, preferred stores — and must sync instantly when the phone goes from 4G to Wi-Fi. That is Firestore, with built-in mobile and offline sync via the Firebase SDK.

The store-level IoT system tracks the temperature of every refrigerator every 30 seconds across 6,000 stores. That is billions of small writes per day, all keyed by store_id + timestamp. That is Bigtable, the wide-column workhorse for time-series.

The homepage banner cache that serves "today's hot promotion" to every visitor must respond in 1 millisecond. That is Memorystore for Redis, sitting in front of Cloud SQL to absorb read traffic.

The headquarters report that asks "which products sold best last quarter across all 6,000 stores?" — that is not a database job, that is a data warehouse job for BigQuery, covered in data-warehousing-bigquery.

Cloud SQL — The Familiar Relational Workhorse

Engine support and managed responsibilities

Cloud SQL is Google Cloud's fully managed relational database service supporting MySQL, PostgreSQL, and SQL Server. It is the natural first step for any organization migrating an existing on-premises relational workload — a Rails app, a Drupal site, a legacy ERP, an internal HR system.

Google handles the "undifferentiated heavy lifting": OS patching, database engine upgrades, daily backups, point-in-time recovery, automatic failover to a standby replica in another zone. The customer focuses on schema design and queries.

Regional scale and high availability

Cloud SQL is regional: a primary instance lives in one region with high availability (HA) across two zones, and you can add read replicas in other regions for read scaling and disaster recovery. The practical scale ceiling is up to roughly 64 TB of storage and 128 vCPUs per instance — generous for the vast majority of enterprise workloads but not "internet-scale."

Typical Cloud SQL use cases include: SaaS application backends, content management systems, e-commerce platforms with regional scope, internal corporate applications, and any workload that already runs on a vanilla open-source relational engine.

AlloyDB — PostgreSQL on Steroids

Performance profile vs standard PostgreSQL

AlloyDB for PostgreSQL is a newer, premium offering. It is 100 % PostgreSQL-compatible but engineered by Google for transactional workloads that are too big or too analytical for Cloud SQL. Google publishes benchmarks claiming up to 4× faster transactional performance than standard PostgreSQL and up to 100× faster analytical queries, thanks to a columnar in-memory engine layered on top of the row store.

AlloyDB is the right pick when a customer says "we love PostgreSQL but we are outgrowing it" — for example, a fintech that processes hundreds of thousands of transactions per minute on a single regional database. It is regional like Cloud SQL but offers near-zero-downtime maintenance and built-in vector search for AI-powered applications.

The CDL framing: AlloyDB is for customers who want PostgreSQL semantics with hyperscale performance and modern AI features, but who do not need global multi-region strong consistency (that is Spanner's job).

Cloud Spanner — Globally Distributed, Strongly Consistent

The three properties Spanner combines

Cloud Spanner is Google's signature database — the technology that runs Google Ads, Google Photos, and the Google Play Store. It uniquely combines three properties that the database industry once believed were impossible to achieve together:

1. Relational SQL semantics with schemas and JOINs
2. Horizontal scaling to thousands of nodes and petabytes
3. Strong external consistency across multiple continents

TrueTime and global ordering

Spanner uses Google's proprietary TrueTime API — backed by atomic clocks and GPS receivers in every Google data center — to give every transaction a globally ordered timestamp. This is what allows a customer in Singapore and a customer in Frankfurt to debit the same account without race conditions.

Spanner is overkill — and expensive — for a local Taiwan-only workload. Use Cloud SQL or AlloyDB for those. Spanner is the right answer when scenarios mention: global gaming leaderboards, global supply chain inventory, multi-region banking, regulatory systems that span jurisdictions, and any workload that previously required a custom, painful sharding layer on top of Oracle or PostgreSQL.

Firestore — Document Database for Mobile and Web Apps

Document model and Firebase integration

Firestore is a fully managed, serverless, NoSQL document database. It stores data as collections of JSON-like documents and is famous for its tight integration with Firebase, giving mobile and web developers real-time sync, offline support, and built-in client-side security rules.

Firestore is the natural choice when a mobile or web app needs:

• Flexible schemas that evolve frequently
• Push-style updates ("when this document changes, update every connected phone")
• Offline-first behavior (the app keeps working on the MRT when the signal drops)
• Per-user security rules enforced at the database tier

Consistency boundaries — regional vs multi-regional

Firestore offers strong consistency within a region and is available in regional and multi-regional configurations. It is not global in the Spanner sense — a multi-regional Firestore covers a continent (e.g., nam5 covering North America, eur3 covering Europe), not the entire planet with single-row strong consistency.

Typical Firestore use cases: chat apps, collaborative editing tools, mobile games, social feeds, user-profile services, IoT companion apps.

Bigtable — Wide-Column for IoT, Time-Series, and Analytics

Throughput and latency profile

Cloud Bigtable is the wide-column NoSQL store that originally powered Google Search, Gmail, and Google Maps. It is engineered for massive throughput — millions of operations per second — at single-digit-millisecond latency, with petabyte-scale storage.

Bigtable is the right tool when:

• You have billions to trillions of small rows keyed by an obvious row key (device ID + timestamp, user ID + event ID)
• You write a lot more than you query interactively
• You don't need cross-row transactions or SQL JOINs

The canonical use cases on the CDL exam are IoT telemetry (a fleet of 100,000 scooters reporting GPS every 10 seconds), financial market tick data, ad-tech event streams, and operational monitoring (every metric from every server in a data center).

HBase compatibility and migration landings

Bigtable also integrates natively with the Apache HBase API, making it a strong landing zone for organizations migrating off self-managed Hadoop and Cassandra clusters.

Memorystore — In-Memory Cache for Sub-Millisecond Reads

Role in the data tier

Memorystore is Google Cloud's fully managed Redis and Memcached service. It is not a primary database — it is a cache that sits in front of one (typically Cloud SQL or AlloyDB) to absorb read traffic and shave latency from tens of milliseconds down to under one millisecond.

Typical Memorystore use cases:

• Session caching: storing logged-in users' session tokens
• Leaderboards and counters: real-time game scores, "trending now" lists
• API response caching: hot data that 80 % of users request
• Rate limiting: tracking how many requests an IP has made in the last minute
• Pub/Sub fan-out for chat or notifications

For a CDL scenario, the trigger phrase is "sub-millisecond latency" or "reduce load on the primary database" — both point to Memorystore.

Managed vs Self-Managed — The Operational Trade-Off

TCO and exam triggers

A common CDL framing is the choice between a managed Google Cloud database (Cloud SQL, AlloyDB, Spanner, Firestore, Bigtable, Memorystore) and a self-managed alternative — running PostgreSQL, MongoDB, Cassandra, or Redis on Compute Engine virtual machines.

Self-managed gives you total control over the version, the extensions, and the configuration. But you also own everything that breaks: patching, backups, failover, monitoring, capacity planning, and the 3 AM page when a disk fills up. For most enterprises, the staff cost dwarfs the license cost, and managed services almost always win the Total Cost of Ownership (TCO) comparison — see cloud-financial-governance for the financial framework.

Migration Story — From On-Premises MySQL, PostgreSQL, and Oracle

Source-to-target pairings

A large fraction of CDL questions revolve around migration. The recommended pathways are:

• On-prem MySQL or PostgreSQL → Cloud SQL using Database Migration Service (DMS), which provides near-zero-downtime continuous replication.
• On-prem PostgreSQL with extreme performance needs → AlloyDB for the same SQL surface with hyperscale performance.
• On-prem Oracle → Cloud Spanner or AlloyDB. Spanner is recommended for workloads that need global scale; AlloyDB is the right pick when the workload is regional but performance-hungry. Google partners often run an Oracle-to-PostgreSQL migration assessment before committing.
• On-prem MongoDB → Firestore for document workloads, or MongoDB Atlas on Google Cloud if the team insists on MongoDB compatibility.
• On-prem Cassandra or HBase → Bigtable via the HBase-compatible API.
• On-prem Redis or Memcached → Memorystore as a near-drop-in replacement.

The CDL exam will not ask for command-line steps, but it will ask which target database matches a source system — so memorize the pairings above.

Putting It Together — A One-Glance Decision Cheat Sheet

When a CDL scenario lands on your desk, walk through these triggers in order:

1. "Analytics, reports, dashboards, petabyte scans" → BigQuery (see data-warehousing-bigquery)
2. "Sub-millisecond cache, session, leaderboard" → Memorystore
3. "Global, strongly consistent, financial / supply chain / multi-region" → Cloud Spanner
4. "Time-series, IoT, billions of small rows, high throughput" → Cloud Bigtable
5. "Mobile app, real-time sync, flexible JSON, offline" → Firestore
6. "Migrate existing MySQL / PostgreSQL / SQL Server" → Cloud SQL
7. "PostgreSQL with hyperscale and AI features" → AlloyDB

If you can recognize these seven triggers, you can answer the vast majority of database questions on the CDL exam without ever opening a query editor. The full portfolio overview is available at https://cloud.google.com/products/databases.

Cost and Operational Considerations at the CDL Level

You will not be asked exact dollar amounts on the CDL exam, but you should grasp the relative cost shape of each service:

• Memorystore is billed per GB-hour of memory and is the cheapest in absolute monthly cost for small caches.
• Cloud SQL is billed by instance vCPU and storage; predictable for steady workloads.
• AlloyDB is priced as a premium tier above Cloud SQL but offers significantly higher performance per dollar for the right workload.
• Firestore is serverless and billed per document read, write, and delete — extremely cheap at low scale and predictable when traffic explodes.
• Bigtable is billed per node-hour plus storage; the minimum production cluster is non-trivial, so it is the wrong pick for tiny workloads.
• Cloud Spanner is the most expensive per "processing unit" but the only option for global strong consistency.

For governance and budget alerting across all of these, see cloud-financial-governance.

Frequently Asked Questions

Q: What is the simplest way to remember when to use Cloud Spanner vs Cloud SQL?

A: Ask one question: "Does this workload need strong consistency across multiple continents at once?" If yes, Spanner. If no, Cloud SQL (or AlloyDB if performance demands). Spanner is a premium tier; do not pay for it unless the workload truly requires global ACID transactions.

Q: Is Firestore the same product as Firebase Realtime Database?

A: No. Firestore is the newer, more scalable, more queryable Google Cloud product. Firebase Realtime Database is the older sibling, still supported but generally not recommended for new projects. On the CDL exam, "Firestore" is the canonical document database answer.

Q: Can I run my Oracle workload directly on Google Cloud?

A: Yes — Google Cloud offers Oracle Database@Google Cloud through a partnership with Oracle, but for most migrations the recommendation is to replatform onto AlloyDB (for PostgreSQL-compatible workloads) or Cloud Spanner (for workloads that need global scale). The CDL exam favors replatforming for long-term cost reduction.

Q: Why is Bigtable not the answer for a "global financial ledger"?

A: Bigtable does not support multi-row ACID transactions or SQL JOINs. A financial ledger requires guarantees that money is never double-spent, even when the request hits multiple servers at once. Only Cloud Spanner provides that with global scope. Bigtable is for high-throughput key-based workloads (IoT, time-series), not transactional ledgers.

Q: Does using a managed database mean my team has no responsibilities?

A: No. Under the Shared Responsibility Model, Google handles patching, hardware, replication, and backups. The customer still owns: schema design, query performance, access control (IAM), application-level data validation, and ensuring sensitive data is encrypted appropriately. Managed does not mean unmanaged.

Q: How do these databases connect to my application?

A: All Google Cloud databases support standard client libraries in major languages (Java, Python, Go, Node.js, .NET). For private networking, they connect via VPC Service Controls and Private Service Connect. For serverless apps on Cloud Run or Cloud Functions, Google provides direct VPC connectors. You do not need to manage IP addresses or DNS in most cases.

Summary — From Portfolio to Decision

The Google Cloud database portfolio is broad on purpose. Each service is a specialist: Cloud SQL for the familiar relational workhorse, AlloyDB for PostgreSQL at hyperscale, Cloud Spanner for global strong consistency, Firestore for mobile and document workloads, Bigtable for IoT and time-series, and Memorystore for the in-memory cache layer.

As a Cloud Digital Leader, your job is not to design the schema — it is to listen to a business scenario, identify the dominant data model, scale boundary, workload pattern, and consistency requirement, and then confidently recommend the right service. Pair this knowledge with the cloud value framing from cloud-value-proposition and the governance lens from cloud-financial-governance, and you have a complete database story for the exam and for real-world cloud strategy conversations.