PlanetScale vs. Neon - MySQL 和 Postgres 间的第二仗

本文为「数据库全方位对比系列」第三篇，该系列的前两部作品为

---

根据 2023 年 Stack Overflow 调研，Postgres 已经取代 MySQL 成为最受欢迎和渴望的数据库了。

看起来 MySQL 和 Postgres 的爱恨交织还将继续。从原生的 MySQL vs. Postgres，到分布式的 TiDB vs. CockroachDB，再到云原生的 AWS Aurora vs. GCP AlloyDB，现在进入了下一章节：面向开发者的 serverless 数据库 PlanetScale vs. Neon。

一直以来，Bytebase 与 MySQL / Postgres 及其生态合作密切。业界最大的 MySQL & Postgres 托管服务之一 Google Cloud SQL 也是 Bytebase 创始团队的杰作之一。

我们就以下几个维度对 PlanetScale 和 Neon 进行了对比：

• 架构 Architecture

• 兼容性 Compatibility

• 开发者工作流 Developer Workflow

• 可靠性 Reliability

• 伸缩性 Scalability

• 可运维性 Operability

• 集成 Integration

• 合规 Compliance

• 开源 Open Source

• 定价 Pricing

• 融资情况 Funding

架构 Architecture

PlanetScale 是基于 Vitess 的分布式数据库。Vitess 采用 shared-nothing 架构，每个分片 (shard) 包含一个 MySQL 主节点和几个副本。VTGate 代理将应用程序请求转发到相应的分片。

Neon 采用 shared-storage 架构，分离了计算和存储，计算部分只是普通的 Postgres 服务器，而存储部分则是一个定制的多租户存储系统，由所有 Postgres 计算节点共享。

兼容性 Compatibility

PlanetScale 的 MySQL 兼容性受到了限制。

1. 底层 Vitess 的限制。Vitess 的 shared-nothing 架构本身就有兼容性限制。需要维护会话或跨分片操作的功能很难实现。

2. 产品权衡。比如为了支持在线 DDL，PlanetScale 完全禁止外键，这比 Vitess 对外键的限制更严格。

3. 云服务模式。没有超级权限或 LOAD DATA INFILE 这样可以访问 host 文件系统。

Neon 与原生 Postgres 基本兼容。

Neon 则实现了新的 Page 层，除此之外只是轻微修改了 Postgres 本身的代码。Neon 的兼容性仅受云服务模式的限制，类似于其他云托管数据库服务（没有超级用户或访问 host 文件系统）。

开发者工作流 Developer Workflow

PlanetScale 和 Neon 都是面向开发者的，但它们在介绍开发者工作流时选择了不同的侧重点。

PlanetScale 强调了从分支，迁移 schema，监控到回滚等端到端的体验。

Neon 则仅仅突出了一个功能，分支（branching）。他们专为此构建了 Copy on Write（CoW）的 Page 层，使得同时包含 schema 和数据的分支可以被瞬间创建出来，而且几乎没有任何成本。

可靠性 Reliability

Shared-nothing 架构天生具有容错性，因为数据被分片和复制了。Vitess 已经是经过许多全球知名企业验证的技术，PlanetScale 这些年来也证明了其可靠性，没有出现过大故障。

Shared-storage 架构需要更强的技术来使逻辑上看是单点（SPOF）的存储组件具备故障容错能力。Neon 有文章详细描述（https://neon.tech/blog/architecture-decisions-in-neon）其中的技术决策 。

作为一种开创性的数据库架构，Neon 的优势在于它建立在坚实的基础之上。PostgreSQL 本身非常稳定且支持完善的事务。Neon 的 Pageserver 也与 PostgreSQL 基于 WAL 的日志完美契合。此外，Neon 能够选择更现代的系统编程语言 Rust，这对于实现其存储层时来说非常合适。

伸缩性 Scalability

PlanetScale，顾名思义，能做到星球级 (Planet) - 伸缩 (Scale)。其 shared-nothing 架构使得其伸缩性接近线性增长 (scale-out)，底层的 Vitess 最初在 YouTube 内部开发，就是用于应对伸缩性的挑战，并且已经在其他大型互联网公司获得了验证：

• Slack: https://slack.engineering/scaling-datastores-at-slack-with-vitess/

• 京东: https://www.cncf.io/case-studies/jdcom-vitess/

相比之下，Neon 不像 PlanetScale 那样具备如此高的伸缩性，毕竟，它只是一个单节点的 Postgres 实例。但这个单节点也可以很好地进行纵向伸缩 (scale-up)。Neon 将存储和计算分离开来，因此两个部分可以分别独立进行伸缩。而且在云环境中，存储是无限的，计算资源也非常充足，因此可伸缩性往往仅受网络带宽限制。这种分离式架构还带来了弹性能力，在需要时可以轻松实现 scale-to-zero 的缩减或者从小到大的扩冲。

可运维性 Operability

PlanetScale 提供的是一套完整的托管数据库服务，它的定位是管理使用数据库的每个方面。

• Deploy requests and Branches - 用于数据库变更工作流

• Insights - 监控

• Boost - 提升查询性能

• Revert - 回滚

• Console - 在浏览器中提供类似 mysql CLI 的使用体验

• Backup - 灾备

