Google Cloud PCA - Section 4

Databases and Caching

PCA lens: database questions are usually service-selection questions. The exam is less about syntax and more about matching business needs to database shape, scale, availability, consistency, operational overhead, and migration constraints.

Fast Decision Matrix

Service	What it is	Pick it when...	Common PCA trap
Cloud SQL	Managed MySQL, PostgreSQL, or SQL Server for traditional apps	Existing relational app, least refactor, regional HA is enough	Choosing it for global horizontal scale or massive write throughput
AlloyDB	High-performance PostgreSQL-compatible database	PostgreSQL workload needs more performance, availability, HTAP, or AI/vector features than Cloud SQL	Choosing it for MySQL/SQL Server compatibility or global Spanner-style consistency
Cloud Spanner	Globally scalable relational database with strong consistency	Mission-critical transactional app needs horizontal scale, high availability, and strong consistency across regions	Using it for a simple regional app where Cloud SQL is enough
Cloud Bigtable	Wide-column NoSQL for huge, low-latency, high-throughput datasets	IoT, telemetry, time-series, adtech, personalization, HBase/Cassandra-style access	Choosing it for relational joins, complex SQL, or multi-row transactions
Firestore	Serverless document database for application backends	Mobile/web app, user profiles, document data, real-time sync, offline support	Using it for warehouse analytics or relational reporting
Memorystore for Redis / Valkey	Managed in-memory cache	Sessions, cache, leaderboards, counters, rate limiting, low-latency reads	Treating cache as the system of record without durability design
Memorystore for Memcached	Legacy managed Memcached cache	Existing Memcached pattern; know it for exam recognition	Treating it as the default new choice instead of Redis/Valkey
BigQuery	Serverless analytics warehouse	Petabyte-scale analytics, reporting, dashboards, ad hoc SQL	Using it as an OLTP application database
Database Migration Service / DMS	Managed database migration and replication	Migrate databases with minimal downtime into Cloud SQL or AlloyDB	Assuming it replaces application refactoring or schema redesign
Datastream	Serverless change data capture (CDC) and replication	Stream database changes into BigQuery, Cloud Storage, Spanner, or event-driven pipelines	Confusing CDC/streaming replication with full database migration planning
Database Center	Central dashboard for database fleet health and recommendations	Org-wide visibility into database health, availability, data protection, security, compliance, cost, and performance	Treating it as a database runtime instead of a fleet management/observability layer
Oracle Database@Google Cloud	Oracle database services integrated with Google Cloud and OCI/Exadata infrastructure	Oracle workloads need low-latency access to Google Cloud apps/services without a major Oracle redesign	Using it as a generic replacement for Cloud SQL/AlloyDB/Spanner
Bare Metal Solution for Oracle	Dedicated bare-metal environment adjacent to Google Cloud	Oracle RAC, licensing, hardware, or legacy constraints prevent normal managed database migration	Choosing it for ordinary relational apps that should modernize to managed databases
AlloyDB Omni	Downloadable AlloyDB-compatible PostgreSQL for outside Google Cloud	Hybrid, on-prem, edge, or multicloud PostgreSQL-compatible modernization where data cannot fully move to Google Cloud	Assuming it is the default managed Google Cloud database instead of AlloyDB or Cloud SQL
Spanner Omni	Downloadable Spanner for on-prem, hybrid, multicloud, or air-gapped environments	Need Spanner-like scale/consistency outside Google Cloud for portability, DR, regulatory, or on-prem modernization reasons	Picking it over fully managed Spanner when the workload can simply run in Google Cloud
Vector search in databases	Database-native support for embeddings/vector similarity search	GenAI app needs semantic search close to operational data in Cloud SQL, AlloyDB, Spanner, Bigtable, Firestore, Memorystore, or BigQuery	Assuming every AI search use case requires a separate vector-only database
Self-managed database on Compute Engine	Customer-managed DB on VMs	Use only when the app needs full OS/database control, unsupported extensions, or vendor constraints	Choosing it when a managed database meets requirements

Exam shortcut: if the prompt says existing MySQL/PostgreSQL/SQL Server and minimal change, think Cloud SQL first. If it says PostgreSQL but Cloud SQL cannot meet performance/scale, think AlloyDB. If it says global transactional scale with strong consistency, think Spanner. If it says huge key-based write/read throughput, think Bigtable. If it says mobile/web document backend, think Firestore.

