Databases fall into two main categories, and the difference between them shapes a large part of how you choose a service on Google Cloud. Relational databases, also called SQL databases, store data in a highly structured tabular format using rows and columns. Non-relational databases, also called NoSQL databases, are built for flexibility and scale, and they manage data that does not fit neatly into tables. The Professional Cloud Database Engineer exam expects you to know which category a workload belongs in, which Google Cloud product serves it, and where the boundaries between the two models actually sit.
A relational database stores information in tables organized with columns that define data attributes and rows that represent individual records. The layout of each table is set by a predefined schema, which determines the structure and the data types each column holds. That structure is the point. It keeps data consistent and easy to access through queries, and it is well suited to applications where accuracy and the relationships between data matter.
Common relational engines include MySQL, one of the most popular open-source options, PostgreSQL, known for its features and adherence to SQL standards, Oracle, used widely in large enterprise environments, and Microsoft SQL Server, often deployed alongside other Microsoft software. These are referred to as relational database engines because they provide the core software that stores, manages, and queries the data. They all follow the relational model, but SQL syntax and features vary somewhat across implementations.
On Google Cloud, the relational services are Cloud SQL, AlloyDB, Spanner, and BigQuery. BigQuery is Google's fully managed data warehouse and uses SQL-like queries. The others are operational relational databases that manage data in a structured, organized way.
One area the Professional Cloud Database Engineer exam tends to probe is how Google Cloud maps to specific database engines, because the right answer often depends on which engine the workload runs. It helps to separate services that run an engine directly from services that are compatible with an engine's syntax and tools.
For PostgreSQL workloads there are three paths. Cloud SQL for PostgreSQL is a fully managed version of the standard engine. AlloyDB is a PostgreSQL-compatible service aimed at demanding enterprise workloads that need higher performance. Spanner offers a PostgreSQL interface so you can use familiar tools while getting a horizontally scalable, globally distributed database. For MySQL, Google Cloud provides Cloud SQL for MySQL, which lets you move existing MySQL databases into a managed environment without changing the underlying code. For SQL Server, Cloud SQL for SQL Server manages the infrastructure and maintenance while providing the engine features those applications expect.
The distinction worth holding onto is that each Cloud SQL version runs the actual engine software. For PostgreSQL, MySQL, and SQL Server, Cloud SQL is executing the real engine. AlloyDB and Spanner, by contrast, are compatible with PostgreSQL syntax and tools but use different underlying architectures to reach better scale or performance. They speak the same language as PostgreSQL while not being the standard engine. So if a scenario involves running a MySQL or SQL Server workload, Cloud SQL is the direct path, because engine consistency is the priority.
Not every migration starts from a supported engine. Some involve converting from an unsupported engine to a supported one, such as moving from SQL Server to AlloyDB for PostgreSQL, or from Oracle to Cloud SQL for PostgreSQL. These conversions take more effort during the migration phase, but they let you land on a supported engine. It is also worth keeping in mind that managed relational solutions on Google Cloud carry some inherent limitations compared to a fully self-managed installation.
Non-relational databases store and manage large volumes of data that do not necessarily fit into a tabular structure. They handle a range of formats, including semi-structured and unstructured data, and they cover several data models. The common ones are the document store, the key-value store, the column-family model, and the graph model.
A key-value store represents data as a collection of key-value pairs. One key might map to a value holding a user's name, age, and location, while another key maps to a different value that only holds user preferences. The data under each key can differ in structure. In a relational database that inconsistency is hard to handle, because every record has to adhere to the same fixed schema, so key-value stores exist to provide flexibility when different records need different information. A document store works the same way but allows more complex nested structures, which fits formats like JSON well. Each document can carry different fields, which makes it effectively a richer form of the key-value model.
The graph model is a good example of data that does not fit a fixed schema at all. A social network is the standard illustration, where nodes represent users and edges represent the connections between them. A graph database stores and queries those connections efficiently, because the model is about relationships rather than a fixed number of columns. This flexibility is what lets non-relational databases scale as data evolves, since you do not have to redefine an entire schema every time the structure changes.
On Google Cloud, Cloud Bigtable is the NoSQL database designed for large analytical and operational workloads. Outside Google Cloud, examples in this category include MongoDB as a document store, Cassandra for large distributed datasets, Redis as an in-memory key-value store, and Amazon DynamoDB as a managed service.
The two categories trade off along predictable lines. Relational databases bring standardization through SQL, a mature and widely understood query language, which makes them the go-to choice for analytics and data science work that needs structured data and complex querying. They also provide ACID compliance for consistent, reliable transactions. The costs are scalability challenges as data grows, difficulty with semi-structured and unstructured data, and schema rigidity that makes structural changes cumbersome.
Non-relational databases offer strong scalability for distributed systems that scale out horizontally, flexibility to store varied data without a rigid schema, suitability for big data applications, and generally higher performance for reads and writes at scale. The trade-offs are a lack of standardization, since there is no single query language like SQL, less ACID compliance, which can mean trading consistency for scale, and analytics or reporting that is sometimes harder because the looser structure complicates aggregations.
For the exam, the practical takeaway is that there is no universally better option. The right choice depends on the use case. When you need transactional consistency and structured querying, a relational service fits. When you need flexibility and horizontal scale across large or evolving datasets, a non-relational service fits. Matching the workload to the category, and then to the specific Google Cloud product, is most of the work.
Our Professional Cloud Database Engineer course covers relational versus non-relational databases alongside engine compatibility on Google Cloud and choosing the right managed database service, with practice questions that drill these distinctions.
