[gh123man]

This seems cool. I am currently shopping around for a cheap managed database for an app I am launching soon (and bootstrapping - so cost is a concern right now). We are starting small but want room to grow. The free tier looks really promising! Especially compared to some of the entry level plans on other cloud providers.

Can anyone who has tried Planetscale and compared it to other managed database solutions tell me about their experience?

[boiler_up800]

I've tried Aurora and Firebase. I think PlanetScale wins on 2 areas at 2 different scales: branching when you're small, and connections when you're large.

With branching it's a feature where every dev can run a command and get their own database version to mess with. They can submit a pull request and as the tech lead I can check it and publish it to prod. Or integrate it with our CI.

On connections, it is interesting how serverless architectures totally flip the model. My node servers used to make a few connections to Postgres while serving thousands of users. Now, each NextJS instance makes its own connection and I might have thousands of database connections for thousands of users. PlanetScale is the only one I know of with effectively no limit on the number of connections. I think Aurora tops out at 16,000.

[MapleWalnut]

PlanetScale branching only copies the schema, not the data.

from their docs:

> Note: Data from the main database is not copied to development branches.

https://docs.planetscale.com/concepts/branching

[the_duke]

Does the branching system have an anonymization layer? At pretty much every company that is beyond "tiny startup with < 10 employees" you really don't want to give every developer read access to all customer data.

[remorses]

It is pretty awesome

The dashboard is clean and easy to navigate

The branching feature is really good idea, it allows you to confidently run migrations with no downtime

The daily backups are also great, no additional steps to set them up

They also have a graph to check query latency which is nice

The only downside is that they dont have foreign keys but I used prisma referential integrity for that so not really an issue for me

[porker]

> The branching feature is really good idea, it allows you to confidently run migrations with no downtime

So this branching feature is one I still don't understand properly.

Let's imagine my startup is big enough to warrant a PlanetScale database. Hundreds of rows are written every second. When I branch, are those writes applied to the original and the branch? If so, what happens with migrations that mean the incoming writes no longer work? Or is the "confidence" it gives not about full migrations but about knowing that if your migration fails the original DB is still working?

[aseipp]

Every branch in PlanetScale has its own separate MySQL connection credentials first off (and conceptually just looks like a separate DB), so no. You'll be using your main production database as usual, and you'll have separate credentials for a branch where you can make schema changes like ALTER TABLE, and you "connect" to that branch with... whatever. Deploy a canary version of your app, use your SQL IDE, whatever. The main branch always prohibits changes like ALTER TABLE or CREATE DATABASE. Merging a branch where the CREATE/ALTER happened is the only way to bring changes to the production database that serves your users queries.

When you merge a branch in PlanetScale, you can still write to the database while the migration is happening, online. This is done through "Online Schema Change", but the TL;DR is that a system in the background creates the new database, reads the mysql binlogs from your original database, including all the writes, and propagates those writes to the new database with the changes applied. It does this continuously, in real time. Once the new database is caught up, the system switches over transparently to make the changes atomically appear live.[1]

The requirement is that the running application server has to be able to handle both the old and new schema at the same time. This is easy if you do something like "add a column that isn't yet used and will be soon", but harder for "dropping a column that is in use". No database alone can solve this however, you have to coordinate your application layer correctly so that it can handle the switch over when you apply the changes. But this means you can have very high uptime with e.g. blue/green deployments and staged rollouts, and you'll never have to take your DB offline for it.

It's also trite but "hundreds of writes a second" is nothing. Vitess can handle 100x that write load (probably much more) and deal with schema changes to petabyte-scale databases completely online. PlanetScale currently doesn't let you control the Vitess keyspace sharding configuration (yet) which is crucial to this but I suspect it will happen eventually. But they'll also let you run Vitess in your own K8S environment while they provide a control plane, so you wouldn't pay list price, anyway.

I do not have any affiliation with PlanetScale but it's a pretty cool product I could see myself using for my low-volume needs, just because of the pay-as-you-go model where I don't pay for e.g. RDS allocation. And I say that as a really big PostgreSQL fan.

[1] https://github.com/github/gh-ost

[dewey]

I think going for a speciality database at this stage is premature optimization. Go with the safe choice (Existing tooling, knowledge, free tiers) and use Postgres or something else established. Later on you can always move workloads to other databases if needed.

[AYBABTME]

It's not really specialized, it's a fancy MySQL until you need more. And then, it becomes 'more' at the click of a button. IMO if I were starting a cheap MySQL-powered project today, I'd use their free tier. The branching stuff is genius, and they're really focused on offering a clean user experience.