Cloud SQL, we said, is the default choice for OLTP or online transaction processing workloads on Google Cloud. Let's take a quick look. Cloud SQL is an easy-to-use service that delivers fully managed relational databases. Cloud SQL lets you hand off to Google the mundane but necessary and often time-consuming tasks like applying patches and updates, managing backups, and configuring replications, so you can put your focus on building great applications. Cloud SQL is our managed service for third party RDBMSs. It supports MySQL, PostgreSQL, and Microsoft SQLServer. Additional RDBMSs will be added over time. What this means is that we provide a Compute Engine instance that has MySQL already installed. We'll manage the instance on your behalf. We'll do backups, we'll do security updates, and update the minor versions of the software so that you don't have to worry about that. In other words, Google Cloud manages the MySQL database to the point where you can treat it as a service. We even do DBA-like things. You can tell us to add a failover replica for your database, we'll manage it for you and you'll have a 99.95 percent availability SLA. Another benefit of Cloud SQL instances is that they are accessible by other Google Cloud services and even external services. You can use Cloud SQL with App Engine using standard drivers like connector J for Java or MySQL DB for Python. You can authorize Compute Engine instances to access Cloud SQL instances and configure the Cloud SQL instance to be in the same zone as your virtual machine. Cloud SQL also supports other applications and tools that you might be used to, like SQL Workbench, Toad, and other external applications using standard MySQL drivers. One of the advantages of Google managing your database is that you get the benefits of Google security. Cloud SQL customer data is encrypted when on Google's internal networks and when stored in database tables, temporary files, and backups. Every Cloud SQL instance includes a network firewall allowing you to control network access to your database instance by granting access. Cloud SQL is easy to use. It doesn't require any software installation or maintenance, and Google manages the backups. Cloud SQL takes care of securely storing your backed up data and makes it easy for you to restore from a backup and perform a point-in-time recovery to a specific state of an instance. Cloud SQL retains up to seven backups for each instance, which is included in the cost of your instance. You can vertically scale Cloud SQL, just increase your machine size. Scale up to 64 processor cores and more than 100GB of RAM. Horizontally, you can quickly scale out with read replicas. Google Cloud SQL supports three read replica scenarios. Cloud SQL instances replicating from a Cloud SQL primary instance. Cloud SQL instances replicating from an external primary instance, external, MySQL instances replicating from a Cloud SQL primary instance. If you need horizontal read-write scaling, consider Cloud Spanner. For the special case of failover, Cloud SQL supports this. Cloud SQL instances can be configured with a failover replica in a different zone in the same region. Then Cloud SQL data is replicated across zones within a region for durability. In the unlikely event of a data center outage, a Cloud SQL instance will automatically become available in another zone. All changes made to data on the primary are replicated to failover. If the primary instances zone has an outage, Cloud SQL automatically fails over to the replica. If the primary has issues not caused by its own outage, a failover doesn't occur. You can however, initiate failover manually. There are a few caveats. Note that the failover replica is charged as a separate instance. When a zonal outage occurs and your primary fails over to your failover replica, any existing connections to the instance are closed. However, your application can reconnect using the same connection string or IP address. You do not need to update your application after a failover. After the failover, the replica becomes the primary and Cloud SQL automatically creates a new failover replica in another zone. If you located your Cloud SQL instance to be near other resources, such as a Compute Engine instance, you can relocate your Cloud SQL instance back to its original zone when the zone becomes available. Otherwise, there is no need to relocate your instance after a failover. You can use the failover replica as a read replica to offload read operations from the primary. We keep saying that Cloud SQL is fully managed. We have also used the word serverless to describe BigQuery, for example. What's the difference? As a fully managed service Cloud SQL provides you access much like you have with an on-premises installation. For instance, you can directly connect to the Cloud SQL instance through the G-Cloud Client and perform tasks directly through SQL. However, Google helps you manage the instance by automating backups, setting up failover instances, and so on. Serverless is the next step up. You can treat a serverless product as just an API that you are calling. You pay for using the product, but don't have to manage any servers. BigQuery is serverless. So are Pub/Sub for asynchronous messaging and Dataflow for parallel data processing. You can think of Cloud Storage as being serverless as well. Sure, Cloud Storage uses disks, but you never actually interact with the hardware. One of the unique things about Google Cloud is that you can build a data processing pipeline of well-designed components, all of which are fully serverless. Dataproc, on the other hand, is fully managed. It helps you run Spark and Hadoop workloads without having to worry about setup. Given the choice between doing a brand new project on BigQuery or Dataflow, which are serverless, and Dataproc, which is fully managed, which one should you choose? All other things being equal, choose the serverless product.
