Update: Google Stackdriver is now Google Cloud Logging and Google Cloud Monitoring. BindPlane will continue to integrate and support both of these products.
Relational databases have commonly been an essential component of every application. Cloud vendors like GCP have a service for relational databases. GCP’s relational database offering is GCP Cloud SQL, which is a managed service for relational databases similar to RDS from AWS.
Traditionally, you had to manage and operate a lot of things when working with databases on-premises. This includes things like installing and configuring the database engine, taking backups periodically, monitoring servers, patching servers, upgrading servers, etc. With a managed service like Cloud SQL or RDS, almost everything is the responsibility of the cloud vendor.
Maybe Cloud SQL is new to you. But if you already have experience with AWS RDS, this post is for you. Today’s post is not necessarily about comparing Cloud SQL features with RDS ones as in a comparison table. You’ll learn about Cloud SQL through the lens of RDS. I’m going to use the console wizard to create a database to learn about GCP’s offering.
Let’s get started!
To begin with, let me talk about the basics of Cloud SQL and how that translates into RDS terms.
As of today, Cloud SQL only has support for the following engines: MySQL, PostgreSQL, and SQL Server (in alpha). RDS has support for the same engines and more. Still, Cloud SQL features are as good as the ones from RDS. Another big difference is that in AWS you have a lot of options to choose for machine types. In GCP, you have fewer options—just shared-core machines for development purposes, standard, and high memory machine types. The bigger the VM is, the better performance you’ll get for the VM network.
Here’s the first screen when creating a database in GCP:
Notice that you’re able to create a database without a password, allowing anyone to connect with the root user. You have the option to set a password later. In this first section, you get to choose the region and zone for the server. In AWS, you don’t choose the region because it’s taken from the one the user is navigating in the console.
When you click on “Show configuration options,” you’ll see a section where you can add database flags. A database flag is similar to a parameter group in RDS. You can change the default values of the database server—for example, the default time zone.
Networking and Connectivity
As you might already know, networking in GCP is quite different from AWS. In RDS, you can create subnet groups that will define whether the database servers have public or private access. Although, you still have the option in RDS to specify if the database is public or private. In GCP, you can also configure public and private access. When you set private access, you have to select from which network GCP will assign a static IP address. You don’t have that type of control in RDS.
Another big difference is securing access to the database. In RDS, you can choose which security groups will be attached to the database. A security group is a mechanism to restrict or allow access at the networking level. In GCP, you can only restrict access by adding the static IP address(es) for public access. For private access, the configuration is limited to only a VPC at a time. If you connect from a VM in GCP, it has to be in the same region.
Private connectivity has its limitations, so to speak. For example, you won’t have access from on-premises or another VPC even if there’s VPC peering. You don’t have too much control to change any access restriction at this level, but you also have the SQL Proxy option. By using a SQL Proxy, you’ll be able to connect from on-premises or other networks. You can go more in-depth with this topic by reading the official docs on how to set up connections, among other things.
Networking and security are quite a bit more complicated in Cloud SQL than in RDS—security groups make this easier.
High availability (HA) is another important topic for Cloud SQL and RDS.
In RDS, you can configure Multi-AZ to increase HA in the same region. You can also set read replicas in a different region either for performance needs or to increase HA as well. When the primary server goes down, AWS manages the switch to a secondary server automatically at the DNS level. Your applications don’t have to change the connection string.
In GCP, you also have the option to create a read replica in a different zone, but not to a different region. If you want replication to a different region, you have to set up an external replica. In both clouds, you have to pay for the replica the same as you pay for the primary server.
A significant difference in Cloud SQL is how GCP manages the failover to a replica. When a failover happens, the switch is done by re-assigning the IP address to the replica. You don’t have to wait for any DNS cache, which is a better solution from the networking standpoint.
Backup and Storage Management
Both cloud vendors have the support for backups. You schedule a backup window, and the cloud vendor takes a differential backup every day. You can also make manual backups when you see the need. But the most significant difference is that in RDS you can retain automated backups after you delete an RDS instance, whereas in GCP, when you remove the database server, all automated backups are removed as well.
When you need to restore a backup, there’s also a difference. In RDS, you need to create a new instance. You have to take care of the switch—if you replace the server—or copy any missing data. Disruption is minimum, and you can control it. In GCP, you have to delete all its replicas before restoring a backup and recreating the replicas. But if you prefer, you can create a new server, or even restore a backup to another project.
At the time of configuring the storage, you’ll see in the Cloud SQL console that the more storage capacity you add, the better the disk throughput you’ll get—same as in AWS with RDS. You’ll also notice from the image below that in Cloud SQL you can configure to increase storage automatically when the server runs out of space. The same feature you have in RDS but under the name of storage autoscaling.
Last, but not least, pricing.
There’s no significant difference between how each vendor charges you for the service. And I’m not going to go deep and compare prices because many variables can affect your monthly bill. For example, the price for a MySQL is different from a PostgreSQL (GCP could charge you per core) database in both clouds. You also have to consider the transfer of data, storage, backups, etc. In both clouds, you’re charged by any replica server with the same pricing structure as the primary server.
An interesting aspect of GCP is that you have to pay for the instance IP address per idle hour. It’s not expensive, but still a cost you’d need to consider when creating a replica, for example.
Managed Relational Database Services
Much of the knowledge and experience you have with AWS RDS can still be used with Cloud SQL. The managed relational database offering from both vendors are very similar. Still, there are small differences, like how each vendor handles HA or if automated database backups can persist after deleting an instance. Many of the differences I included in this post will help you to manage and operate your database workloads in a better way. For example, important aspects like security where you won’t be able to access a private database instance in GCP in a conventional way outside the VPC.
I’d recommend you go and give it a try creating a Cloud SQL instance. It’s the best way to understand how different, or similar, these two services are from your needs.
|This post was written by Christian Meléndez. Christian is a technologist that started as a software developer and has more recently become a cloud architect focused on implementing continuous delivery pipelines with applications in several flavors, including .NET, Node.js, and Java, often using Docker containers.|