Comparing AWS’s RDS and PlanetScale

Hey folks, this is a quick read. 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 to using RDS at this point is Postgres support. So (for the time being) 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 DBs isn’t enough. It turns out that scaling a business’s database layer requires more than buying larger resources and provisioning bigger machines. Most often we see that when businesses scale they need to scale the connections to their DB as well.

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 upwards of 250,000 connections to a single database. Theoretically we can handle millions of connections-- but 250,000 is a real world number. 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’s 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).

This is often enough for a business to choose to switch, but we see a whole other set of developers who are bringing us onto their teams because of a 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 (or really most AWS services) you will see the negative comments mostly revolve around complexity and ramp time to understand the product. When we began designing PlanetScale’s recent 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 data 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 has created Database Branching 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 to automate this step and we hear lots of Next.js developers asking us to make this part of the Vercel development cycle (coming soon…).

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 pre-requisite 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 unlimited connections, data 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 free plan now and provision a database. It won’t cost you anything and if you tweet #speedydelivery to @planetscaledata on twitter we’ll send you a branded mail bag :)

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.

Look, AWS will always be an option, probably across every possible developer layer, but for databases we have designed a better alternative to RDS. And if you sign up for PlanetScale and end up disagreeing, I’d love to hear why → feel free to email me at jarod@planetscale.com.