本文为「数据库全方位对比系列」第三篇，该系列的前两部作品为：
根据 2023 年 Stack Overflow 调研，Postgres 已经取代 MySQL 成为最受欢迎和渴望的数据库了。
![file]()
看起来 MySQL 和 Postgres 的爱恨交织还将继续。从原生的 MySQL vs. Postgres，到分布式的 TiDB vs. CockroachDB，再到云原生的 AWS Aurora vs. GCP AlloyDB，现在进入了下一章节：面向开发者的 serverless 数据库 PlanetScale vs. Neon。
![file]()
![file]()
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 代理将应用程序请求转发到相应的分片。
![file]()
Neon 采用 shared-storage 架构，分离了计算和存储，计算部分只是普通的 Postgres 服务器，而存储部分则是一个定制的多租户存储系统，由所有 Postgres 计算节点共享。
![file]()
兼容性 Compatibility
PlanetScale 的 MySQL 兼容性受到了限制。
- 底层 Vitess 的限制。Vitess 的 shared-nothing 架构本身就有兼容性限制。需要维护会话或跨分片操作的功能很难实现。
- 产品权衡。比如为了支持在线 DDL，PlanetScale 完全禁止外键，这比 Vitess 对外键的限制更严格。
- 云服务模式。没有超级权限或 LOAD DATA INFILE 这样可以访问 host 文件系统。
Neon 与原生 Postgres 基本兼容。 Neon 则实现了新的 Page 层，除此之外只是轻微修改了 Postgres 本身的代码。Neon 的兼容性仅受云服务模式的限制，类似于其他云托管数据库服务（没有超级用户或访问 host 文件系统）。
开发者工作流 Developer Workflow
PlanetScale 和 Neon 都是面向开发者的，但它们在介绍开发者工作流时选择了不同的侧重点。 PlanetScale 强调了从分支，迁移 schema，监控到回滚等端到端的体验。
![file]()
Neon 则仅仅突出了一个功能，分支（branching）。他们专为此构建了 Copy on Write（CoW）的 Page 层，使得同时包含 schema 和数据的分支可以被瞬间创建出来，而且几乎没有任何成本。
![file]()
可靠性 Reliability
Shared-nothing 架构天生具有容错性，因为数据被分片和复制了。Vitess 已经是经过许多全球知名企业验证的技术，PlanetScale 这些年来也证明了其可靠性，没有出现过大故障。
![file]()
Shared-storage 架构需要更强的技术来使逻辑上看是单点（SPOF）的存储组件具备故障容错能力。Neon 有文章详细描述其中的技术决策 。
作为一种开创性的数据库架构，Neon 的优势在于它建立在坚实的基础之上。PostgreSQL 本身非常稳定且支持完善的事务。Neon 的 Pageserver 也与 PostgreSQL 基于 WAL 的日志完美契合。此外，Neon 能够选择更现代的系统编程语言 Rust，这对于实现其存储层时来说非常合适。
伸缩性 Scalability
PlanetScale，顾名思义，能做到星球级 (Planet) - 伸缩 (Scale)。其 shared-nothing 架构使得其伸缩性接近线性增长 (scale-out)，底层的 Vitess 最初在 YouTube 内部开发，就是用于应对伸缩性的挑战，并且已经在其他大型互联网公司获得了验证：
相比之下，Neon 不像 PlanetScale 那样具备如此高的伸缩性，毕竟，它只是一个单节点的 Postgres 实例。但这个单节点也可以很好地进行纵向伸缩 (scale-up)。Neon 将存储和计算分离开来，因此两个部分可以分别独立进行伸缩。而且在云环境中，存储是无限的，计算资源也非常充足，因此可伸缩性往往仅受网络带宽限制。这种分离式架构还带来了弹性能力，在需要时可以轻松实现 scale-to-zero 的缩减或者从小到大的扩冲。
可运维性 Operability
PlanetScale 提供的是一套完整的托管数据库服务，它的定位是管理使用数据库的每个方面。
![file]()
- Deploy requests and Branches - 用于数据库变更工作流
- Insights - 监控
- Boost - 提升查询性能
- Revert - 回滚
- Console - 在浏览器中提供类似 mysql CLI 的使用体验
- Backup - 灾备
虽然有这么多功能，PlanetScale 仍然能打磨好每一个。例如，Boost 就展示了 PlanetScale 将学术论文转化为优秀产品的实力。
![file]()
Neon 相对较新，提供了基本的功能。
- 通过分支功能来实现灾备。
- 可视化的 SQL 编辑器与数据库进行交互。
![file]()
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 采用了一致的策略，他们的代码库都采用了相同的自由开源许可证，并只对云服务收费。
![file]()
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 套餐，提供无限制的行读写操作。
![file]()
Neon 也是用量计费 (usage-based)，根据的是 4 个指标：活跃计算时间、数据存储、数据传输和数据写入。这种定价模型更加传统和可预测。Neon 还提供一个定价计算器来估算成本。
![file]()
融资 Funding
两家公司都由行业老兵带领，且资金充裕：PlanetScale 迄今已筹集了 $1.05 亿美元，而 Neon 则获融到了 $1.03 亿（包括近期刚宣布的 B 轮融资 $4600 万）。
PlanetScale 还是 Neon?
![file]()
总体而言，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 编辑器。
![file]()
💡 你可以访问官网，免费注册云账号，立即体验 Bytebase。