Service Deep Dives

Cloud SQL

Fully managed relational database for MySQL, PostgreSQL, and SQL Server.

PCA angle	Details
Why an org would use it	Organizations use Cloud SQL when they already have a traditional relational application and want to remove database server management without rewriting the app. It is usually the fastest path for lift-and-shift or modest modernization because teams can keep familiar engines, drivers, schemas, backup patterns, and SQL behavior. It is a good fit when the business needs managed backups, patching, regional high availability, read replicas, private connectivity, IAM integration, and predictable operations.
Choose when	Existing relational workload, least refactor, MySQL/PostgreSQL/SQL Server compatibility, normal OLTP, regional HA, read scaling with replicas.
Do not choose when	Massive horizontal scale, global strong consistency, very high write throughput, or analytics-heavy workloads. Compare with AlloyDB, Spanner, Bigtable, and BigQuery.
Exam trigger words	Existing app, relational schema, SQL Server/MySQL/PostgreSQL, managed DB, minimize admin, simple regional failover.

Cloud SQL HA and read replicas

Availability and read-scaling patterns for Cloud SQL.

PCA angle	Details
Why an org would use it	Organizations use HA to reduce downtime from zonal failures. HA is about failover and availability, not increasing write throughput. Read replicas help scale read-heavy workloads and can place read capacity closer to users, but they do not solve write bottlenecks. PCA questions often test whether the requirement is availability, read scaling, disaster recovery, or global transactional consistency.
Choose when	Use HA for failover. Use read replicas for reporting/read-heavy traffic. Use backups/PITR for recovery from bad writes or deletes.
Do not choose when	Do not choose read replicas as the answer for writes, strong consistency, or true active-active global databases.
Exam trigger words	Scale reads, failover, regional outage, reporting load, RPO/RTO, point-in-time recovery.

AlloyDB for PostgreSQL

Fully managed PostgreSQL-compatible database built for higher performance and enterprise workloads.

PCA angle	Details
Why an org would use it	Organizations use AlloyDB when they want PostgreSQL compatibility but need better performance, availability, or analytical capability than a standard managed PostgreSQL deployment can provide. It is strong for demanding transactional workloads, hybrid transactional and analytical processing, and modern AI/vector-search use cases that benefit from keeping data close to the database engine. It can be a better modernization target for serious PostgreSQL estates that are outgrowing Cloud SQL but do not need Spanner's global relational model.
Choose when	PostgreSQL-compatible workload, high performance, enterprise HA, HTAP, low-latency AI/vector search, outgrown Cloud SQL PostgreSQL.
Do not choose when	Not for MySQL or SQL Server apps. Not the default answer for global strong consistency. For global transactional scale, compare with Spanner.
Exam trigger words	PostgreSQL compatible, higher performance than Cloud SQL, enterprise-grade, live transactional analytics, vector/AI.

Cloud Spanner

Fully managed relational database for global scale, high availability, and strong transactional consistency.

PCA angle	Details
Why an org would use it	Organizations use Spanner when a normal relational database cannot meet scale, availability, or global consistency requirements. It supports relational schemas and SQL-style access while scaling horizontally and synchronously replicating data for high availability and consistency. It is a common PCA answer for global financial systems, inventory/reservation systems, user identity/profile systems, and applications where stale or conflicting data would be unacceptable.
Choose when	Global or multi-region transactional system, strong consistency, horizontal scale, high availability, mission-critical data, relational model required.
Do not choose when	Do not choose Spanner just because the app uses SQL. It can be overkill for a single-region app that Cloud SQL or AlloyDB can handle.
Exam trigger words	Global consistency, massive relational scale, financial transactions, inventory, user profiles, active-active, strict RPO/RTO.

Cloud Bigtable

Managed wide-column NoSQL database for very large, low-latency, high-throughput operational and analytical workloads.

PCA angle	Details
Why an org would use it	Organizations use Bigtable for datasets that are too large or too write-heavy for traditional relational databases but still require fast key-based access. It is strong for telemetry, IoT, time-series data, clickstream, fraud signals, adtech, personalization, and HBase/Cassandra-style workloads. The architecture works best when access patterns are designed around row keys and column families rather than joins and relational constraints.
Choose when	Billions of rows, time-series/IoT/telemetry, high read/write throughput, low latency, sparse data, HBase or Cassandra migration pattern.
Do not choose when	Not for relational joins, ad hoc analytics, small app backends, or transactions across many rows. For analytics, compare with BigQuery. For app documents, compare with Firestore.
Exam trigger words	Wide-column, low latency, high throughput, time-series, IoT, HBase, Cassandra, operational analytics.