虽然有这么多功能，PlanetScale 仍然能打磨好每一个。例如，Boost 就展示了 PlanetScale 将学术论文转化为优秀产品的实力。

Neon 相对较新，提供了基本的功能。

• 通过分支功能来实现灾备。

• 可视化的 SQL 编辑器与数据库进行交互。

SQL 编辑器很好用：Neon 嵌入了外部的 explain.dalibo.com 来展示查询计划。虽然界面看起来有点奇怪，但确实能解决问题。

集成 Integration

PlanetScale 本身已经是个很全面的数据库平台了，它的文档站还列了一系列集成：

• 支持主要的语言应用程序框架。

• 使用 Datadog 监控。

• 通过 Airbyte, Stitch 和 Hightouch 进行数据传输。

Neon 尚未积累很多标配的数据库集成，但 Neon 独特的功能解锁了新的集成可能：

• Snaplet 使用 Neon 来瞬间提供生产数据库快照以供测试环境使用。

• Replit 使用 Neon 的 scale-to-zero 为用户提供低成本的数据库服务。

• Vercel + Neon 的 branching，可以在几分钟内（而不是几小时）提供部署预览。

合规 Compliance

PlanetScale 拥有 SOC 2 Type 2 和 HIPAA 认证。

Neon 目前已完成 SOC 2 Type 1 。

开源 Open Source

PlanetScale 和 Neon 采用了一致的策略，他们的代码库都采用了相同的自由开源许可证，并只对云服务收费。

PlanetScale 基于 forked 的 Vitess 分支，用的是 Apache-2.0 证书。PlanetScale 的团队还曾经打造过 gh-ost，是 MySQL 最好的在线 Schema 迁移 (Online DDL) 工具（可能也是所有开源关系型数据库管理系统中最好的）。他们还开源了 beam，一个展示 PlanetScale 功能的留言板网页应用。

Neon 的整个代码库也是采用了 Apache-2.0 许可证。

定价 Pricing

PlanetScale 根据用量计费 (usage-based)，基于读写行数。这在数据库服务中还是不太常见的，当时也引起了争议。一方面，它鼓励用户优化查询；另一方面，糟糕的查询是很难避免的，尤其是 MySQL 查询优化器本身也存在缺陷。为了消除争议，PlanetScale 最近推出了一个新的 Scaler Pro 套餐，提供无限制的行读写操作。

Neon 也是用量计费 (usage-based)，根据的是 4 个指标：活跃计算时间、数据存储、数据传输和数据写入。这种定价模型更加传统和可预测。Neon 还提供一个定价计算器来估算成本。

融资 Funding

两家公司都由行业老兵带领，且资金充裕：PlanetScale 迄今已筹集了 $1.05 亿美元，而 Neon 则获融到了 $1.03 亿（包括近期刚宣布的 B 轮融资 $4600 万）。

PlanetScale 还是 Neon?

总体而言，PlanetScale 为每个数据库任务提供了一致的体验。最初，它只是一个面向超大规模用户的兼容  MySQL 的 Vitess 托管服务。自从转向开发者市场以来，PlanetScale 已经转变成一个先进的 serverless 数据库平台，只是恰好是支持了 MySQL 方言。

Neon 面世的晚一些，并且与新的 PlanetScale 有非常相似的价值主张。与 PlanetScale 不同的是，Neon 从第一天起就明确知道自己的目标受众，并有意地去构建迎合他们的技术：

• 类似 Git 的分支管理，特别是可以立马创建出包括 schema 和数据的分支。

• 具备自动缩放的 serverless 数据库。

• 迎合 Postgres 的崛起，提供几乎完美的 Postgres 兼容性。

PlanetScale 和 Neon 之上

现在，在为下个项目选数据库时，首要考虑的已经不再是 Postgres vs. MySQL。相反，是考虑选择关系型数据库管理系统 (RDBMS) 还是其他类型的数据库。尽管 RDBMS 在数据库市场上仍占据主导地位，但讽刺的是，在云时代，这个领域并没有像其他数据库领域一样取得很大进展。用户确实有很多选择，但没有哪个能与 NoSQL 领域的 MongoDB Altas 或 OLAP 里的 Snowflake 媲美。

PlanetScale 和 Neon 彼此相似，而它们也与 MongoDB / Snowflake 相似：

• 类似 MongoDB，PlanetScale 采用了 shared-nothing 架构、提供完整的数据库平台、面向开发人员，并能够讲述出色的产品故事。

• 类似 Snowflake，Neon 将新颖的 shared-storage 引入到体系僵化的 OLTP 领域，使用 Postgres 方言，也同样重视开发者体验。

PlanetScale 和 Neon 都有可能成为现代关系型数据库即服务 (Modern RDBMS DBaaS) 中的下一个 MongoDB / Snowflake。我们都已经等了太久了😮‍💨。

---

不过， 如果你还是喜欢用原生的 MySQL 和 Postgres，并想要用 PlanetScale 的数据库变更工作流或 Neon 的可视化 SQL 编辑器，可以来试用一下 Bytebase。Bytebase 是个支持所有主流数据库的数据库工具，一站式覆盖数据库的变更、查询、安全和治理，提供了更多可定制的变更工作流，以及集成了数据访问控制和脱敏的可视化 SQL 编辑器。