Building PlanetScale with PlanetScale(planetscale.com)
planetscale.com
Building PlanetScale with PlanetScale
https://planetscale.com/blog/building-planetscale-with-planetscale
22 comments
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.
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?
What other differences are there vs MySQL in terms of data modeling?
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.
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
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).
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
From what I understand, they only branch the schema. They don't copy the data.
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)
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.
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)
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?
[1]: https://www.youtube.com/watch?v=YqBG5rFP4Ic
[2]: https://github.com/leerob/leerob.io/pull/326