
Database choice is a recurring decision point on the Professional Cloud Architect exam. Most scenarios reduce to a single fork: relational or non-relational. Knowing which fits a workload, and which Google Cloud service implements it, is what the exam tests.
Relational databases store data in tables made of rows and columns, with a schema that defines column names and data types up front. Every row in a table conforms to that schema. This rigidity is the point. It enforces data integrity and supports strong consistency, which matters for systems where accuracy and relationships between records cannot drift.
Examples outside Google Cloud include MySQL, PostgreSQL, Oracle, and Microsoft SQL Server. Inside Google Cloud, the relational services you need to recognize for the Professional Cloud Architect exam are Cloud SQL, Cloud Spanner, and BigQuery. Cloud SQL is managed MySQL, PostgreSQL, or SQL Server. Cloud Spanner is a globally distributed relational database with horizontal scale and strong consistency. BigQuery is a fully managed data warehouse that uses SQL-like queries.
Non-relational databases, often called NoSQL, drop the requirement that every record share the same schema. They are designed to store and manage large volumes of data that do not fit cleanly into rows and columns, including semi-structured and unstructured data. The four data models you should know are document store, key-value, column-family, and graph.
A key-value store maps a unique key to an arbitrary value. Key UserID_1234 might map to { name: Alice, age: 28, location: NY }, while key UserID_5678 maps to { preferences: { theme: dark, notifications: true } }. The two records hold completely different fields. A relational table would reject this because every row has to match the schema. A key-value store accepts it by design.
A document store extends the same idea by allowing nested structures, typically JSON-like documents, so each document can carry its own fields. A column-family model is used by wide-column databases that group related columns together for high-throughput reads and writes. A graph model represents entities as nodes and relationships as edges, which is efficient for queries about connections, like a social network where users link to other users.
Examples outside Google Cloud include MongoDB, Cassandra, Redis, and Amazon DynamoDB. On Google Cloud, Cloud Bigtable is the NoSQL service to know. It is designed for large analytical and operational workloads with high write throughput.
A worked example: vending machines streaming sensor readings into Google Cloud. The data is high volume, semi-structured, and the format may evolve as new sensor types come online. A NoSQL database fits because its flexible schema absorbs format changes without a migration, and it is optimized for the write throughput a continuous stream demands. A relational database would struggle with the write rate and the schema churn. Object storage is not designed for continuous small writes. Text files lack efficient querying.
The general rule the Professional Cloud Architect exam expects you to apply: pick relational when the workload has a stable schema, needs strong consistency, and benefits from joins, which points at Cloud SQL, Cloud Spanner, or BigQuery. Pick non-relational when the schema is flexible or absent, write throughput is high, or the data model is a graph or wide column, which points at Cloud Bigtable.
My Professional Cloud Architect course covers relational vs non-relational database selection alongside the rest of the foundational architecture material.