Database engineering is the discipline of designing, building, and maintaining the systems that store and organise a company’s data in Google Cloud. It matters for the PCDE exam because you must understand the broad landscape of database options and how each fits a specific business problem. This chapter gives you the map of that landscape so you can navigate exam questions about when to use Cloud SQL versus Spanner, how managed services differ from self-managed databases, and the core responsibilities of a database engineer.
Jump to a section
A simple way to picture Overview of Database Engineering on Google Cloud
A professional kitchen is a system built on rules. The refrigerator knows its zones: the dairy drawer stays cold, the freezer stays frozen, and the vegetable crisper maintains humidity. A cook does not store raw meat above fresh salad because that violates a basic rule of food safety. Every ingredient has a designated place, and every tool has a purpose.
A database engineer does exactly the same for a company’s data. They design the storage zones (different types of databases), set the rules for who can handle what (permissions), and ensure the whole system runs without spilling raw data into the wrong container. Google Cloud provides the kitchen itself, the appliances, and the prep stations, but the database engineer chooses whether to use the stand mixer or the food processor for a specific recipe. If the kitchen gets too busy (thousands of users ordering pizza at once), the engineer adds more workspace dynamically, a concept Google Cloud calls elastic scaling. The engineer also keeps the kitchen secure: they lock the walk-in cooler and control who has the master key, just like a database administrator manages access using Cloud IAM.
The result is a kitchen that never burns the toast, never loses the recipe, and always serves the right dish to the right customer, even when demand spikes on a Friday night.
A database is simply a place where an application stores structured information so it can be retrieved later. Think of a digital filing cabinet. Before cloud computing, companies bought physical servers, installed a database engine such as MySQL or Oracle, and hired database administrators to patch, back up, and monitor those servers. That model is called on-premises, because everything lives inside the company’s own building.
Google Cloud changes this model. Instead of owning the hardware, you rent storage and computing power from Google’s data centres. This shift is called cloud computing. Within Google Cloud, a database engineer decides between two fundamental approaches: managed databases and self-managed databases. A managed database, such as Cloud SQL or Cloud Spanner, means Google handles backups, patching, replication, and hardware failures. You only interact with the data. A self-managed database, for example running your own PostgreSQL on a Compute Engine virtual machine, requires you to do every maintenance task yourself.
Google Cloud offers several database services, each built for a specific type of workload. Here are the main categories:
- Relational databases (SQL databases): These organise data into tables with rows and columns. They enforce a strict schema, meaning each row must have the same columns. Cloud SQL provides managed MySQL, PostgreSQL, and SQL Server. Cloud Spanner is a globally distributed relational database that keeps data consistent across continents. - NoSQL databases: These do not use the rigid table structure. They are better for unstructured or rapidly changing data. Firestore is a document database for mobile and web apps. Bigtable is a wide-column database for large analytical workloads, such as time-series data from IoT sensors. - Data warehouses: These are specialised databases for analytical queries on massive datasets. BigQuery is Google Cloud’s serverless data warehouse. It can scan terabytes of data in seconds without needing to manage any infrastructure. - In-memory databases: These store data in RAM for extremely fast reads. Memorystore provides managed Redis and Memcached for caching. The role of a database engineer covers several activities. You design the schema (how tables relate to each other). You set up replication (copying data across regions for disaster recovery). You tune performance by adding indexes or adjusting query patterns. You implement security controls using Cloud IAM, which is Google’s system for granting fine-grained permissions to users and services. You also plan for scaling: when a application grows, you need to add more capacity without downtime. A critical concept is the shared responsibility model. Google secures the physical data centre, the network, and the hypervisor that runs virtual machines. The customer (that is, you, the database engineer) is responsible for securing the data inside the database: who has access, how data is encrypted, and whether backups are configured correctly. The PCDE exam tests whether you understand where Google’s responsibility ends and yours begins. Another key idea is the difference between a relational database and a NoSQL database in terms of consistency. Relational databases follow ACID transactions (Atomic, Consistent, Isolated, Durable). NoSQL databases often relax these guarantees to achieve higher speed or scalability. For example, Cloud Spanner offers strong global consistency, meaning every user sees the same data at the same time, even when writing from different continents. Firestore provides eventual consistency by default, meaning a write might take a few seconds to appear everywhere. Knowing when to choose one over the other is central to the PCDE exam.
Step 1: Identify the workload type
You examine the application's data requirements. Is it transactional (many small writes, like an e-commerce checkout), analytical (complex queries on large datasets), or real-time (fast reads from a cache)? This step determines which category of database engine you need.
Step 2: Choose the database service
Based on the workload type, you select a Google Cloud service. For transactional relational data, choose Cloud SQL (single region) or Cloud Spanner (multi-region). For mobile apps, choose Firestore. For time-series analytics, choose Bigtable. For analytical queries on massive data, choose BigQuery.
Step 3: Design the schema and access controls
You define the table structure (schema) and set up Cloud IAM roles to grant appropriate permissions. For example, you create a 'db_admin' role that can manage instances, and an 'app_user' role that can only read and write specific tables via database-level grants.
Step 4: Configure high availability and disaster recovery
You enable automated backups, set retention policies, and configure read replicas or multi-region replication as needed. For Cloud SQL, you enable point-in-time recovery. For Cloud Spanner, you set up a multi-region configuration to survive regional outages.
Step 5: Monitor and optimise performance
You use Cloud Monitoring to track metrics like query latency, CPU utilisation, and storage usage. You analyse slow queries and create indexes to improve performance. You also set up alerts for when the database approaches capacity limits, allowing you to scale before users experience delays.
Imagine you are the database engineer for a company called ShopFast, an e-commerce platform that sells handmade furniture. ShopFast started as a small website with a single MySQL database running on a laptop. Now it serves 50,000 customers a day, and the laptop can no longer keep up. The CEO asks you to migrate everything to Google Cloud without losing a single order. Step one: you assess the current setup. The MySQL database holds customer profiles, product listings, inventory, and order history all in one place. You realise this monolithic database is a bottleneck. The checkout team needs fast writes; the analytics team runs slow reports that block those writes. Your task is to split the database into specialised services, a pattern called microservices. For the customer profiles, you choose Firestore because each customer’s data is a single document that updates independently. For the inventory system, you choose Cloud Spanner because it must stay perfectly consistent: you cannot sell the same chair to two people. For the analytics reports, you set up BigQuery to run overnight queries without affecting the live site. You configure Cloud SQL for the legacy product catalogue because it already works well with the existing codebase, but you set up a read replica so that search queries do not slow down the main database. You enable automated backups with a 30-day retention policy using Cloud SQL’s built-in backup feature, and you configure point-in-time recovery so you can restore the database to any second in the past week. For security, you create a Cloud IAM role called 'inventory_editor' that only allows specific developers to modify inventory data. You encrypt all customer payment data using Cloud Key Management Service (Cloud KMS). You set up a VPC firewall rule to restrict database access to only the application servers, not the public internet. Finally, you test a disaster recovery scenario. You simulate a region failure by turning off the primary Cloud Spanner instance. The automatic failover kicks in within 30 seconds, and the application continues serving customers from a different region without data loss. The CEO is relieved. You have transformed a fragile laptop setup into a resilient, scalable system that can handle Black Friday traffic without breaking a sweat. As the database engineer, you designed every piece of this architecture and you monitor it daily using Cloud Monitoring and Cloud Logging to catch performance issues before they affect customers.
The PCDE exam tests your ability to choose the right database service for a given scenario, not just memorise feature lists. Expect scenario-based multiple-choice questions that describe a business requirement (low latency, global consistency, high availability, complex joins) and ask which Google Cloud database service fits best. The most important concepts that appear repeatedly:
- The difference between Cloud SQL and Cloud Spanner. Traps: Cloud SQL is for regional use; Cloud Spanner is for global use. Cloud SQL supports horizontal scaling only through read replicas (writes stay on one node). Cloud Spanner supports horizontal writes across regions. The exam will sometimes describe a multi-region application that needs strong consistency, and the wrong answers will suggest Cloud SQL or Firestore. Correct answer: Cloud Spanner. - The difference between Firestore and Bigtable. Firestore is for mobile/web apps with document structures and real-time updates. Bigtable is for analytical workloads with time-series data, such as IoT sensor readings. A common trap: the question describes a chat application with user profiles; the wrong answer suggests Bigtable because it is scalable. Correct: Firestore. - Cloud IAM roles and permissions. The exam expects you to know that Cloud IAM works at the project level (not database level). You cannot grant a user access to a specific table inside a Cloud SQL instance using IAM alone; you must also configure database-level permissions inside the database engine. Traps: questions that describe IAM controlling table privileges. Correct: IAM controls access to the instance or database itself; SQL grants control the tables. - The shared responsibility model. Exam questions will ask: who is responsible for patching the operating system on a Compute Engine VM running a self-managed database? Answer: the customer. Who is responsible for patching the same VM if it is part of a Cloud SQL managed service? Answer: Google. Traps: questions about network security, which is typically Google’s responsibility for the underlying network but the customer’s responsibility for application-layer firewall rules. - Backup and disaster recovery: The exam tests retention policies (how long can you keep backups?), point-in-time recovery, and cross-region replication. Cloud SQL supports automated backups with up to 365 days retention. Spanner has built-in multi-region replication. The trap: Cloud SQL does not offer built-in cross-region replication for writes; you need to use a read replica in another region. - Security keywords: encryption at rest (Cloud KMS), encryption in transit (TLS), Cloud Audit Logs for tracking who accessed data, and Customer-Managed Encryption Keys (CMEK) versus Google-managed keys. The exam expects you to know that CMEK gives you more control but requires more management. Know the following exact definitions by heart: managed service, serverless, horizontal scaling, vertical scaling, strong consistency, eventual consistency, ACID, schema, and project-level IAM. The exam sometimes asks you to identify the definition of a term like 'schema' or 'partitioning'.
A database engineer designs the data storage architecture, selects the right Google Cloud database service for each workload, and secures data using Cloud IAM and encryption.
Google Cloud offers managed databases (Cloud SQL, Cloud Spanner, Firestore, Bigtable, BigQuery, Memorystore) that each serve a distinct purpose: relational, document, wide-column, analytical, or caching.
Cloud Spanner is the only fully managed relational database that provides strong global consistency across multiple regions for both reads and writes.
Cloud SQL supports horizontal scaling via read replicas but does not support horizontal writes across regions.
Cloud IAM controls access at the project and resource level, not at the database row or column level.
The shared responsibility model means Google secures the infrastructure, and the customer secures the data, access policies, encryption keys, and backup configurations.
These come up on the exam all the time. Here's how to tell them apart.
Cloud SQL
Regional deployment only
Horizontal scaling for reads via read replicas; writes limited to one node
Best for applications with a single-region user base
Cloud Spanner
Global deployment with automatic multi-region replication
Horizontal scaling for both reads and writes across nodes and regions
Best for globally distributed applications requiring strong consistency
Firestore
Document database for mobile/web apps
Strong consistency per document, eventual consistency across documents
Supports real-time listeners for live updates
Bigtable
Wide-column database for analytical and time-series data
Strong consistency for single-row reads; eventual consistency for multi-row scans
Optimised for high throughput on large datasets, not real-time updates
Managed Database (e.g. Cloud SQL)
Google handles backups, patching, replication, and hardware failures
Higher cost per compute unit due to management overhead
Less operational control over configurations
Self-Managed Database (e.g. PostgreSQL on Compute Engine)
Customer handles all maintenance tasks
Lower cost per compute unit but higher operational effort
Full control over database configuration and custom extensions
Cloud IAM
Controls access at the project, folder, or resource level (e.g. create instance, delete database)
Works independently of the database engine
Cannot grant row-level or table-level access inside a database
Database-Level Permissions (SQL GRANT)
Controls access to specific tables, rows, or columns within a database
Configured using SQL statements like GRANT SELECT ON Table TO user
Operates within the database engine, not at the cloud resource level
Mistake
Google Cloud databases are all the same; you just pick one and store data.
Correct
Each database service (Cloud SQL, Spanner, Firestore, Bigtable, BigQuery) is designed for a specific workload pattern, and choosing the wrong one can cause performance failures or huge cost overruns.
Beginners often see the word 'database' and assume one size fits all. In reality, the exam tests whether you can match the workload to the correct engine.
Mistake
Cloud IAM can grant a user access to a specific row or column inside a database table.
Correct
Cloud IAM controls access at the project, folder, or resource level (like the entire Cloud SQL instance). Fine-grained access inside tables is managed by the database engine itself using SQL GRANT statements.
People assume cloud permissions work like file-system permissions. IAM is coarser and works at a higher level, which is a core exam distinction.
Mistake
Managed databases mean you never have to think about security or maintenance.
Correct
Managed databases offload patching and hardware management to Google, but you are still responsible for securing your data (encryption keys, access policies, firewall rules, and backup configuration).
The phrase 'fully managed' sounds like total responsibility transfer, but the shared responsibility model still places significant duties on the customer.
Mistake
Cloud Spanner is just a bigger version of Cloud SQL.
Correct
Cloud SQL is a traditional relational database limited to a single region for writes. Cloud Spanner is a globally distributed relational database that can handle write scaling across multiple regions while maintaining strong consistency.
Both use SQL, so beginners think they are interchangeable. The exam tests the specific global-scaling difference.
Mistake
BigQuery is just a database, so you can run transactional queries on live data in real time.
Correct
BigQuery is a data warehouse optimised for analytical queries on large datasets, not for transactional (OLTP) workloads. It is not designed for high-frequency inserts or row-level updates.
People see the web UI and think it works like an ordinary SQL database. The exam highlights that BigQuery is for analytics (OLAP), not transactions (OLTP).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Cloud SQL is a regional managed database for MySQL, PostgreSQL, or SQL Server, best for single-region applications. Cloud Spanner is a globally distributed relational database that provides strong consistency across regions, suitable for global-scale applications.
No, Cloud SQL is a managed service. Google handles patching of the database engine and the underlying operating system automatically during maintenance windows you configure.
Serverless means you do not provision or manage any servers. You simply load your data and run SQL queries. Google automatically scales compute resources up and down based on query volume, and you pay only for the data scanned.
Firestore offers strong consistency for reads after a write within a single document but only eventual consistency across multiple documents in a query. For a financial ledger, Cloud Spanner or Cloud SQL is better because they support ACID transactions across multiple rows.
Cloud IAM is Google Cloud's system for managing access to cloud resources. You use it to grant permissions to users or service accounts for actions like creating a Cloud SQL instance or viewing BigQuery datasets. It does not handle row-level permissions inside a database.
Google Cloud secures the physical infrastructure, network, and hypervisor. The customer is responsible for securing their data, managing identity and access (IAM), configuring network firewalls, and encrypting data with keys.
You've finished Overview of Database Engineering on Google Cloud. Continue through the PCDE study guide to build a complete picture of the exam.
Done with this chapter?