所有的“遥遥领先”都经不起推敲
digoal约 6 分钟PlanetScale发布Postgres云服务,吊打主流云厂商“胜之不武”
https://planetscale.com/blog/benchmarking-postgres
2025年7月1日，PlanetScale发布了PlanetScale for Postgres。 在过去的几个月里，PlanetScale一直专注于打造全球最佳的 Postgres 体验，包括性能。
为了确保PlanetScale达到数据库性能的高标准，需要一种标准化、可重复且公平的方法来衡量和比较其他选项。 PlanetScale构建了一个内部工具“Telescope”，作为创建、运行和评估基准测试的首选工具。
PlanetScale将其用作内部工具，以便在产品构建和调整过程中，快速向工程师提供产品性能演变的反馈。 PlanetScale决定与全世界分享，并为其他人提供复现这些发现的工具。
看对比数据, 似乎PlanetScale吊打了几乎所有主流云厂商的PG服务!
这怎么可能? 但事实就是这样, 例如PlanetScale 与 Amazon Aurora 基准测试
https://planetscale.com/benchmarks/aurora
以及更多:
PlanetScale 与 Google AlloyDB 对比 PlanetScale 与 Neon/Lakebase 对比 PlanetScale 与 Supabase 对比 PlanetScale 与 CrunchyData 的比较 PlanetScale 与 TigerData 对比 PlanetScale 与 Heroku Postgres
PlanetScale 是何来路?
PlanetScale 是一个基于 Vitess 开源项目的 无服务器（Serverless）MySQL 数据库即服务（DBaaS）平台，由 Vitess 的共同创造者和维护者于 2018 年创立，总部位于美国加利福尼亚州山景城。它专注于为开发者提供高性能、可扩展且兼容 MySQL 的云数据库解决方案，并引入了类似 Git 的分支管理功能，使数据库开发和管理更加灵活。
PlanetScale 的核心特点
MySQL 兼容性
完全兼容 MySQL 协议，现有的 MySQL 应用可以无缝迁移到 PlanetScale 上。 底层基于 Vitess（由 YouTube 开发的开源分布式 MySQL 集群管理工具），支持水平扩展。
无服务器架构（Serverless）
自动扩缩容，开发者无需管理服务器或数据库实例。 按使用量计费，免费套餐提供 5GB 存储、10 亿行读取/月、1000 万行写入/月。
数据库分支（Branching）
类似 Git 的分支功能，允许开发者创建独立的数据库分支（如 main和develop），进行测试或开发，然后通过 Deploy Request 合并回主分支。支持 Schema Diff（结构差异比对），确保变更可控。
全球部署 & 多云支持
支持 AWS、GCP 和 Azure 等多个云平台，可在不同地区（如美国、欧洲、亚太）部署数据库。 提供 SSL 加密连接，确保数据安全。
开发者友好工具
Web 控制台 和 CLI 工具（ pscale），方便管理数据库。可与 Vercel 等 Serverless 平台搭配，构建全栈应用。
适用场景
个人开发者 & 小型项目：免费套餐适合个人博客、测试项目。 企业级应用：支持高并发、分布式部署，适合 SaaS、Web 应用等。 CI/CD 集成：分支功能便于数据库版本控制和自动化部署。
限制
中国地区访问受限：部分用户反馈在中国大陆可能无法直接使用，需调整网络设置。 免费版限制：超出免费额度后，按存储和读写操作收费。
总结
PlanetScale 是一个现代化的 MySQL 云数据库服务，结合了 Vitess 的分布式能力 和 Git 式分支管理，适合需要弹性扩展、高可用性和 DevOps 友好工作流的开发者。
PlanetScale 吊打主流云厂商的秘密原来如此简单！
秘密就是本地存储.
被对比的PG 云服务产品都采用了云盘. 而PlanetScale 是本地存储.
云盘的特点(相比本地盘的优势):
多副本, 可靠性更好 数据在云盘, 当计算节点出现故障时, 故障转移更快. (在正常的服务器中再启动一个容器/ECS, 挂载数据云盘即可, 数据可以做到0丢失.) 存储空间几乎无上限. 扩展云盘块设备以及文件系统即可.
云盘的特点(相比本地盘的劣势):
延迟更高, 即使采用RDMA可能也比本地nvme略高, 如果是普通网络则延迟更高(可能在1个数量级以上) IOPS更低, 那些宣称IOPS很高的的云盘其实是需要并发才能达到的. 参考 专家都做不到100万！阿里云是不是在吹牛？ 吞吐(带宽)更低, 与IOPS指标一样, 宣称吞吐(带宽)很高的云盘, 也是并发IO才能达到的.
为什么PG本地存储和云存储会差这么大呢?
首先, 我们假设所有服务都使用了WAL同步提交模式, 抑或开启了WAL分组批量提交.
PS 番外篇:
PlanetScale给出的测试case:
tpcc 500G数据量
实例规格
32G内存 cpu相当 足够放下tpcc数据的存储 对比厂商采用云盘 PlanetScale 采用本地连接的具有无限 IOPS 的 NVMe 驱动器
测试场景性能差异分析
select 1 这个实际上取决于客户端和数据库端的网络带宽和延迟, 理论上和IO无关, 性能应该差别不大 tpcc 只读 因为数据量已经远超内存, 查询时肯定会发生物理IO, 所以云盘就非常吃亏(带宽和延迟都比本地盘高) tpcc 读写 提交时需要等WAL先落盘, 除非提高并发(触发分组提交), 否则性能一定比本地盘差. 即使触发分组提交, 云盘的IO延迟高一样比本地盘差, 只是差的没那么明显.
抖动分析
如果开启了FPW, 在进行检查点时, 可能写大量full page, 导致抖动. 同样也是云盘的IO延迟高, 抖动就更加明显
稳定性
在进行大量写、更新操作后, PG的表会膨胀到一定的比例, 由于目前vacuum不能单表并发垃圾回收, 所以云盘的IO延迟高的弱势又显现了. 在长时间测试后, 性能会比本地盘低, 因为膨胀更明显.
那是不是就建议PG使用本地盘呢?
当然不是, 原因是
本地盘如果坏了, 只能切换到只读实例, 如果不是同步流复制, 可能有数据丢失. 即使开启同步流复制, 也有缺陷, 因为只读实例的抖动也可能导致主实例抖动. 所以要开启同步流复制, 通常需要3节点或者2节点+WAL复制节点. 这样切换逻辑就比较复杂了, 切换时间可能更长. 成本也上去了. 切换主从时, 老版本可能导致逻辑复制丢失. 除非你升级到支持逻辑复制slot failover的版本.
说白了, 云原生PG, 基本上都是用云盘, 而不是本地盘.
更高级的PG则使用类似Oracle RAC的架构, 也是用的共享云盘或者共享存储. 例如 Neon、PolarDB、Aurora
同时, PG 18开始引入了AIO, 将大幅度降低IO延迟的影响.
《PostgreSQL 18 preview - 异步IO(AIO)应用到缓冲区管理器层面》 《PostgreSQL 18 preview - 异步IO支持io_uring, IO性能大幅提升》 《PostgreSQL 18 preview - 打开文件数限制max_files_per_process更新, 为异步IO io_uring做准备》 《PostgreSQL 18 preview - 重磅, 刚刚支持异步IO框架》 《PostgreSQL 18 preview - read_stream 启发式预读量优化, 异步IO准备》
总结
PlanetScale 的测试case没有问题, 但是用本地盘来对比云盘, 虽然性能胜了, 但是“胜之不武”啊.
否则云厂商干嘛不出本地盘的形态呢? 又不是技术上办不到.
且本地盘无法支撑高级PG架构, 例如存算分离的高级PG PolarDB、neon、Aurora等.
所有的遥遥领先都经不起推敲，你觉得呢？