PlanetScale is now generally available

I would love to try this out but having only worked with MSSQL and Postgres for any large datasets I wanted to check size limitations of MySql and found this from 2020:

"In addition, a practical size limit on MySQL databases with shared hosting is: A database should not contain more than 1,000 tables; Each individual table should not exceed 1 GB in size or 20 million rows; The total size of all the tables in a database should not exceed 2 GB."

This seems to be parroted elsewhere.

2GB is nothing. Is this accurate?

I'm a bit confused with the "branching" [0] and "non-blocking schema changes" [1] features. I'm confused as they sound like "the next big thing" and I don't see anything special here. Not saying are bad concepts or ideas, the contrary. But not really useful either. Surely I'm missing something, so I would love to hear from the PlanetScale team here if possible.

I have a strong and long Postgres operational background, so I may be also here with assumptions that might be different in MySQL/Vitess/PlanetScale. My main concerns/questions are:

* I can't imagine testing DDL changes without data. Having data there is so important to understand the change and its impact, that I won't do them without data. And unless I'm mistaken, these branches only contain DDL, no data at all ("data from the main database is not copied to development branches").

* While it sounds neat, has a web UI and a CLI, managing branches of a schema and using CI and approval lifecycle... is something that sounds like I could do, and possibly better (as it is more integrated with tooling and workflows) from Git platforms themselves, isn't it? I could do branches, merges, CI, comments on MRs, approval... I could even easily build a deploy queue ("promote") with a CI. Doesn't sound like too hard.

* I don't understand how the "safeness" and the non-blocking nature of changes are ensured. Many DDL changes will take different amount of locks on rows or tables, which may cause some queuing and even lock storms in the presence of incoming traffic. Without incoming traffic, they may run fine. In other words: the impact of a migration can only be determined in combination with the traffic hitting production. How does PlanetScale do this? How for example is handled the case where a DDL changes the type of a column to another type which causes a table rewrite, which essentially locks the table and prevents concurrent writes?

Again, not saying both concepts are bad. Terminology and methodology may be already an innovation. And surely I'm missing a lot. But other than this, I don't see myself using this (testing migrations without data is a showstopper, and not the only one) and I don't see much of an innovation from a safeness perspective here.

Why this system isn't one where thin clones of the database are created as the branches (e.g. like in Database Lab Engine [2]), where you can play with data too, and then some data synchronization is performed to switch over to the branch once done (is not easy at all, but doable with many precautions)? That would be a significant improvement in the process, IMHO.

[0]: https://docs.planetscale.com/concepts/branching

[1]: https://docs.planetscale.com/concepts/nonblocking-schema-cha...

[2]: https://postgres.ai/products/realistic-test-environments

Ironically, they've only hijacked our ecosystems.

Now we need seperate access controls, seperate networking tools, seperate monitoring and diagnostics. It's becoming apearent to me that this kind of stuff is the scam of the century.

The best way for me to understand serverless is when Dave Syer made this quote:

["Serverless doesn't mean you don't have servers, you just don't care about them"](https://youtu.be/lJEYG2PjGNU?t=714)

Basically if you forget to query over an index and incur a full table scan, things are going to get very expensive, and it'll probably be a surprise since devs aren't going to bother checking charges run up.