Neki——PlanetScale 推出的分片 Postgres
文章摘要
PlanetScale CEO Nick Van Wiggeren 于 2026 年 9 月 10 日宣布，Neki 进入平台预览阶段。Neki 是 PlanetScale 推出的分片 Postgres 产品，脱胎于这家公司八年来运营全球最大规模分片 MySQL 集群的经验——数千个生产负载、每秒数百万次查询，服务的都是”哪怕停机几秒也会上新闻”的客户。
为什么做这件事
一年半前 PlanetScale 发布 Postgres 支持时就知道事情没完。这期间他们接入了数千客户，其中一些规模已经堪比他们最大的 MySQL 客户。团队反复看到同一个场景：团队把 Postgres 逼到单机天花板。裸金属能买来一些时间，但当客户触到单机能力上限时，他们发现拿不出好选项。Neki 就是为此而生。
文章列举的典型痛点包括：表大到无法在不影响流量的前提下做 vacuum 或建索引、备份要跑好几个小时、连接数上限、为改 schema 开维护窗口、事务 ID 回卷等等。换更大的机器终究会用完”够大的机器”，而且问题并不随核数和 IOPS 线性缓解。
作者对现有方案的批评是：它们各自都要你放弃点什么。应用层分片把路由逻辑推进业务代码；Postgres “兼容”的分布式数据库把分片键藏起来、拿走你的扩展，同时引入难以处理和调试的复杂度与延迟。因此 Neki 的首要设计原则被表述为：坚持 Postgres，不绕开它、不假装它、不背离它。
架构：四个部件
- Neki 路由器：应用先连到路由器，它说标准 Postgres 线协议，所以现有驱动、ORM、连接串都不用改。路由器内含完整的 Postgres 查询解析器、分布式查询规划器和查询缓冲等能力：解析查询、规划该由哪些分片执行、分发出去、再把结果合并成一条流。路由器可纵向也可横向扩展，避免单点瓶颈。
- 分片与分片组：每个分片都是真正的 Postgres，1 主 + 至少 2 从，跨 3 个可用区。没有魔改的存储引擎，所以扩展、SQL 支持和性能表现都和 Postgres 一致。分片被组织成分片组，不同的表或负载可以落在不同的分片集合上；每个分片使用一份配置档案，定义实例规格、副本数、存储、Postgres 参数和扩展。
- 连接池：每个 Postgres 实例旁都跑一个 sidecar。文章强调这是 Neki 的连接处理比”在数据库前面摆个 PgBouncer”更有意义的地方：因为 Neki 同时控制连接的两端（路由器侧和 Postgres 侧），它能按实例实际能承载的量来定池大小，而不是从进程外面估。
- 控制平面：跟踪每个节点健康状况，执行计划内切换和计划外故障转移，并协调重分片、schema 变更、版本升级等工作流。
- 数据拓扑：把上述部件串起来的是一份 JSON 配置，把逻辑表映射到物理分片。你定义分片索引（路由依据的列以及取值如何哈希）和分片组（一组表铺在多少个、哪些分片上）。路由器缓存拓扑，并在每次规划时查阅。
在线运维
文章的另一个卖点是：凡是通常需要开维护窗口的操作，在 Neki 里都是内置工作流。工作流会开出新目标节点、用复制追平、用一个 __neki 元函数切换流量、然后退役旧节点——全部通过应用使用的同一条 psql 连接完成。覆盖范围包括 schema 变更、版本升级、计划内外故障转移、导入和重分片。
一个重要的产品定位是：你不需要第一天就分片。可以先把 Neki 当成单主多从来跑，先享受改进的连接池、在线 DDL、零停机升级和健康监控；等真的撑不住了，重分片只是一个针对现有集群运行的工作流。此外 Insights、schema 建议、branching、MCP 等 PlanetScale 既有能力都还在。
平台预览的含义：官方明确表示不应把生产负载放在预览阶段的 Neki 上，产品仍在变化，其中一些变更会是破坏性的。
HN 评论精华
276 分、150 多条评论。这条讨论的真实走向和技术关系不大——绝大部分热度落在两件事上：这篇发布博客写得糟不糟，以及 PlanetScale CEO 在社交媒体上对竞品的态度。技术性追问反而是零散的少数。
开篇就被吐槽”看不懂你在发什么”
gk1 的顶楼评论逐段点名：Intro 讲了问题但没说 Neki 是什么；Why Neki 讲了替代方案多烂但没说 Neki 是什么；How does Neki work 描述了技术组件但没说它是什么；后面几节同理。他随后两次编辑：先说落地页 neki.dev 的信息量是这篇的一百倍，再说”他们已经加上了 What is Neki 一节，反应速度不错”。
这条引出了一场元讨论。dwb 反问：落地页链接就在第二句话开头，这不就是超链接在正常工作吗？fastball 更直接：博客结构是”我们发了 Neki → 为什么需要它 → 它是什么（带标题）”，”读不到第三段是你的问题，不是博客的问题”；crooked-v 一句话拆台：他们评论的时候”它是什么”那一节还不存在。haul_up 则站在另一边：”发布文章第一句就该回答’这是什么’，得刨到第三段是失败，不是读者的问题。”
simonw 借题发挥了一句被高赞的感慨：”可惜在 2026 年，你永远不该假设有人会点链接。”被追问为什么可惜时他说：链接是网络最棒的东西，但越来越多用户要么误解要么主动回避它们——人们在社交媒体上宁可发文章截图也不发链接，有时是无知，但更多时候是因为今天的网页体验太糟糕：付费墙、订阅弹窗、cookie 警告、加载缓慢。
核心技术追问：一致性与跨分片事务
这是少数几条真正的技术线，而且大多没有得到官方的完整回答。
arrowleaf 说，看分布式系统他第一个想知道的就是一致性怎么处理，结果在博客和 neki.dev 上 Ctrl+F 搜 “consis” 零命中，”所以我只能假设它是最终一致，且对实时系统来说副本延迟可观”。Atreiden 说自己向开发团队推荐分布式 Postgres（如 RDS Aurora Global）时，收到的最大顾虑就是最终一致性不适合很多负载，Neki 是否解决了这个问题、代价是什么。
mcpherrinm 基于 Vitess 经验给出了实际答案：常规做法是按用户之类的维度分区，让单个用户获得一致的视图，但跨分片的东西就不保证了。他在 Block 工作时，Cash App 用 Vitess，把跨分片写入搞对是落地的主要障碍之一。osalberger 补了一个更精确的表述：假设每个分片是可重复读或更高隔离级别，整体的一致性保证是并行快照隔离，技术上仍高于 Postgres 的读已提交；如果每个分片是可串行化且你把事务切分到不跨分片，应用在技术上仍是可串行的，只是表现得像两套互相独立的部署。
ragall 注意到全文没提跨分片的外键或其他约束，怀疑根本没实现，那样的话”有用，但停留在十年前 Spanner 的水平”。PlanetScale 的 spongeboi 出面澄清：跨分片事务是支持的，但原子的两阶段提交跨分片事务还在开发中。ragall 追问得很到位：文档里说”不同表或负载可分配到不同分片组”又说”随负载增长切分热分片”，这两者如何交互？单张表能跨多个分片吗？如果能，不是需要 2PC 才能保证主键约束吗？他还刻薄地评价：”这些介绍页读起来就像 AI 生成的废话。” pgdog 的作者 levkk 也留言说想有机会对比两家的实现（如果 Neki 开源的话）。
eile23 问跨分片 join 和事务怎么处理、哪些查询模式需要改应用。PlanetScale 的 imjosh-dev 回答：跨分片 join 会被拆解成各分片上的单分片 select，然后在路由器里做 join；目前有一些查询模式尚不支持，正在补；在任何分片数据库上运行，最需要记住的都是减少跨分片查询的数量。SkiFire13 追问数据拓扑那篇文档并没说用不同切分键的表之间 join 怎么办、索引怎么办。
klaussilveira 问 80 亿行以上的大表怎么办，imjosh-dev 回答完全由用户决定，Neki 不自动分片，一切由数据拓扑控制。
最大的争议：闭源，以及 CEO 的姿态
这是整个讨论最热闹的部分。xyzzy_plugh 点火：PlanetScale CEO 一直在贬低 Multigres，吹嘘 Neki 如何优越，而 Neki 甚至不开源，”Sam，感觉你只是在玩把戏，恭喜你完成了——我看看笔记——一次闭源发布”。
CEO samlambert 全程在评论区高强度对线，回复风格极具攻击性：
- 回应开源质疑：”开源跟 Neki 对上一个连分片都不做的服务的扩展能力有什么关系？”
- 被 margalabargala 指出开源是选型时的重要考量、能让用户免受糟糕的公司决策影响后，他回：”你给 AWS 的客户干过活吗？如果干过，你为商业开源的毁灭贡献了不少。”
- 被 cschmatzler 拿出一年前公告里”准备好时我们会把 Neki 作为开源项目发布”的原话质问是否变卦时，190n 直接贴出两个 Web Archive 快照，证明那句话已经从博客里删掉了。
- samlambert 的辩解是：”谁说开源没价值？我在 GitHub 干了六年，显然热爱开源。我们用公司的钱维护 Vitess。为什么要冲着一家小公司来，而不去批评我们不得不这么做的原因？我很愿意开源 Neki，我也没说过不会。”
- 面对 Twirrim “如果他们闭嘴，我最多是无所谓，现在我确定永远不碰他们的产品”的评论，他回击：”人们以为这种评论真的会困扰我，好像我从你这儿少赚了一分钱，好像你有购买力或者能带来足以影响我营收的负载。我告诉你，我有付给 PlanetScale 数百万美元的客户告诉我，他们是因为我的 Twitter 账号才来的。所以你永远别想让我为此感到抱歉。”
parthdesai 的一句”技术可能很棒，但 CEO 给人的感觉像个混蛋”引出了长串讨论。mbesto 的总结被多人呼应：”没人说你说的话不真实——他们说的是你是个混蛋。你可以既是混蛋又是对的。“并附赠一条销售建议：”把精力放在贬低竞争对手上，通常不是好策略。”margalabargala 说得更直白：”如果一个人对’你是混蛋’的辩护是’但我说的都没错’，那他几乎肯定是个混蛋——没人指控你不诚实。”
也有替他说话的：tonyhb 说 Sam 不是混蛋，他的 Twitter 很棒，只是观点鲜明、干冷幽默，”你要是没见过他本人可能会误读语气”；cwisecarver 说他在 Zoom 上其实很和善；nateberkopec 说自己就喜欢 CEO 放开一点展现个性，”总比所有人都像受过媒体训练的机器人强”。反方 overfeed 说：”今天之前没听过这人，但他在 X 和这条讨论里散发的那股 edge-lord 气场让我不想认识他。”JeremyNT 则指出关键：”也许他在 Zoom 上很好，但我们绝大多数人不会在那种场合见到他，只能凭他公开发的东西判断。”
关于闭源动机，hiyer 给了一个被 samlambert 亲口确认的解释：这么做是为了让 AWS 这样的云厂商没法用它做自己的服务来吞掉 PlanetScale 的收入——”Google 大到可以承受开源 Vitess、k8s、Angular，PlanetScale 不行”。samlambert 回复：”没错。AWS 一直对我们做反竞争的事，我们不能让他们更轻松。”ezekg 建议他们看看 fair source 许可。fsuts 则点出反讽之处：PlanetScale 靠开源的 Vitess 起家，如今给 Postgres 做了个 Vitess 等价物却做成了专有产品（ksec 顺手纠正：Vitess 是 YouTube 而非 Google 造的）。
与竞品的对比
- Multigres：jbonatakis 说这是最先想到的竞品，虽然还没实现分片，但它由 Vitess 创造者、PlanetScale 联合创始人打造，而且开源，”低估它是愚蠢的”。samlambert 回应：”我们有旧产品和他离开前公司的反事实证据，完全可以断定 Multigres 做不成任何事。”PlanetScale 的 kelp 给出了更专业的版本：过去几年团队基于大量高负载客户经验改进 Vitess，当前约 70% 的代码是近五年写的；他承认”Vitess for Postgres”这个说法让他们有点上火，但强调到目前为止 Multigres 没有可用分片实现的公开证据，其分片设计文档本周才落地，且明确把跨分片查询规划和重分片执行列为范围之外。
- Citus：aamederen 问对比如何，imjosh-dev 贴出自家博客。StackGres 的 ahachete 逐条反驳该文的不准确之处：Citus 的任何节点都能当协调者、还有”无数据节点”模式让协调者可以任意多；加节点是 operator 该解决的问题，在 StackGres 里就是改 YAML 里一个数字；分片再平衡本来就内建为 Citus 的 UDF；至于”代理模型优于 Citus 架构”的暗示，他指出 Citus 本身也是代理模型，只不过代理恰好是 Postgres，所以推不出代理模型更好的结论。
- PgDog：devy 问对比，samlambert 回了六个字”它能用，而且做分片”。PgDog 作者 levkk 反击：”我们也一样，只不过 PgDog 开源、能跑在任何地方而不只是你的云上、是为 Postgres 而生而不是从 MySQL 转过来的。”
- MySQL 用户怎么办：IceWreck、tedd4u、MrDrMcCoy、dveeden2 分别推荐 Vitess/PlanetScale 本体、MariaDB Galera、TiDB。
其他零碎
xnx 问这在跟谁竞争。vira28 说面对超大云厂商是座难爬的山，samlambert 回应：”跑在 Aurora MySQL 上有史以来最大的数据库现在跑在 PlanetScale 上，跑在 Aurora Limitless 上有史以来最大的数据库也是。”tedd4u 作为前 GCP 用户现身说法：Spanner 很棒但也贵得惊人，CloudSQL 很棒但不解决写扩展，”Vitess+MySQL 加上他们的 branching/部署/监控工具这个组合，GCP 没有”。
Yannik_Sc 调侃 PlanetScale Metal 号称”无限 IOPS”，”听起来像技术奇迹，也让我怀疑这个领域还有多少宣称是奇迹、多少是神话”。cobbzilla 解读：”我觉得这是营销语，意思是’我们不限制它’，不是在陈述物理定律。”kelp 回复一个字：”对。”
kaycebasques 说自己正坐在一辆贴满 Neki 广告的 Muni 12 路车上，十分钟前刚查过 neki.dev，问是不是刻意把车身广告和发布日对齐的——kelp 说公交广告已经跑了一阵，还有几块广告牌。Hasz、behole 等多人夸这个页面的品牌设计漂亮。hanspagel 贡献了全场最好笑的一条：”我零用户的副业项目需要这个，但我担心 Neki 扩展性不够好”，后续发展成”我打算为每次数据库查询自动启动一个新 Kubernetes 集群”“性能不行就全部用 Rust 重写”的接龙。