Cloud SQL and OLTP for the PDE Exam

Cloud SQL is one of those services that looks deceptively simple on the Professional Data Engineer exam. It is a managed relational database, you pick MySQL or PostgreSQL or SQL Server, and you move on. The trap is that the exam rarely asks you what Cloud SQL is. It asks you whether Cloud SQL is the right answer when a scenario already mentions transactions, row-level updates, ACID compliance, or a 50 TB workload that needs to migrate from on-prem. Getting those scenario questions right means knowing exactly where Cloud SQL stops being the right tool and something else takes over.

In this post I want to walk through how I frame Cloud SQL when I prep candidates for the Professional Data Engineer exam: what it is, why OLTP matters as a label, the storage ceiling that triggers a switch to Spanner or Bigtable, and how to spot the OLTP versus OLAP distinction in a question stem.

What Cloud SQL actually is

Cloud SQL is a cost-effective, fully managed relational database on Google Cloud. Google manages the underlying VM, the patches, the backups, and the failover. You manage the schema, the queries, and the connection strings. It supports three engines:

• MySQL
• PostgreSQL
• SQL Server (with some limitations compared to the other two)

The mental model I want you to lock in is that Cloud SQL is the lift-and-shift target for a traditional relational workload. If a question describes a team running MySQL or PostgreSQL on-prem and asks for the lowest-friction migration to Google Cloud, Cloud SQL is almost always the answer. You are not rewriting the application. You are not changing the SQL dialect. You are pointing the same connection string at a managed instance.

Cloud SQL is built for small to medium datasets, single-region deployments, and transactional use cases. It gives you strong consistency, fast queries, and ACID compliance. That last property matters, because ACID is the keyword the exam uses to tell you a workload cannot tolerate eventual consistency or weak isolation.

OLTP, and why the exam keeps using that acronym

OLTP stands for Online Transactional Processing. Cloud SQL is good for OLTP. That is the single most important sentence on this whole topic.

OLTP workloads are characterized by lots of small, low-latency, row-level operations:

• INSERT a new order
• UPDATE a customer's address
• DELETE a cancelled booking

You see OLTP patterns in operational systems: e-commerce checkout, banking ledgers, inventory management, CRM. The data is constantly changing, and every transaction needs to either fully commit or fully roll back. That is what ACID gives you.

The contrast on the exam is always OLAP, Online Analytical Processing, which is BigQuery territory. OLAP queries scan huge ranges and aggregate. SUM, COUNT, AVG, MAX, MIN over millions or billions of rows. Data mining, reporting, trend analysis, BI dashboards. BigQuery is purpose-built for that scan-and-aggregate pattern. Cloud SQL is not.

When you see a Professional Data Engineer question that mentions frequent inserts and updates, row-level transactions, or ACID compliance, the answer leans Cloud SQL. When you see aggregation across a warehouse, ad-hoc analytics, or petabyte scale, it leans BigQuery. Train yourself to scan the question stem for those signals before you even look at the answer choices.

Instance sizing and the 64 TB ceiling

Cloud SQL instances scale up to a maximum storage of 64 TB per instance. That number is worth memorizing because the exam loves to dangle a scenario that sits just above it.

If a workload needs more than 64 TB, you have three escape hatches, and the exam wants you to pick the right one based on the constraints:

• Spanner if you still need strong consistency and ACID compliance, and the workload is global or beyond Cloud SQL's vertical limit. Spanner is more expensive, but it preserves relational semantics at scale.
• Bigtable if NoSQL is acceptable and you need a high-throughput, low-latency wide-column store. Bigtable does not give you full relational ACID, but it handles strong consistency at the row level and scales to petabytes.
• BigQuery if the workload is actually analytical, not transactional, and you do not need ACID semantics. If the team only thought they needed Cloud SQL because that is what they had on-prem, but the queries are all aggregations, BigQuery is the better destination.

I would commit this routing logic to memory. Cloud SQL, Spanner, Bigtable, BigQuery: the question stem will give you the consistency requirement, the scale, and the workload type, and the right answer falls out of those three inputs.

How to think about Cloud SQL on exam day

When a Professional Data Engineer scenario lands on your screen, run through a short checklist:

• Is the workload transactional, with row-level reads and writes? If yes, lean OLTP.
• Does the question call out ACID, strong consistency, or relational schema? If yes, you are in Cloud SQL or Spanner territory.
• What is the data volume? Under 64 TB, single-region, and an existing MySQL or PostgreSQL footprint points squarely at Cloud SQL.
• If the answer choices include both Cloud SQL and BigQuery, ask whether the work is INSERT/UPDATE/DELETE or SUM/COUNT/AVG. That single distinction usually resolves the question.

Cloud SQL is not the flashiest service on the exam, but it shows up in enough questions that getting the OLTP framing wrong costs you points across multiple scenarios. Anchor on transactional workloads, ACID, the 64 TB ceiling, and the upgrade path to Spanner or Bigtable, and these questions become close to automatic.

My Professional Data Engineer course covers Cloud SQL alongside the rest of the storage and database services on the exam, with worked scenarios for choosing between Cloud SQL, Spanner, Bigtable, and BigQuery so the OLTP versus OLAP decision becomes reflexive.