Comparing AWS’s RDS and PlanetScale

By Jarod Reyes | September 30, 2021

We have been blown away by the reception to our product from the developer community, but maybe even more surprising are the number of customers switching from RDS to PlanetScale lately. I’ll do my best to quickly lay out the main reasons we see so many businesses switching to PlanetScale from AWS RDS.

Amazon RDS is a relational database service by Amazon Web Services. Essentially, RDS MySQL is a database in the cloud. PlanetScale is similarly a MySQL database hosted in the cloud, but with an emphasis on unlimited scale potential and developer-first design. The main advantage of using RDS at this point is Postgres support. So, if you are devoted to Postgres, RDS is your best bet. However, if you're looking for a database that will scale with your growth and that fits into your developers workflows, switching from RDS to PlanetScale is a no-brainer. Here are the top two reasons we see organizations and developers leaving RDS for PlanetScale: scalability and developer workflow.

Connection limits and other scalability issues with RDS

I know, it’s surprising that an AWS product like RDS has scaling limits, but it turns out hosting databases isn’t enough. Scaling a business’s database layer requires more than just buying larger resources and provisioning bigger machines. Most often we see that when businesses scale, they need to scale the connections to their databases as well.

PlanetScale is built on Vitess, the open-source database clustering system that was built to scale YouTube in 2010. Vitess continues to power the databases of some of the web's largest companies, such as GitHub, Pinterest, and more.

Vitess and PlanetScale have the ability to scale to nearly limitless connections. In fact, we recently ran some benchmarking showing our ability to run one million concurrent connections on a PlanetScale database. We'll dig more into this next.

All of the numbers below are based on real-world Vitess clusters

Scale issue #1: Connection limits

While RDS limits connections to 16,000, PlanetScale has been designed to scale to nearly limitless database connections per database. And while you can have up to 16,000 connections on RDS, you will have to manually upgrade and increase connection limits or create and manage your own connection pool. For developers building modern web apps, which often have thousands of simultaneous connections from different clients, this does not scale.

Scale issue #2: Connection pooling

Connection pooling is a well-known database access pattern that keeps database connections active so that when a database connection is later requested, one of the active connections are used rather than having to create a new connection from scratch. RDS MySQL will allow you to create up to 16,000 connections, but you will have to create connection pools yourself. With PlanetScale, Vitess elegantly manages the state of the connection pool, meaning you just make queries to your database without worrying about connections at all.

Bonus Feature — Query Consolidation

Vitess also makes sure that identical requests are automatically served to multiple clients simultaneously through a single query. Often, the outages we see from customers who were on NoSQL or RDS databases are cascading outages due to an initial spike in query response times. This is often due to anomalies or odd traffic patterns (think seasonal hits to your website). Vitess gets around this by identifying spikes in query attempts. So if 3 million people go to your YouTube video at once, Vitess will notice that multiple clients are simultaneously (or nearly simultaneously) attempting the same query and serve them all from the same connection.

Scale Issue #3: Total cost of RDS

Maybe most important to most businesses is pricing scalability. While RDS has a very complete picture of their pricing structure (it is 2740 words long, which is roughly 20% more words than are on the entire album Abbey Road by the Beatles), its rigidity does not lend itself well to sudden increases in database usage or quickly scaling your needs up or down. We’ve designed PlanetScale pricing to allow businesses to only pay for what they use, though we do have hybrid models that allow businesses to bring their own resources or indeed pay per machine (talk to sales if you’d like to discuss this more).

In the end, we saved 20-30% by switching to PlanetScale. — Barstool Sports

The scaling issues alone are often enough for a business to choose to switch to PlanetScale, but we see also see another set of developers who are bringing us onto their teams because of our simpler developer workflow.

PlanetScale’s developer workflows and non-blocking schema changes

It’s not entirely user friendly. There’s definitely a learning curve when starting to use the software —G2 Review of RDS

If you go onto G2 or any other review board for AWS RDS, you will see the negative comments mostly revolve around complexity and ramp up time to understand the product. When we began designing the PlanetScale cloud product, we knew that this was the main way we could improve the developer experience for databases — by removing the ramp up time and making critical routines like schema changes and CI/CD processes much easier to manage with a database.

Non-blocking schema changes

Making schema changes on RDS is complicated and often requires the use of multiple external libraries. Even worse, it often requires downtime or maintenance windows. This is becoming increasingly harder for DBAs and engineering teams to stomach when the suite of tools they use daily are making continuous deployments with no downtime easier and easier to do. Without a ton of your own orchestration, this is just not easily done with databases.

PlanetScale’s technology makes non-blocking schema changes a reality. PlanetScale allows you to deploy schema changes directly in the CLI and web UI. Additionally it will automatically check upstream for any other changes that may have been introduced in database branches and let you know if it is safe to deploy. You can read more about non-blocking schema changes on our docs.

The gist: PlanetScale will never require a maintenance window or downtime for a migration.

Staging branches and CI/CD workflow automation

I won’t go into too much detail about Continuous Integration/Continuous Deployment (CI/CD) — Red Hat describes it well here — but it has become the gold standard for engineering teams and it relies on easy automation of delivery and deployment tools. We at PlanetScale wanted to make creating a staging environment for your database much easier. But RDS developers recommend using mysql_dump to make a copy of your AWS MySQL production database for staging. This is why we introduced database branching.

PlanetScale created database branches to allow our customers to handle data like they handle features on GitHub. The ability to cut a branch of your database and then make changes and redeploy to your main database is a huge time saver. We already know of developers who are using the pscale CLI. You can find additional guidance in our Using the PlanetScale CLI with GitHub Actions workflows blog post.

The gist: Making a staging environment with up-to-date data schemas should not require a ticket to the data team.

Dev tools and documentation

One of the last reasons we see developers switching from RDS is the lack of great documentation or tooling. Our customers note that configuration alone for a new RDS resource requires hours of dev time. This is too much time to sink into processes that should be standardized and can be automated. Setting up a database should be easier in 2021.

Provisioning a new RDS Database requires a prerequisite number of steps followed by these 13 steps. Compare that to the ability to instantly provision a database on PlanetScale. A database that allows for nearly unlimited connections, database branches, and query insights for every instance. It’s just not a fair comparison. Honestly if you’d like to see how fast it is just sign up for a plan now and provision a database.

Takeaways

Clearly AWS RDS is optimizing for the incumbent industry mammoths who have engineering hours to spare and don’t move very quickly (Aurora is still on MySQL 5.7, not the latest version MySQL 8). But for every other business, we prioritized speed and scale. RDS offers a breadth of customization and configuration at the cost of needing to employ many more DBAs to manage your data store.

While AWS has managed to make compute resources globally reliable, their database layer still does not scale well. RDS does not scale nicely with businesses that are on a growth trajectory, hitting connection limits, replica limits, and indeed pricing floors that require you to manage your database more as you grow, not less. Businesses who are moving quickly need more support, more guidance, and should not be required to master a new interface. For this reason, we give all of our customers access to the database experts who built PlanetScale and Vitess in order to help them migrate to PlanetScale quickly and with the support they need.

PlanetScale does not offer the same customization, but does provision in seconds and allows businesses of all sizes (regardless of how many DBAs they hire) to reliably scale like experts. PlanetScale offers a much better developer workflow, which reduces time to feature and the overhead of needing to file a data ticket for every new feature.

If you'd like to test PlanetScale out, you can use our Database import tool, which allows you to import your RDS database to PlanetScale with no downtime if you choose to switch over. Check out our RDS migration guide for more information.