Cloud SQL

Cloud SQL runs standard MySQL, PostgreSQL and SQL Server engines as a managed service. Your application connects with an ordinary driver and issues ordinary SQL. What changes is that provisioning, patching, backups, replication and failover are handled by the platform rather than by you.

Because it is the real engine rather than a compatible reimplementation, existing applications and tooling generally work unchanged. That compatibility is the main reason it is the most common first database choice during a migration.

Relational databases with ACID transactions remain the correct default for most application data. Orders, accounts, inventory and anything where correctness under concurrent updates matters belong in one.

The managed service removes the operational work that databases traditionally demand — the backup that was never tested, the patch that was postponed, the failover procedure nobody had rehearsed. These are the failures that cause real outages.

• Instance — a running database server with a machine size, storage allocation and configuration.
• High availability — a standby instance in a second zone with synchronous replication. Failover is automatic and keeps the same connection address.
• Read replica — an asynchronous copy used to serve read queries. Reduces load on the primary but can lag slightly behind it.
• Automated backups and point-in-time recovery — scheduled backups plus transaction logs, letting you restore to a specific moment rather than only to the last backup.
• Maintenance window — when the platform may apply updates that briefly restart the instance. Choose it deliberately rather than accepting the default.
• Cloud SQL Auth Proxy — establishes an authenticated, encrypted connection without exposing the database to the public internet or managing IP allowlists.
• Private IP — placing the instance on your VPC so it has no public address at all. The recommended configuration.
• Connection limits — a fixed maximum by instance size. Serverless applications that scale rapidly can exhaust connections; pooling is not optional at scale.

Failover is not instantaneous. There is a short interruption during which connections drop, so applications need retry logic. A design that assumes zero interruption during failover is incorrect, and exams test this.

• You need to scale writes beyond a single machine. Cloud SQL scales reads with replicas but writes go to one primary. Global scale-out writes require Spanner.
• You need a single database spanning regions with strong consistency. That is Spanner's specific purpose.
• Your data is huge, semi-structured and needs very high write throughput with simple lookups. That is Bigtable.
• Your workload is analytical — scanning billions of rows for aggregates. That is BigQuery, and running such queries against Cloud SQL will be slow and expensive.
• You want a flexible document model with real-time client synchronisation. That is Firestore.

• Transactional data for web and mobile applications.
• Content management and e-commerce back ends.
• Migrating an existing on-premises database with minimal application change.
• Reporting databases fed by read replicas so analytics does not slow the primary.
• Line-of-business applications where SQL Server compatibility is required.