This chapter covers GCP's database services — a critical topic for the ACE exam, appearing in roughly 10-15% of questions under Objective 2.3 (Planning Solutions). You will learn the key characteristics, use cases, and limitations of each managed database: Cloud SQL, Cloud Spanner, Firestore, Bigtable, Memorystore, and BigQuery. The exam tests your ability to select the right service for a given workload based on consistency, scale, latency, and cost requirements. Master these distinctions to avoid the common trap of choosing a relational database when a NoSQL solution is more appropriate.
Jump to a section
Think of GCP database services as a massive hardware store with different toolboxes for different jobs. Cloud SQL is like a pre-assembled power drill kit: it comes with everything you need for common household tasks (relational queries, ACID transactions) and you just plug it in and go. Cloud Spanner is a robotic assembly line that can coordinate thousands of workers across a factory floor (global scale) while maintaining perfect order (strong consistency) — but you need a dedicated team to set it up. Firestore is a stack of sticky notes on a whiteboard: each note is a document, you can read or write any note instantly, and multiple people can scribble simultaneously without waiting for a lock. Bigtable is a giant spreadsheet with trillions of rows and columns, optimized for scanning millions of cells per second, but you can't do joins or transactions. Memorystore is a high-speed cache like a notepad on your desk: you keep frequently used numbers there to avoid walking to the filing cabinet (disk). Each tool excels at its intended job; using the wrong one leads to poor performance or high costs.
Overview of GCP Database Services
GCP offers a spectrum of managed database services, each optimized for different data models and access patterns. The ACE exam expects you to differentiate them by:
Data model (relational, document, key-value, wide-column, in-memory, analytics)
Consistency guarantees (ACID vs. eventual)
Scale (regional vs. global, terabytes vs. petabytes)
Latency (milliseconds vs. sub-millisecond)
Operations (fully managed vs. serverless vs. IaaS)
Cloud SQL
Cloud SQL is a fully managed relational database service for MySQL, PostgreSQL, and SQL Server. It provides up to 64 TB of storage, 416 GB of RAM, and 96 vCPUs per instance. It supports automatic replication, failover, and backup. Use cases: web applications, CMS, ERP, and any standard OLTP workload under 10 TB. The exam often presents scenarios with moderate read/write traffic and high availability needs — Cloud SQL with cross-zone high availability is the answer.
Key exam facts:
Maximum storage: 30 TB for MySQL/PostgreSQL, 64 TB for SQL Server (with increased limits)
Read replicas: up to 10 per primary, cross-region possible
Failover replica: one per region, synchronous replication via semi-sync
Automated backups: enabled by default, retained up to 365 days
Maintenance: can choose any window, updates are applied automatically
Cloud Spanner
Cloud Spanner is a globally distributed, horizontally scalable relational database service that provides strong consistency and ACID transactions across regions. It uses a combination of TrueTime (Google's globally synchronized clock) and Paxos consensus to achieve external consistency. Spanner is ideal for financial applications, global supply chains, and any workload requiring relational semantics at planetary scale.
Key exam facts:
Node count: minimum 1, maximum 1000+ (scales linearly)
Storage per node: 2 TB (in standard tier), 4 TB (in enterprise tier)
Max database size: 2 TB * number of nodes (effectively unlimited)
Consistency: external (linearizable) — stronger than typical ACID
Schema: relational with interleaved tables for parent-child relationships
Pricing: per node per hour ($0.90 USD per node-hour as of 2025) plus storage
The exam loves scenarios with global users needing strong consistency — Spanner is the answer, not Cloud SQL.
Firestore (Datastore mode & Native mode)
Firestore is a flexible, scalable NoSQL document database built for mobile, web, and server development. It offers two modes: - Native mode: provides real-time updates, offline support, and mobile SDKs. - Datastore mode: backwards-compatible with Cloud Datastore, used for server-side applications.
Firestore stores data in documents (sets of key-value pairs) organized into collections. It supports automatic multi-region replication, strong consistency (for single-region), and eventual consistency for multi-region queries. Use cases: real-time chat apps, user profiles, game state, IoT device metadata.
Key exam facts:
Max document size: 1 MB
Max write rate: 10,000 writes per second per database (can be increased)
Queries: indexed by default, composite indexes needed for complex queries
Pricing: pay for reads, writes, deletes, and storage; free tier includes 1 GiB storage and 50,000 reads/day
The exam often tests the difference between Native and Datastore mode — Native mode includes real-time listeners and offline persistence.
Bigtable
Bigtable is a fully managed, scalable NoSQL wide-column database for large analytical and operational workloads. It is the same database that powers Google Search, Maps, and Gmail. Bigtable is ideal for time-series data, IoT streams, financial data, and ad tech. It supports high throughput (millions of writes per second) and low latency (sub-10ms for reads).
Key exam facts:
Storage: HDD (cheaper, higher latency) or SSD (lower latency, higher cost)
Replication: single-cluster (strong consistency) or multi-cluster (eventual consistency)
Cluster resizing: can add/remove nodes without downtime
Max row size: 100 MB
Max cell size: 1 MB
Tablets: automatically split and rebalanced
Access: via HBase API or Bigtable client libraries
The exam often presents high-throughput, low-latency analytical workloads — Bigtable is the answer, not BigQuery.
Memorystore
Memorystore provides managed Redis and Memcached in-memory data stores. It is used for caching, session management, real-time leaderboards, and pub/sub messaging. Memorystore for Redis supports up to 300 GB per instance with read replicas and persistence options. Memorystore for Memcached is simpler, with no persistence or replication.
Key exam facts:
Redis tier: Basic (no replication) or Standard (replication, failover)
Persistence: RDB (point-in-time snapshots) or AOF (append-only file)
Max connections: depends on instance size (e.g., 1 GB instance supports 6,500 connections)
The exam tests when to use Memorystore vs. using Cloud SQL for caching — Memorystore is always the answer for caching.
BigQuery
BigQuery is a serverless, highly scalable data warehouse that supports SQL queries on petabyte-scale data. It separates compute from storage, allowing you to query data stored in BigQuery, Cloud Storage, or external sources. BigQuery is ideal for business intelligence, data analytics, and log analysis.
Key exam facts:
Query pricing: on-demand ($5 per TB processed) or flat-rate (slots)
Storage pricing: $0.02 per GB per month for active data, $0.01 for long-term
Maximum query size: unlimited (petabytes)
Streaming inserts: up to 100,000 rows per second
The exam often tests BigQuery vs. Cloud SQL for analytics — BigQuery is better for large-scale analytical queries.
Choosing the Right Service
When a scenario presents:
Relational, ACID, <10 TB, single region → Cloud SQL
Relational, ACID, global scale → Cloud Spanner
Document, real-time, mobile/web → Firestore (Native)
High-throughput, time-series, NoSQL → Bigtable
Caching, session store → Memorystore
Petabyte-scale analytics → BigQuery
Identify Workload Requirements
Start by analyzing the application's data model (relational vs. NoSQL), consistency needs (ACID vs. eventual), scalability (regional vs. global), latency (milliseconds vs. sub-millisecond), and access patterns (OLTP vs. OLAP). For example, a financial ledger requires strong consistency and ACID, ruling out eventual-consistency databases like Bigtable or Firestore multi-region.
Match to GCP Service
Use the decision matrix: If relational and under 10 TB, choose Cloud SQL. If relational and global, choose Cloud Spanner. If document model with real-time sync, choose Firestore. If high-throughput time-series or NoSQL with wide-column, choose Bigtable. If caching, choose Memorystore. If petabyte-scale analytics, choose BigQuery.
Configure High Availability
For Cloud SQL, enable high availability by creating a failover replica in a different zone. Cloud Spanner automatically replicates across zones. Firestore multi-region replicates to multiple regions. Bigtable offers replication across zones or clusters. Memorystore Redis Standard tier provides automatic failover. BigQuery is serverless and inherently HA.
Plan Backup and Recovery
Cloud SQL provides automated backups and point-in-time recovery (PITR) with binary logging. Cloud Spanner uses incremental backups via export/import. Firestore has automatic backups in Native mode (via PITR). Bigtable backups can be taken via export to Cloud Storage. Memorystore Redis supports RDB/AOF persistence. BigQuery has time-travel (7 days) and fail-safe (7 days).
Set Up Monitoring and Alerts
Use Cloud Monitoring to track CPU, memory, disk, and connections for each service. For Cloud SQL, monitor replication lag. For Spanner, monitor latency and node utilization. For Bigtable, monitor CPU utilization and storage. Set alerts for thresholds (e.g., 80% CPU). The ACE exam may ask about recommended metrics to monitor.
Scenario 1: E-commerce Platform with Global Users
A retail company launches a global e-commerce site. They need a relational database for inventory and orders with strong consistency across regions. They choose Cloud Spanner with nodes in US, Europe, and Asia. They configure interleaved tables for parent-child relationships (e.g., Order → Line Items). They use TrueTime to ensure linearizable transactions. Common misconfiguration: not sharding by customer ID, leading to hotspots. Performance: each node handles ~2,000 write QPS; 10 nodes handle 20,000 writes/s. Cost: ~$0.90/node-hour * 10 nodes * 720 hours = $6,480/month.
Scenario 2: Real-time Chat Application
A mobile app startup builds a real-time chat app. They use Firestore Native mode for user profiles, messages, and presence. They leverage real-time listeners to update UI instantly. They use offline persistence to support disconnected users. They create composite indexes for queries like "messages in a chatroom ordered by timestamp." Common pitfall: not setting up security rules properly, leading to unauthorized reads. Scale: a single Firestore database can handle 10,000 writes/s; they use sharding via multiple databases for higher throughput. Cost: $0.06/100k reads, $0.18/100k writes — for 1M reads/day, cost is ~$0.60/day.
Scenario 3: IoT Sensor Data Ingestion
A manufacturing company collects sensor data from thousands of machines. They need high write throughput (millions of writes/s) and low-latency reads for real-time dashboards. They choose Bigtable with SSD storage and single-cluster replication for strong consistency. They design row keys as machine_id#timestamp to avoid hotspots. They use Cloud Dataflow to write streaming data into Bigtable. Common mistake: using monotonically increasing row keys (e.g., timestamp first) causing hot tablets. Performance: one Bigtable node handles ~10,000 writes/s; they use 100 nodes for 1M writes/s. Cost: ~$0.65/node-hour (SSD) * 100 nodes * 720 hours = $46,800/month.
What the ACE Tests
Objective 2.3: Plan database services. The exam presents scenarios with specific requirements and asks you to choose the appropriate service. Key areas:
Differentiating between Cloud SQL and Cloud Spanner (single-region vs. global, ACID vs. external consistency)
Differentiating between Firestore and Bigtable (document vs. wide-column, real-time vs. high-throughput)
When to use Memorystore vs. Cloud SQL for caching (Memorystore always for caching)
BigQuery vs. Cloud SQL for analytics (BigQuery for large-scale, Cloud SQL for small OLAP)
Common Wrong Answers
Choosing Cloud SQL for global scale: Candidates see "relational" and pick Cloud SQL, ignoring the need for global distribution. Correct answer is Cloud Spanner.
Choosing BigQuery for real-time transactional workloads: BigQuery is for analytics, not OLTP. Correct answer is Cloud SQL or Spanner.
Choosing Firestore for high-throughput time-series: Firestore has a 10,000 writes/s limit and is not optimized for wide-column scans. Correct answer is Bigtable.
Choosing Bigtable for document storage: Bigtable is wide-column, not document. Correct answer is Firestore.
Numbers and Terms to Memorize
Cloud SQL max storage: 30 TB (MySQL/PostgreSQL), 64 TB (SQL Server)
Cloud Spanner node storage: 2 TB (standard), 4 TB (enterprise)
Firestore max document size: 1 MB
Bigtable max row size: 100 MB
Memorystore Redis max size: 300 GB
BigQuery streaming inserts: 100,000 rows/s
Edge Cases
If a scenario requires both relational and global scale but has a small dataset (<1 TB), Cloud Spanner is still the answer if strong consistency is needed across regions.
If a scenario requires caching but also requires persistence, Memorystore Redis with AOF persistence can be used, but the exam may test that caching is the primary use case.
If a scenario mentions "serverless" and "SQL", BigQuery is serverless but not transactional; Cloud SQL is not serverless. The exam may ask: "Which fully managed relational database is serverless?" — Answer: none, but Cloud SQL is fully managed.
Eliminating Wrong Answers
If the scenario mentions "global" and "strong consistency", eliminate Cloud SQL and Bigtable.
If the scenario mentions "real-time updates" and "mobile", eliminate Bigtable and Cloud SQL.
If the scenario mentions "petabyte-scale analytics", eliminate all except BigQuery.
If the scenario mentions "caching", eliminate all except Memorystore.
Cloud SQL is for single-region relational workloads under 30 TB; Cloud Spanner is for global relational workloads.
Firestore is for document-oriented, real-time, mobile/web apps; Bigtable is for high-throughput, time-series, wide-column data.
Memorystore is for caching and session storage, not persistent data.
BigQuery is serverless and for petabyte-scale analytics, not OLTP.
Know the max storage/row sizes: Cloud SQL 30 TB, Spanner 2 TB/node, Firestore 1 MB doc, Bigtable 100 MB row.
The exam often presents scenarios with global users and strong consistency — choose Cloud Spanner.
For real-time updates and mobile, choose Firestore Native mode.
For high write throughput (millions/s), choose Bigtable.
BigQuery streaming limit is 100,000 rows/s.
Memorystore Redis Standard tier provides automatic failover.
These come up on the exam all the time. Here's how to tell them apart.
Cloud SQL
Single-region only (regional)
Up to 30 TB storage (MySQL/PostgreSQL)
ACID transactions within region
Semi-sync replication for HA
Familiar SQL (MySQL, PostgreSQL, SQL Server)
Cloud Spanner
Global distribution across regions
Petabyte-scale (2 TB per node, up to 1000+ nodes)
External consistency (stronger than ACID) globally
Paxos-based synchronous replication
Custom SQL dialect with interleaved tables
Firestore
Document data model (JSON-like)
Real-time listeners and offline support
Max 1 MB per document
Strong consistency for single-region
Automatic indexing
Bigtable
Wide-column data model (column families)
High throughput (millions of writes/s)
Max 100 MB per row, 1 MB per cell
Strong consistency within a cluster
Manual row key design for performance
Mistake
Cloud Spanner is just a bigger Cloud SQL.
Correct
Cloud Spanner is fundamentally different: it uses TrueTime and Paxos for global consistency and horizontal scaling, while Cloud SQL is a single-region, vertically scalable MySQL/PostgreSQL/SQL Server instance. Spanner is not a drop-in replacement; it requires schema design for interleaved tables and distributed queries.
Mistake
Firestore is just a renamed Datastore.
Correct
Firestore offers two modes: Native mode (new) and Datastore mode (backwards-compatible). Native mode includes real-time listeners, offline persistence, and mobile SDKs. Datastore mode lacks these features. The exam tests the difference.
Mistake
Bigtable is a key-value store like Redis.
Correct
Bigtable is a wide-column store, not a key-value store. It supports column families, timestamps, and versions. Redis is an in-memory key-value store with data structures like lists and sets. Their APIs and use cases differ significantly.
Mistake
Memorystore can replace Cloud SQL for persistent storage.
Correct
Memorystore is an in-memory cache, not a persistent database. Even with AOF persistence, data loss is possible on failure. Use Cloud SQL or Spanner for durable data.
Mistake
BigQuery can be used for transactional workloads.
Correct
BigQuery is a data warehouse for analytical queries, not OLTP. It does not support row-level updates or transactions. Use Cloud SQL or Spanner for transactional workloads.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Cloud SQL is a managed relational database for single-region deployments with up to 30 TB storage. It supports MySQL, PostgreSQL, and SQL Server. Cloud Spanner is a globally distributed relational database that provides strong consistency across regions using TrueTime and Paxos. Spanner scales horizontally and can handle petabytes. Use Cloud SQL for regional workloads, Spanner for global.
Use Firestore for document-oriented data (e.g., user profiles, chat messages) that requires real-time updates, offline support, and automatic indexing. Use Bigtable for high-throughput, low-latency access to large volumes of time-series or wide-column data (e.g., IoT sensor data, financial data). Bigtable does not support real-time listeners or complex queries.
No. Memorystore is an in-memory cache designed for low-latency access. It can persist data using RDB or AOF, but it is not a durable database. If the instance fails, data may be lost. Use Cloud SQL or Spanner for persistent, transactional data.
For MySQL and PostgreSQL, the maximum storage is 30 TB. For SQL Server, it is 64 TB. These limits can be increased by contacting support.
BigQuery does not support row-level transactions or ACID guarantees. It is designed for analytical queries on large datasets. For transactional workloads, use Cloud SQL or Spanner.
Native mode provides real-time listeners, offline persistence, and mobile SDKs. Datastore mode is backwards-compatible with Cloud Datastore but lacks real-time features. The exam tests that Native mode is for mobile/web apps needing real-time sync.
Enable high availability by creating a failover replica in a different zone within the same region. Cloud SQL uses semi-synchronous replication to keep the replica up to date. Automatic failover occurs if the primary fails.
You've just covered GCP Database Services — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?