Firestore

Serverless NoSQL document database for web, mobile, and app backends.

PCA angle	Details
Why an org would use it	Organizations use Firestore when they want to build application features quickly without managing database servers or capacity. It works well for document-shaped data such as user profiles, app state, product catalogs, lightweight content, and mobile/web experiences that benefit from real-time sync and offline support. It is a strong fit when developer velocity, automatic scaling, and simple app integration matter more than relational joins or complex reporting.
Choose when	Mobile/web backend, document data, serverless app database, real-time updates, offline sync, hierarchical objects.
Do not choose when	Not the best fit for complex relational reporting, warehouse analytics, or very large time-series telemetry. Compare with Cloud SQL, BigQuery, and Bigtable.
Exam trigger words	Document database, mobile app, Firebase, offline sync, real-time application state, serverless NoSQL.

Memorystore for Redis / Valkey

Fully managed in-memory data store for low-latency cache and transient state.

PCA angle	Details
Why an org would use it	Organizations use Memorystore when application performance depends on extremely fast reads/writes or reducing pressure on a backend database. Common uses include caching expensive query results, session storage, leaderboards, rate limiting, counters, queues, and short-lived state shared across app instances. The value is speed and operational simplicity, not long-term durability. The source of truth should normally remain in a durable database.
Choose when	Sub-millisecond access, cache layer, sessions, counters, rate limiting, ephemeral shared state, high read performance.
Do not choose when	Not the primary durable database unless the application has explicitly designed for persistence, replication, and data loss risk.
Exam trigger words	Cache, session store, low latency, Redis, Valkey, leaderboard, rate limiter.

Memorystore for Memcached

Managed Memcached cache for legacy/simple key-value caching patterns.

PCA angle	Details
Why an org would use it	Organizations historically used Memcached for simple distributed caching where they did not need Redis-like data structures or persistence features. For PCA, recognize the pattern: this is cache, not a database of record. Current Google documentation marks Memorystore for Memcached as deprecated, so for new designs you should think carefully before making it the answer.
Choose when	Existing Memcached-based application or exam clue specifically calls out Memcached compatibility.
Do not choose when	Do not pick it as the default for new cache designs unless the prompt clearly requires Memcached. Compare with Memorystore for Redis or Valkey.
Exam trigger words	Legacy Memcached, simple key-value cache, cache-only, low priority.

BigQuery

Serverless enterprise data warehouse for analytics, reporting, and ad hoc SQL at scale.

PCA angle	Details
Why an org would use it	Organizations use BigQuery when the question is about analyzing large volumes of data rather than serving transactional application requests. It is strong for reporting, dashboards, large joins over analytical datasets, log analytics, data marts, and cost/performance optimization through partitioning and clustering. It is often in the database decision set because the exam tries to separate OLTP databases from OLAP warehouses.
Choose when	Analytics, BI, reporting, data warehouse, batch analysis, petabyte-scale SQL, dashboards, long-running analytical queries.
Do not choose when	Do not choose BigQuery for low-latency row-by-row application transactions. It is not an OLTP app database.
Exam trigger words	Analytics warehouse, ad hoc SQL, reporting, dashboards, partitioning, clustering, not OLTP.

Database Migration Service / DMS

Managed service for database migration and continuous replication into Google Cloud databases.

PCA angle	Details
Why an org would use it	Organizations use DMS to reduce migration complexity and downtime when moving databases into Google Cloud. It is useful when the business wants a phased migration, ongoing replication, or a cutover with less outage than a one-time export/import. PCA questions may include DMS when the core problem is migration mechanics, not long-term runtime architecture.
Choose when	Database migration with minimal downtime, continuous replication, Cloud SQL or AlloyDB target, modernization planning.
Do not choose when	DMS does not automatically fix schema design, application dependencies, or database engine incompatibilities.
Exam trigger words	Migrate database, reduce downtime, continuous replication, cutover, source-to-target migration.

Additional DB Topics PCA May Touch

