Building PlanetScale with PlanetScale | Hacker News Reader

Building PlanetScale with PlanetScale

planetscale.com

87 pointsmschoening22 comments

I've been a fan of PlanetScale and recently was able to chat[1] with their Head of Eng. Great team, better product execution. Also moved my personal site from using Firebase/Redis to just MySQL with PlanetScale[2] and the results have been solid. Averaging 128ms on function response times with a p95 of 250ms.

[1]: https://www.youtube.com/watch?v=YqBG5rFP4Ic

[2]: https://github.com/leerob/leerob.io/pull/326

I've been building a small personal app with PlanetScale and I like it a lot. Their way of doing schema branching works well, and is easy to use (though slightly tedious), and makes a lot of sense. Not affiliated with them in any way, just a pleased customer.

I've been following PlanetScale for a few years and interviewed their CTO Sugu last week: https://www.softwareatscale.dev/p/software-at-scale-29-sugu-..., if anyone's interested to hear their story of building Vitess for YouTube and some details on PlanetScale behind the scenes.

PlanetScale is the serverless relational database we have been waiting for all this time. It's truly excellent, and being based on the same tech that runs youtube, we know it will scale well.

I noticed they just launched in aws eu-west-1 (Dublin, Ireland). There is now a new option to select the location when you create a new db. Yay it's now usable in Europe!

Personally, migrations have never been painful enough to warrant this sort of product. The idea of branching databases on the other hand is really cool. Is each branch a full copy? Seems like that would lead to huge storage needs for larger databases.

I had the impression they PS was interesting because they offer serverless SQL.

I've been PlanetScale for a test drive recently, and it's a bit of both. I also think they kind of go hand-in-hand: if you have "serverless" things (or just Docker), they can come and go with connections very quickly, so picking the correct "pause time" to take the DB down for an ALTER TABLE is possible but a tiny bit awkward. Online migrations mean you never take it down and it's always available so that's kind of moot.

But now you do have some other considerations (see below.) I don't think it's an absolute pancea, but it's certainly a very interesting and very useful secondary point in the design space. I like PlanetScale a lot. The free tier is also actually useful I think.

To be clear even if it's is "serverless SQL" you still have to design with the fact you're using Vitess in mind. So you have no foreign keys, scalability is done by keyspace sharding (not currently available in PlanetScale), apps deal with online migration where the schema evolves as they access it, etc. You have to keep these things in mind but you get some benefits in return, like most things.

> So you have no foreign keys

What other differences are there vs MySQL in terms of data modeling?

Interesting, I'd be fascinated to hear what tech you use, because I've always had a really hard time with migrations.

Any migration scheme with a timestamp based approach is going to work well (e.g. ActiveRecord, TypeORM).

The database branching idea seems to be popping up more and more. IIRC, TermniusDB supports it too - https://terminusdb.com/

I've not played with PlanetScale yet, but I am planning on playing with TerminusDB in the near future.

Yes - branching both schema and data in terminus - becoming more JSON oriented too with a new document API

From what I understand, they only branch the schema. They don't copy the data.

In the case of TerminusDB - which was mentioned in another comment - a branch is just a pointer, so isn't expensive. You basically get free clones, but don't have the risk of lots of messy copies of data everywhere

This looks quite compelling, but what about use cases where "serverless" is simply not viable. In some industries, you must control access to the server in order to stay compliant with regulations. At least for some of the data. Is there a plan to have a software-only release? Or did I just miss it.

We won't be doing software only releases or on prem software for PlanetScale. We do have an option to provision into your own cloud account so that the data lives inside your environment and you get all the PlanetScale magic.

Previous related thread:

PlanetScale – Database for Developers - https://news.ycombinator.com/item?id=27197873 - May 2021 (128 comments)

At Tiqets we have a different repo with SQL migrations using Flyway... ITs as simply as branching that repo, creating your migration. Getting the pipeline green and merging it back.

All migrations are automatically executed on production, pre-tested. Reviewed. No DB Administrator, No deployment together with the app.

It works quite well..

However, personally I really like not having to deal with schema changes. For example Firebase or Cloud DataStore is really nice... Its the best for developers, but not for data integrity.

This works fine for a lot of cases, but you can run into issues on larger databases. Things like default or calculated columns and indexes can seem like innocuous SQL but end up being incredibly expensive and even acquire locks that block other transactions on bigger databases.

We have some "medium sized" Postgres databases around 1-10TB and something like adding an index to a big table (100s millions of rows) can be quite expensive resource wise

(I'd say "big" is something like 20-50TB+ and small <1TB)

So is this product about the actual DB or the devex/ interface. Seems the real insight is in the latter. But the implementation is likely tied to MySQL. Would be cool to use with database of your choice, including existing managed dbs.

So you create a TCP connection to your database over the public internet? Does it have an http api like aurora serverless/fauna/datastax astra?

Reply on news.ycombinator.com