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'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.
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