These are not always the main answer in database questions, but they are useful PCA edge topics. They usually show up when the prompt mentions CDC, fleet governance, Oracle constraints, hybrid/multicloud requirements, GenAI/vector search, or unusual control requirements.

Topic	Why an org would use it	PCA exam trigger	Common trap
Datastream	Use it when the org needs low-latency CDC/replication from operational databases into analytics, storage, or downstream systems. It is more about streaming change data than picking the long-term database engine.	Real-time replication, CDC, stream database changes, feed BigQuery/Cloud Storage/Spanner	Confusing Datastream with DMS. DMS is migration-oriented; Datastream is CDC/event/data movement oriented.
Database Center	Use it when the org has many databases and needs a central view of health, recommendations, availability, data protection, security, compliance, cost, and performance posture.	Fleet health, database governance, database recommendations, org-wide database visibility	Not a runtime database. It will not replace Cloud SQL, Spanner, Bigtable, or AlloyDB.
Oracle Database@Google Cloud	Use it when the org has Oracle workloads that should stay close to Google Cloud applications/services while still using Oracle database technology and Exadata-style infrastructure.	Oracle migration, Exadata, Autonomous Database, low latency between Oracle and Google Cloud apps	Do not choose it for normal MySQL/PostgreSQL/SQL Server apps. It is an Oracle-specific path.
Bare Metal Solution for Oracle	Use it for specialized Oracle or legacy workloads that cannot be virtualized/refactored easily, often because of licensing, RAC, hardware, or platform constraints.	Oracle RAC, strict licensing, legacy workload, dedicated hardware, cannot refactor	Usually not the modern default. If managed Cloud SQL/AlloyDB/Spanner works, prefer managed services.
AlloyDB Omni	Use it when the org wants AlloyDB/PostgreSQL-compatible capabilities outside Google Cloud, such as on-prem, edge, disconnected, hybrid, or multicloud environments.	Hybrid PostgreSQL, on-prem PostgreSQL modernization, data cannot move fully to cloud	Do not confuse with fully managed AlloyDB in Google Cloud. Omni increases deployment flexibility but also changes operational responsibility.
Spanner Omni	Use it when the org needs Spanner-like scale, strong consistency, and multimodel capabilities outside Google Cloud, such as on-prem, multicloud, air-gapped, or DR environments.	Spanner outside Google Cloud, application portability, cross-cloud resilience, regulatory/on-prem constraint	If the workload can run in Google Cloud, fully managed Spanner is usually the cleaner PCA answer.
Firestore with MongoDB compatibility	Use it when app teams want Firestore/serverless document database behavior while using MongoDB-compatible skills, drivers, or migration patterns.	MongoDB-compatible document app, serverless document backend, app modernization	Do not turn this into a warehouse/analytics answer. It is still application/document data territory.
Vector search in databases	Use it when a GenAI or semantic search app should keep embeddings close to operational or analytical data instead of standing up a totally separate vector stack.	Semantic search, embeddings, GenAI app, RAG over app/database data	Do not assume vector search automatically changes the primary database choice. Start with the workload shape first.
Self-managed DB on Compute Engine	Use it only when the org truly needs OS-level control, unsupported database versions/extensions, custom agents, vendor constraints, or unusual licensing behavior.	Full control, unsupported engine, custom OS/database config, lift-and-shift with no managed option	Usually a trap. PCA prefers managed services unless control requirements are explicit.

PCA shortcut: start with the workload shape first. Existing relational app usually points to Cloud SQL/AlloyDB. Global transactional consistency points to Spanner. Massive key-based throughput points to Bigtable. App documents point to Firestore. Analytics points to BigQuery. Then layer in migration, CDC, Oracle, hybrid, or AI/vector constraints only if the prompt asks for them.

High-Value PCA Comparison Patterns

