PlanetScale 一个很有意思的云 MySQL 解决方案

[Livid]

https://docs.planetscale.com/

用管理代码库一样的 branching 的方式来测试和部署数据库的更改。

[LeeReamond]

不太理解是什么使用场景，如果每次都在 main 分支上提交的话，似乎与传统的锁行锁表也区别不大，如果在分支上再开新分支的话，这在数据库有啥用呢

[xingzhi]

@LeeReamond 跟代码的开发同理，db 的新分支用于修改 scheme ，开发测试，没问题后再应用 deploy 到 prod (main)

[LeeReamond]

@xingzhi 个人看法，无论如何，开发中就算有一丁点可能性动到生产服务器的数据，我都觉得是一件很可怕的事情。。

[Livid]

@LeeReamond 是啊，正是因为改表这件事情到了 2021 年都那么恐怖，所以看起来有希望的解决方案才会有价值。

[hlwjia]

一直有在关注！

看过几个用例，超赞

[catxo]

这个我记得之前站里有看到国人创业的类型的产品
也不知道是不是竞品 哈哈哈哈

[lockelee]

@catxo you mean bytebase. bytebase 管理 schema 变更，但是不 host db instance

[catxo]

@lockelee get
那么感觉 bytebase 更像一个 schema 版本控制器
代码和 schema 分离了，总担心变更期间的间隙会有意料外的事情

[clf]

现在最痛苦的是后端不仅仅是 mysql 一个数据库需要分支，得所有用到的数据库一起切分支才可以

[lockelee]

@catxo bytebase 应该也支持 schema as code

[panzhc]

@tianzhou

[tianzhou]

我们两家彼此的默契在于，我们看到的问题是一样，切入点都是开发工程师在开发应用时和数据库打交道的开发者体验。

有意思的是，我之前在 Google Cloud SQL 团队，做的是基于 Vanila 的 MySQL hosting 服务，而 PlanetScale 基于的是 Vitess 则用于 youtube ，也是当时除我们之外 Google 部署最大的 MySQL 集群。

不过 PlanetScale 是从中间件层解，而我们则是从工具层解，解法不一样。PlanetScale 的方法更加硬核一些，我们的则更贴近当下的用户。当然还有一种更硬核的做法，就是从引擎层解，估计马上也会有团队这样做的。

我个人也试用了一下 PlanetScale, 还读了一遍他的文档，是一个做的很好的产品。尤其加上和 Vercel 的配合，是有机会带来一个新的 V(ercel)P(lanetScale) 技术栈。

PlanetScale 和 Bytebase 要解的问题是有交叉，但目前的侧重点还不一样，不过未来发展久了，我们彼此都有去卷对方的可能性😅