从YouTube规模化之痛到PlanetScale：数据库如何在第一天就为未来而生

PlanetScale 的诞生并非源于一个商业点子，而是一次被超大规模系统“逼”出来的工程实践。本次分享中，创始人回顾了他们在 YouTube 扩展数据库的真实经历，并展示了 PlanetScale 如何试图让创业公司从第一天起，就避开第三、第四年才爆发的数据库灾难。

两个数据库老兵，25年后的第三次并肩作战

理解 PlanetScale，首先要理解它背后的人。CEO 兼联合创始人 Jatin Vaidya 和另一位联合创始人 Sugu Sougoumarane 早在 90 年代中期就在关系型数据库公司 Informix 共事，这是他们第一次合作。此后，两人的职业路径多次分叉又交汇：Sugu 先后加入 x.com、PayPal，并在 YouTube 被 Google 收购前几个月入职；而 Jatin 则在离开 Informix 后加入 Google 搜索质量团队。

真正改变他们技术命运的，是 2007 到 2013 年的 YouTube。Sugu 随收购来到 Google 后，把 Jatin 拉进了 YouTube，这也让 Jatin 成为“最早从 Google 转到 YouTube 的工程师之一”。那几年，YouTube 用户和流量呈指数级增长，而数据库扩展问题开始成为生死线。Jatin 直言，那不是抽象的‘可扩展性问题’，而是每天都在发生的生产事故。

正是在这种高压环境下，他们开始构建一个内部工具，用来解决 MySQL 在超大规模下的扩展问题。这个工具后来被开源，名字叫 Vitess。多年后回看，PlanetScale 并不是一个拍脑袋的创业项目，而是两位工程师在极端现实条件下，被迫打磨出来的“幸存者方案”。

Vitess 的核心洞见：让应用“假装”只有一个数据库

Vitess 是 PlanetScale 的技术基石，而它解决的问题非常具体：当单个 MySQL 实例无法承载流量时，如何在不推翻应用架构的前提下实现水平扩展。Jatin 对 Vitess 的定义很直接：它是一个“位于应用和多个 MySQL 实例之间的分片中间层”。

这里的关键洞见在于“视图统一”。Vitess 通过中间层，让应用程序看到的依然是“一个巨大的数据库”，而不是一堆分片后的 MySQL 实例。分片逻辑、路由规则、连接管理，全部被下沉到基础设施层。这种设计，直接源于 YouTube 的教训：如果把分片复杂性暴露给应用层，工程团队会被拖入无穷无尽的维护泥潭。

Vitess 的成熟也不是一蹴而就的。Jatin 提到，2017 年 Slack 和 Square 遇到了与 YouTube 类似的扩展瓶颈，他们亲自去给这两家公司讲解 Vitess，并说服对方投资时间和工程资源来使用、贡献这个项目。到 2017 年底，他们意识到一件事：基于 Vitess 构建商业化数据库服务，是一条可行的道路。

但他们并没有立刻创业，而是选择等待 YouTube 将 Vitess 捐赠给 CNCF（云原生计算基金会）。直到 2018 年初，这一步完成之后，PlanetScale 才正式成立。

为什么 PlanetScale 想成为你“第一天就选的数据库”

PlanetScale 的产品目标，被 Jatin 的同事 Sam 概括得非常直白：“我们的目标是，人们在创业第一天就选择 PlanetScale，并且如果我们做得足够好，他们永远不会遇到第三年、第四年才爆发的扩展问题。”

这种定位，直接反击了传统数据库的使用路径：先用简单方案，等规模上来再“痛苦迁移”。PlanetScale 试图把复杂性前置到平台，而不是留给未来的你。最典型的例子，是它的定价模型：按存储量、读取行数、写入行数三项计费。Sam 强调，他们“坚定地相信，你只应该为你消耗的东西付费”，并明确表示价格不会比用户使用 RDS 更贵。

在技术能力上，PlanetScale 明确为“serverless 世界”而设计。他们提到系统可以处理约 60，000 个连接，这正是无状态应用、大量短连接场景下的现实需求。对开发者而言，这意味着数据库不再是限制架构演进的瓶颈，而更像一个可无限伸缩的基础服务。

像用 Git 一样用数据库：分支与 Deploy Requests

PlanetScale 在开发者体验上的最大创新，来自两个概念：数据库分支（branching）和 Deploy Requests。前者的灵感非常明确——Git。Sam 解释说，你应该能够“像拉一个 Git 分支一样，拉出一个完全隔离的数据库副本”，用于实验、开发或测试，而不影响主分支。

Deploy Requests 则直击所有工程团队的噩梦：数据库迁移。Sam 直言，“migrations are scary and break production”。PlanetScale 基于 Vitess 的在线 schema 变更能力，把结构变更变成一种可审查、可回滚的流程，而不是一次高风险操作。

更有意思的是他们对未来的设想。Sam 提到，PlanetScale 正在推进一种能力：如果某个 Deploy Request 试图删除一个仍被代码引用的列，系统将直接阻止它发生。这意味着数据库开始具备“理解应用行为”的能力，而不是被动执行 SQL。

所有这些操作，不仅存在于控制台界面，也可以通过 pscale CLI 完成。Sam 强调，这种“所有功能都可脚本化”的设计，是为了适配真正的现代开发流程，而不是停留在演示层面。

把 MySQL 变成“实现细节”，而不是架构负担

在问答环节，有人直接问：你们现在用的还是 MySQL 吗？Sam 的回答很耐人寻味：他们的目标，是“缩小这个差距，让 MySQL 成为一个实现细节”。换句话说，开发者不需要每天思考自己在用什么数据库引擎，而只需要关心数据模型和业务逻辑。

这背后，是 PlanetScale 对企业级需求的持续投入，包括“无处不在的加密”、开发者无法直接读取明文数据、以及跨所有表的自动变更追踪。这些能力，明显来自他们在 Google 和 YouTube 服务大规模客户时积累的安全与合规经验。

当 Jatin 介绍公司现状时，也补充了一个时代背景：PlanetScale 在 2018 年成立，先后完成了 300 万美元种子轮和 2019 年由 a16z 领投的 2200 万美元融资。疫情之后，他们决定不再续租山景城的办公室，成为一家真正分布式的公司。这种组织形态，某种程度上也与他们所构建的“去中心化、可扩展基础设施”形成了呼应。

总结

PlanetScale 的故事提醒我们，真正有生命力的基础设施产品，往往不是从市场调研中诞生，而是从真实的生产事故中“熬”出来的。从 YouTube 的数据库危机，到 Vitess 的开源演进，再到今天试图重塑开发者使用数据库方式的 PlanetScale，他们始终在回答同一个问题：如何让规模不再成为创新的敌人。对于今天的创业者和工程师来说，最大的启发也许是——别等到第三年才为规模买单。

关键词： PlanetScale， Vitess， MySQL， 数据库扩展， 开发者体验

事实核查备注： Jatin Vaidya 为 PlanetScale CEO 兼联合创始人；Vitess 起源于 YouTube 并捐赠给 CNCF；PlanetScale 成立于 2018 年；2019 年获得 a16z 领投的 2200 万美元融资；定价维度为存储、读取行数、写入行数；系统可处理约 60，000 个连接；支持数据库分支与在线 schema 变更（Deploy Requests）。