Comparison	What to remember
Cloud SQL vs AlloyDB	Cloud SQL is the default managed relational answer for standard MySQL/PostgreSQL/SQL Server. AlloyDB is the higher-performance PostgreSQL-compatible answer when Cloud SQL PostgreSQL is not enough.
Cloud SQL vs Spanner	Cloud SQL is regional relational with familiar engines. Spanner is for horizontal relational scale, high availability, and strong consistency across regions.
AlloyDB vs Spanner	AlloyDB keeps PostgreSQL compatibility and performance. Spanner is for global transactional consistency and scale, not simply better PostgreSQL.
Bigtable vs Firestore	Bigtable is for massive key-based, high-throughput operational/time-series data. Firestore is for app document data, mobile/web backends, and real-time sync.
Bigtable vs BigQuery	Bigtable serves low-latency operational access. BigQuery analyzes large datasets with SQL. Operational serving and analytics are different exam intents.
Memorystore vs database	Memorystore accelerates applications with cache or transient state. It usually sits in front of a durable database and is not the system of record.
HA vs read replica vs backup	HA handles failover. Read replicas scale reads. Backups and PITR recover from accidental deletes, corruption, or bad deployments.
DMS vs Datastream	DMS is primarily for database migration and cutover. Datastream is CDC/replication/data movement for streaming changes into downstream services.
Database Center vs database service	Database Center gives fleet visibility and recommendations. It is not where the application stores data.
Oracle Database@Google Cloud vs Bare Metal Solution	Oracle Database@Google Cloud integrates Oracle database services with Google Cloud. Bare Metal Solution is for specialized dedicated-hardware/legacy Oracle cases.
AlloyDB vs AlloyDB Omni	AlloyDB is fully managed in Google Cloud. AlloyDB Omni brings AlloyDB/PostgreSQL-compatible capabilities to on-prem, edge, or other-cloud environments.
Spanner vs Spanner Omni	Spanner is the fully managed Google Cloud service. Spanner Omni is for Spanner-like capability outside Google Cloud.
Managed DB vs self-managed DB on Compute Engine	Prefer managed databases unless the prompt explicitly requires OS control, unsupported features, or licensing constraints.

Common PCA Traps

Do not choose Spanner just because the app uses SQL. Choose Spanner when the prompt requires global/horizontal transactional scale and strong consistency.
Do not choose BigQuery for user-facing OLTP. BigQuery is for analytics, reporting, and large-scale SQL over analytical datasets.
Do not choose Bigtable for relational joins or arbitrary SQL. Bigtable needs intentional row-key and access-pattern design.
Do not confuse HA, read replicas, and backups. They solve different problems: failover, read scale, and recovery.
Do not use Memorystore as the durable system of record unless the scenario explicitly describes a design that accepts that risk.
Do not assume DMS solves application migration. It helps move/replicate database data; app changes and dependencies still matter.
Do not choose Datastream when the question is asking for the target database. Datastream moves changes; it does not decide the serving database.
Do not choose Database Center as an application architecture component. It is for fleet visibility, health, and recommendations.
Do not choose Oracle Database@Google Cloud or Bare Metal Solution unless the prompt specifically has Oracle, Exadata, RAC, licensing, or legacy constraints.
Do not choose self-managed databases on Compute Engine unless the prompt clearly requires control that managed services cannot provide.

One-Page Cram Summary

Prompt says...	Think...
Existing MySQL/PostgreSQL/SQL Server, least refactor	Cloud SQL
PostgreSQL compatibility but higher performance/HTAP/AI	AlloyDB
Global relational transactions with strong consistency	Cloud Spanner
Huge low-latency key-based writes/reads, time-series, HBase/Cassandra	Cloud Bigtable
Mobile/web document database, offline sync, real-time app state	Firestore
Cache, sessions, counters, rate limiting, leaderboards	Memorystore for Redis / Valkey
Analytics warehouse and reporting	BigQuery
Database migration with minimal downtime	Database Migration Service
Real-time CDC or streaming database changes	Datastream
Database fleet health, recommendations, governance	Database Center
Oracle/Exadata workload needs to stay near Google Cloud services	Oracle Database@Google Cloud
Oracle RAC/licensing/dedicated hardware legacy constraint	Bare Metal Solution for Oracle
PostgreSQL-compatible database outside Google Cloud	AlloyDB Omni
Spanner-like database outside Google Cloud	Spanner Omni
Semantic search / embeddings close to existing data	Vector search in the chosen database
Full OS/database control required and managed DB will not work	Self-managed database on Compute Engine

Source Check

Source sanity check used official Google Cloud documentation for the Professional Cloud Architect exam guide and database services including Cloud SQL, AlloyDB, Spanner, Bigtable, Firestore, Memorystore, BigQuery, DMS, Datastream, Database Center, Oracle Database@Google Cloud, Bare Metal Solution, AlloyDB Omni, Spanner Omni, and current database AI/vector-search positioning.