Cloud Digital Leader Google Cloud Products and Services Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Cloud SQL for PostgreSQL

  Why it's wrong here

  Although Cloud SQL for PostgreSQL gives you a managed PostgreSQL engine and a familiar SQL dialect, it does not include AlloyDB’s AI-oriented storage enhancements, such as a columnar engine or native vector search for embeddings. For a migration centered on AI workloads, you would still have to build and tune external tools for semantic search, and Cloud SQL’s transaction-oriented design lacks the accelerated analytical and vector query performance that AlloyDB provides. Thus, while technically compatible, it is the wrong target for AI-optimized goals.

• ✗

  Cloud Spanner

  Why it's wrong here

  Cloud Spanner is designed for horizontally scalable, globally distributed transactional workloads with strong consistency, but it is not a drop-in PostgreSQL replacement in this migration context. Although Spanner offers a PostgreSQL interface, its architecture is built around distributed consensus and sharding, not around AI features like vector similarity search or a columnar engine. You would still need to integrate separate vector search infrastructure, and Spanner lacks AlloyDB’s optimized performance for AI analytical queries.

• ✓

  AlloyDB

  Why this is correct

  AlloyDB is Google Cloud’s fully managed PostgreSQL-compatible database purpose-built for demanding transactional and analytical workloads, and it integrates AI-optimized features directly into the engine. It includes native support for vector embeddings and vector search (AlloyDB AI), plus a columnar engine that accelerates analytical queries and can speed up AI inference pipelines. For a migration from Cloud SQL for MySQL, AlloyDB provides the lowest-friction PostgreSQL-compatible path while adding the AI capabilities your new workload needs.

• ✗

  Bigtable

  Why it's wrong here

  Bigtable is a NoSQL, wide-column database optimized for massive-scale, low-latency operations with high throughput, not for SQL-based relational migrations or AI-oriented vector search. It is not PostgreSQL-compatible, so you would need to completely redesign your schema and queries, and it offers no built-in support for embedding vectors or vector similarity search. Its strengths are in time-series, IoT, and clickstream data, not as a target for migrating an existing MySQL database into an AI-enabled PostgreSQL environment.

Go deeper

Related to this question