FlightControl Home

We migrated from PlanetScale to AWS Aurora v2

Mina Abadir

On January 20, 2024, we moved our production database from PlanetScale to AWS Aurora RDS, a move that I did not personally anticipate to happen for at least two more years, if at all.

The main reasons are:

The History

In late 2021, when we started building Flightcontrol, we chose the following stack:

During this time, my main concern about that stack was the database. Databases keep me up at night, and we are a small team of two, and I do not want to be managing any servers. I know RDS is a managed service, but still, it is a fixed-size single node that does not scale with any traffic increase.

We wanted a serverless solution, and the options available during this time were mainly Aurora Serverless v1. I had first-hand experience with Aurora Serverless v1, and it was the worst experience I ever had with databases.

The two of us were talking, and I remember Brandon mentioning PlanetScale. Immediately, the product and the idea intrigued me. It is a database service that is serverless, and you are charged for the number of rows read or write. That is a dream come true for me. It supports MySQL only, but the benefits of having a serverless database where I do not need to worry about scaling issues were intriguing.

We have been using PlanetScale since then to host our production database on their Scaler Plan (originally branded Team plan).

PlanetScale introduces Scaler Pro plans

On July 6, 2023, PlanetScale announced the new Scaler Pro plans, and with this introduction, PlanetScale’s positioning started to change. Here is the quote from the announcement post:

As we've onboarded thousands of customers, large and small, one of the most common pieces of feedback people have given is that they're unsure how to map our pricing model onto their business. Reads and writes are easy to understand conceptually, but they don't map back to capacity planning that businesses are accustomed to. Many customers want more control than the traditional serverless model provides and clarity on how it compares to products like Amazon RDS and Google Cloud SQL.

PlanetScale announcement

This is a shift in the product and the main selling point for us, where they are no longer marketing the product as serverless, and their focus now is to offer high-performance databases.

Serverless database that is not actually serverless

Shortly after this new product announcement, as we checked our query insights, it appeared that some queries started to take longer than others. We had our indexes created, and it was not clear what we could do to enhance the performance. Then, a new CPU and memory chart appeared on our dashboard, showing our fully utilized cluster. That was when it was apparent that the product was moving away from the serverless positioning.

cluster utilization on planetscale dashboard

Also, the pricing page started using terms like “low-traffic” for their Scaler product.

old planetscale pricing page

That did not make sense because we are being charged on one dimension, which in this case is the row read and written. It did not make sense to show CPU & Memory, a completely different dimension that we cannot control.

We had a conversation with the team on Twitter, and it was clear that PlanetScale is moving away from the serverless positioning.

tweet by Brandon, confused about planetscale serverless
Taylor, a planetscale employee, providing clarification

Update: During the writing of this article, PlanetScale ultimately retired the Scaler Plan, keeping only the Scaler Pro plans, and removed all mentions of serverless from their marketing website.

Upgrading to Scaler Pro

After this conversation with the team, it felt to us that PlanetScale was not necessarily the right product to use, but we went ahead and upgraded to Scaler Pro; we immediately upgraded to PS-20 as we were basically on PS-10 previously. To my surprise, our CPU usage dropped to 40% immediately after this upgrade, which is great, but memory usage stayed at the high 80%. This surprised us, as we just doubled the memory available to our cluster, which did not have any effect. This could be due to page caching on Vitesse; the CPU kept spiking to high usage, which felt unclear.

cluster utilization after upgrading from ps-10 to ps-20
Cluster utilization after upgrading from PS-10 to PS-20

Shortly after the upgrade, we got our cost estimate, and our cost immediately increased from ~$100 to ~$250; the pricing breakdown did not make sense; for example, read-replicas had varying prices, with no information on the pricing per region.

Other PlanetScale limitations

Other PlanetScale limitations helped with the decision to move out of it:

Great things about PlanetScale

RDS Aurora v2 Benefits

RDS Aurora v2 Drawbacks

Migrating to RDS

The move to RDS was not that easy and needs its own blog post, but there are a few points worth mentioning in the context of this post.

Word of gratitude to PlanetScale

Any software, including Flightcontrol, has its limitations and various tradeoffs. You have to make an informed decision about what works for you. PlanetScale worked for us in the first two years, but we did not feel it was the right product as we are scaling and growing. We’re thankful for the product and team that served us well this far.

Deploy apps with utmost reliability, flexibility & performance

Learn more
App screenshotApp screenshot