Cloud SQL is one of those services that shows up across the Professional Cloud Architect exam in a very specific way. The exam wants you to recognize when a workload calls for a managed relational database, and to distinguish that pattern from analytical workloads or NoSQL patterns. I want to walk through what Cloud SQL actually is, what OLTP means in practice, and how to read a question on the Professional Cloud Architect exam that points toward Cloud SQL.
Cloud SQL is a cost-effective, fully-managed relational database service on Google Cloud. The word "managed" is doing a lot of work in that sentence. Google handles the infrastructure, the backups, and the patches. You bring the schema, the queries, and the data.
It supports three engines: MySQL, PostgreSQL, and SQL Server. The first two are first-class citizens. SQL Server is supported but with some limitations compared to MySQL and PostgreSQL, and that distinction occasionally matters on exam questions that mention specific SQL Server features.
The core value proposition is a direct lift-and-shift. If you have a traditional MySQL or PostgreSQL workload running on a virtual machine or on-prem, Cloud SQL lets you migrate that workload without rewriting the application. The connection strings change. The query layer does not.
Cloud SQL is suitable for small to medium-sized datasets, single-region deployments, and transactional use cases. Each of those three properties matters.
"Small to medium" is the boundary that separates Cloud SQL from Spanner. When a question describes a workload that needs to scale globally, or describes data volumes in the multi-terabyte range with high write throughput, Cloud SQL is usually the wrong answer and Spanner is usually the right one.
"Single-region" is the second boundary. Cloud SQL has read replicas and high-availability configurations, but its design center is a regional database. If a question stresses global distribution or active-active multi-region writes, Cloud SQL is not the answer.
"Transactional" is the property that defines what Cloud SQL is good at. It offers strong consistency, fast queries, and ACID compliance. ACID matters when you are worried about data integrity in the face of concurrent transactions or failures, which is the world of operational systems.
OLTP stands for Online Transactional Processing. The word "transactional" is the key. OLTP workloads are dominated by INSERT, UPDATE, and DELETE statements that touch a small number of rows at a time and need to complete quickly.
The classic examples are e-commerce checkout, banking, inventory management, and CRM. In each case, the system is recording or modifying state in real time on behalf of a user or a transaction. Latency matters. Correctness matters. The volume of data per operation is small.
Cloud SQL is good at this. The combination of ACID guarantees and a familiar relational engine is exactly what these workloads need.
The contrast that the Professional Cloud Architect exam expects you to understand is OLTP versus OLAP. OLAP stands for Online Analytical Processing, and the canonical OLAP service on Google Cloud is BigQuery.
OLAP workloads look completely different. The operations are SUM, COUNT, AVG, MAX, MIN across vast datasets. The pattern is data mining, reporting, and trend analysis. The use cases are data warehousing and business intelligence.
An OLAP query touches millions or billions of rows and returns a small aggregate result. An OLTP query touches a handful of rows and either reads them or modifies them. Cloud SQL is built for the second pattern. BigQuery is built for the first.
When an exam question describes "a reporting dashboard over historical sales data" or "ad-hoc analysis across years of logs," that is OLAP and the answer is BigQuery. When a question describes "an order-processing system for an online retailer" or "a customer record system with frequent updates," that is OLTP and the answer is Cloud SQL.
A few patterns I would internalize before sitting for the Professional Cloud Architect exam:
If the question mentions MySQL, PostgreSQL, or SQL Server by name, and the workload is operational rather than analytical, Cloud SQL is almost always the right answer. If the question names a specific relational engine but adds requirements like global writes or horizontal scale to many terabytes, the answer shifts to Spanner.
If the question describes high-volume small transactions on a single-region workload, Cloud SQL fits. If it describes aggregations over historical data, the answer is BigQuery. If it describes flexible-schema document or key-value access, the answer is Firestore or Bigtable, not Cloud SQL.
If the question emphasizes "managed" and "lift-and-shift" of an existing relational workload, that phrasing is pointing at Cloud SQL.
My Professional Cloud Architect course covers Cloud SQL and OLTP alongside the rest of the databases material.
