To build a database that can grow and stay online, you must plan its architecture carefully. Scalability means the database can handle more work by adding resources, while high availability means it is designed to stay running even if a component fails. These goals are connected: a system that can scale often becomes more available because it can spread work across more parts. In Google Cloud, you achieve this by choosing the right database service and configuring it for redundancy, which means having backup copies of your data and servers ready to take over.
Google Cloud offers different managed database services, each suited for specific types of data and workloads. Cloud SQL is a managed service for traditional relational databases like MySQL or PostgreSQL, good for structured data and transactions. Cloud Spanner is a globally distributed relational database that offers strong consistency and high availability across regions. Firestore and Cloud Bigtable are NoSQL databases for flexible, semi-structured data or massive-scale workloads. The choice depends on your needs: if you need strong ACID transactions and a SQL interface, choose Cloud SQL or Spanner; if you need to store vast amounts of simple data with low latency, Bigtable might be better.
High availability is built by removing single points of failure. For a managed service like Cloud SQL, you enable the high availability configuration, which automatically creates a standby replica in a different zone within the same region. If the primary database fails, traffic automatically switches to the standby. For a global service like Cloud Spanner, your data is automatically replicated across multiple zones and even regions. The control plane manages these replicas, and the application connects to a single endpoint without needing to know which replica is currently primary.
Scalability is handled differently for each database service. For Cloud SQL, you scale vertically by increasing the machine’s CPU and memory. For Cloud Spanner and Bigtable, you scale horizontally by adding more nodes to the instance, which spreads the data and query load. The scaling operation is managed through the Google Cloud console, CLI, or API. It’s important to monitor performance metrics to know when to scale; scaling up too early wastes money, while scaling too late can hurt performance.
Applications connect to the database using specific endpoints provided by the Google Cloud service. To control access, you use Cloud IAM policies to define which users or services can manage the database instance. For the data inside the database, you use the database’s own native user accounts and permissions. Network access is controlled by configuring authorized networks or, more securely, by using the Private Service Connect or VPC Service Controls to ensure traffic stays within a trusted private network and does not cross the public internet.
Fascinated by the world of cloud databases? Explore the methods for structuring, scaling, and securing database solutions on Google Cloud as you gear up for the Professional Cloud Database Engineer exam!
Prepare and test your skills
Prepare and test your skills
Cloud SQL achieves high availability by automatically creating a standby replica in a different zone within the same region, and traffic switches to the standby if the primary fails. Cloud Spanner provides high availability through automatic replication across multiple zones and even regions, with the control plane managing replicas so the application connects to a single endpoint without needing to know which replica is primary.
Cloud SQL scales vertically by increasing the machine’s CPU and memory. Cloud Spanner and Cloud Bigtable scale horizontally by adding more nodes to the instance, which spreads data and query load. Scaling operations are managed through the Google Cloud console, CLI, or API.
Network access is controlled by configuring authorized networks, or more securely by using Private Service Connect or VPC Service Controls to ensure traffic stays within a trusted private network and does not cross the public internet. Additionally, Cloud IAM policies define which users or services can manage the database instance, while the database’s own native user accounts and permissions control access to the data inside.