PlanetScale 推出 Neki：原生 Postgres 分库方案
PlanetScale 正式推出 Neki 平台预览版，这是基于八年运营超大规模分片 MySQL 集群经验打造的新一代数据库方案。针对 Postgres 在单机性能瓶颈、备份耗时及连接限制等痛点，Neki 坚持不修改核心存储引擎，确保每个分片都是真实的 Postgres。通过 Neki routers、智能连接池及控制平面，它实现了无缝的分片扩展、在线 DDL 及零停机升级。用户无需重写代码即可利用现有驱动和 ORM，享受从单实例到分布式集群的平滑演进。目前 Neki 处于平台预览期，欢迎开发者体验并反馈。
我们构建 Neki 的核心原则是：坚守 Postgres，而不是绕过它、伪造它或背离它。
HN 评论区
131- Yannik_Sc
我喜欢 PlanetScale Metal 上提供的这项服务。
他们声称提供无限的 IOPS（每秒 I/O 操作数）。
我自己也想弄点这种硬盘。听起来简直是技术奇迹。
但另一方面，宣称这种奇迹让我忍不住怀疑，这其中还有哪些部分是真的技术突破，又有哪些只是神话或虚假营销。
- gk1
各位，在发布产品时，请务必说明你们推出了什么以及它是用来做什么的。最好在开篇第一段就讲清楚。
- 简介：解释了问题，但没说 Neki 是什么，也没说它是用来干嘛的。
- 为什么是 Neki：解释了替代方案及其缺点，但没说 Neki 是什么，也没说它是用来干嘛的。
- Neki 如何工作：描述了技术组件，但没说 Neki 是什么，也没说它是用来干嘛的。
- 分片之外的优势：解释了如何运行/部署，但没说 Neki 是什么，也没说它是用来干嘛的。
- 什么是平台预览 + 立即试用 Neki：用了 140 个字定义“预览”并提供了开始链接……但没说 Neki 是什么，也没说它是用来干嘛的。
编辑：落地页（landing page）开头提供了多 100 倍有用的信息 -> https://neki.dev/
编辑 #2：他们随后增加了一个“什么是 Neki”的板块。反应速度不错。
- Atreiden
当我向开发团队提议使用高可用分布式 Postgres（例如通过 RDS Aurora global）时，他们最大的顾虑是最终一致性并不适用于许多工作负载。
Neki 是否解决了这个问题？如果是，它是如何解决的？根据我对 CAP 定理的理解，这基本上需要在可用性方面做出一些妥协，但我很好奇在实际操作中具体是怎样的。
- xyzzy_plugh
PlanetScale 的 CEO 一直在贬低 multigres[0]（Supabase 的 Neki 等价物），并得意洋洋地吹嘘 Neki 多么优越，然而 Neki 甚至不是开源的！
Sam，感觉你只是在玩弄手段。你说的话或做的事很难让人认真对待。你打算把这个开源吗？还是决定要退缩了？
恭喜你搞了个“查看笔记”式的闭门发布，是吧？
- fsuts
有点讽刺的是，PlanetScale 的公司是建立在 Google 构建的开源 Vitess 之上的，
而现在 PlanetScale 却为 Postgres 打造了一个类似 Vitess 的等价物，并将其变成了专有软件。
- hanspagel
我的那个零用户的小项目需要这个，但我好奇 Neki 的扩展性是否足够好。
- eile23
跨分片（cross-shard）的 JOIN 和事务是如何处理的？即使使用相同的驱动和 ORM，是否有某些查询模式需要修改应用程序代码？
- erulabs
我很高兴看到这一点，但作为一个重度 Vitess/MySQL 用户，我确实担心 PlanetScale 会分散精力。希望看到他们在 Vitess 方面也能持续改进。
抛开自私的疑虑，恭喜 PlanetScale 发布新产品！