PlanetScale is now generally available
I&#x27;m a bit confused with the &quot;branching&quot; [0] and &quot;non-blocking schema changes&quot; [1] features. I&#x27;m confused as they sound like &quot;the next big thing&quot; and I don&#x27;t see anything special here. Not saying are bad concepts or ideas, the contrary. But not really useful either. Surely I&#x27;m missing something, so I would love to hear from the PlanetScale team here if possible.<p>I have a strong and long Postgres operational background, so I may be also here with assumptions that might be different in MySQL&#x2F;Vitess&#x2F;PlanetScale. My main concerns&#x2F;questions are:<p>* I can&#x27;t imagine testing DDL changes <i>without data</i>. Having data there is so important to understand the change and its impact, that I won&#x27;t do them without data. And unless I&#x27;m mistaken, these branches only contain DDL, no data at all (&quot;data from the main database is not copied to development branches&quot;).<p>* 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&#x27;t it? I could do branches, merges, CI, comments on MRs, approval... I could even easily build a deploy queue (&quot;promote&quot;) with a CI. Doesn&#x27;t sound like too hard.<p>* I don&#x27;t understand how the &quot;safeness&quot; 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?<p>Again, not saying both concepts are bad. Terminology and methodology may be already an innovation. And surely I&#x27;m missing a lot. But other than this, I don&#x27;t see myself using this (testing migrations without data is a showstopper, and not the only one) and I don&#x27;t see much of an innovation from a safeness perspective here.<p>Why this system isn&#x27;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.<p>[0]: <a href="https:&#x2F;&#x2F;docs.planetscale.com&#x2F;concepts&#x2F;branching" rel="nofollow">https:&#x2F;&#x2F;docs.planetscale.com&#x2F;concepts&#x2F;branching</a><p>[1]: <a href="https:&#x2F;&#x2F;docs.planetscale.com&#x2F;concepts&#x2F;nonblocking-schema-changes" rel="nofollow">https:&#x2F;&#x2F;docs.planetscale.com&#x2F;concepts&#x2F;nonblocking-schema-cha...</a><p>[2]: <a href="https:&#x2F;&#x2F;postgres.ai&#x2F;products&#x2F;realistic-test-environments" rel="nofollow">https:&#x2F;&#x2F;postgres.ai&#x2F;products&#x2F;realistic-test-environments</a>