The relational versus non-relational database distinction is one of the most fundamental concepts in cloud architecture, and the Associate Cloud Engineer exam tests it directly. Knowing which GCP database services fall into each category, and more importantly knowing when to use which type, is essential for passing the exam and doing real cloud engineering work.
A relational database organizes data into tables with rows and columns. Each table has a fixed schema that defines what columns exist and what data type each column holds. Relationships between tables are defined through foreign keys. You query relational databases using SQL.
The defining characteristic of relational databases is ACID compliance. Transactions are atomic (either the whole transaction succeeds or none of it does), consistent (the database moves from one valid state to another), isolated (concurrent transactions do not interfere with each other), and durable (committed transactions survive failures). This makes relational databases the right choice for financial systems, order management, and any application where data integrity is non-negotiable.
On Google Cloud, the relational database services are Cloud SQL and Cloud Spanner. Cloud SQL is a managed instance of MySQL, PostgreSQL, or SQL Server running in a single region. It handles traditional relational workloads and is the simplest migration path for applications already using those database engines. Cloud Spanner is Google's globally distributed relational database. It maintains strong consistency across regions, which makes it unusual in the database world. Most distributed databases sacrifice consistency for availability. Spanner does not.
Non-relational databases, commonly called NoSQL databases, are designed for use cases where a rigid table structure is not appropriate. They trade some of the consistency guarantees of relational databases for flexibility, horizontal scalability, or performance at very high throughput.
NoSQL is not one thing. It describes several different data models, each suited to different access patterns.
Document stores store data as JSON-like documents. Each document can have different fields, making the schema flexible. Cloud Firestore is GCP's document database. It is well-suited for mobile and web application backends where each user's data might have slightly different attributes.
Key-value stores are the simplest model. Each record is a key paired with a value, and you retrieve data by looking up the key. Cloud Memorystore is GCP's managed Redis and Memcached service. It is used for caching, session storage, and leaderboards where you need extremely fast lookups by a specific identifier.
Column-family databases organize data by column rather than by row, allowing each row to have different columns. Cloud Bigtable uses this model. It handles millions of read and write operations per second and is built for time-series data, IoT sensor data, and any workload with very high throughput requirements.
The ACE exam presents scenarios and asks you to choose the right database. A few patterns make this straightforward most of the time.
If the scenario involves transactions, financial data, or requires SQL queries with joins, you are looking at a relational database. If it is a single region and a manageable scale, Cloud SQL. If it needs global scale or multi-region consistency, Cloud Spanner.
If the scenario involves flexible document storage for a mobile or web app, Firestore. If it involves caching or session data that needs sub-millisecond lookups, Memorystore. If it involves massive throughput, time-series data, or IoT sensor streams at scale, Bigtable.
The non-relational databases are generally not ACID compliant in the traditional sense, though Firestore does offer transactional guarantees within documents. For use cases where you are reading and writing data for individual users or events rather than running complex cross-table queries, the NoSQL options are often faster and cheaper.
One reason organizations choose non-relational databases is horizontal scaling. Adding more servers to a NoSQL cluster typically scales both capacity and throughput linearly. Relational databases are harder to scale horizontally because maintaining consistency across multiple nodes while allowing SQL joins is a complex engineering problem. Cloud Spanner solves this, which is why it is unique and also why it is more expensive than Cloud SQL.
Bigtable scales to handle petabytes of data and millions of operations per second by distributing data across many nodes. The row key design becomes critically important at that scale, but the database itself can grow with your workload without a fundamental architecture change.
The Associate Cloud Engineer exam does not require you to know the internal implementation details of these databases. It expects you to match scenarios to services. A healthcare company stores patient records with consistent schemas and needs transactional guarantees: Cloud SQL. A gaming company needs a leaderboard that can handle millions of reads per second with minimal latency: Memorystore. A company ingests sensor data from ten million devices: Bigtable.
The exam also tests whether you know the limits. Cloud SQL has a maximum storage per instance. Cloud Spanner costs significantly more than Cloud SQL. Bigtable requires careful row key design to avoid hotspots. These limitations shape the right answer in scenario questions.
My Associate Cloud Engineer course covers all of these database services with the scenario-based framing the exam uses, including the decision framework for choosing between them under pressure.
Most real applications use more than one database type. A typical e-commerce platform might store order records in Cloud SQL for transactional integrity, cache product listings in Memorystore for fast page loads, store user session data in Firestore for its flexible document model, and load historical order data into BigQuery for analytics and reporting.
The ACE exam occasionally presents multi-service scenarios where you need to select the right database for each component of a system rather than choosing a single database for the whole application. Recognizing that different parts of an application have different data characteristics and access patterns is the skill being tested. Transactional data goes to a relational service. Cache data goes to a key-value store. Analytical data goes to BigQuery. Each component gets the database that fits its requirements.
