Neki 是 PlanetScale 推出的分片版 Postgres，现已可用。它的每个分片都是真正的 Postgres，Neki 在其上加入路由器、边车和控制平面，把单机 Postgres 扩展到数亿 QPS 和 PB 级数据，且无需停机。应用连接到 Neki 路由器，由路由器把查询分发到各个 Postgres 分片，图中第四个分片正在在线拆分；工作负载增长时它可拆分热点分片，并让数据库保持在线完成数据布局重排。
正文
分片式 Postgres 现已推出
Neki 是 PlanetScale 推出的分片式 Postgres。每个分片都是真正的 Postgres，Neki 增加路由、边车和控制平面，让系统突破单机限制，扩展到每秒数亿次查询和 PB 级数据，且无需停机。
应用连接到 Neki 路由器，再由路由器将查询分发到 Postgres 分片。第四个分片正在在线拆分。
随着负载增长，可以拆分热点分片：Neki 创建新目标分片，通过复制追平数据，并在拓扑变更中迁移流量。也能在数据库在线时迁移到新分片布局，重新平衡容量而无需改写应用或停服。
05 让平台跟踪健康状态、提升副本并更新路由，应用始终使用同一 Postgres 端点。
06 跨分片以协调工作流执行 schema 变更，Neki 按分片采用合适方法并跟踪切换进度。
07 在分片数据库层内部池化连接，Neki 路由时感知拓扑、分片健康和会话状态。
08 将不同表或工作负载分配给不同分片组，让热、冷或隔离数据在所需硬件配置上扩展。
09 每个分片作为跨可用区的高可用 Postgres 集群运行，故障隔离在最小单元。
10 明确定义数据到分片、分片组和分片索引的映射，放置方式显式、可审查，为可控重分片而设计。
11 跨分片在单一事务中写入，Neki 协调提交以保证原子性：要么全部分片应用变更，要么都不应用。
12 使用显式工作流处理导入、重分片、schema 变更、切换和清理，让分布式 Postgres 操作可重复。
13 通过同样的在线迁移模型升级到新 Postgres 版本：创建目标分片组、复制、切换，然后退役旧组。
14 在源数据库持续提供服务时导入 Neki，复制并验证，就绪后切换。
15 每个 Neki 分片拥有独立的 WAL 和逻辑复制路径，CDC 兼容标准 Postgres 模式及每分片流。
从单分片起步，随业务增长拆分。可通过零停机导入迁移现有数据库，或与团队沟通你的工作负载。
评论
社区对分片 Postgres 新工具普遍表示欢迎，但疑问集中在跨分片约束缺失、一致性模型妥协以及对抗大型云厂商的难度上。
认为分片 Postgres 新产品值得欢迎但落地不易
- 市场出现分片 Postgres 令人兴奋，但团队在生产中运维分片设置难度大，且独立工具对抗超大规模云厂商胜算低。（较多人） > 宣传很吸引人，但怀疑有多少团队能因此真正运维起分片数据库。（@vaibhav2614）
怀疑跨分片外键等约束未实现导致技术落后
- 页面未提及跨分片外键或约束，若确实缺失，其实用性仅相当于十年前的 Spanner 水平。（少数人） > 如果跨分片约束没实现，那虽有价值但只赶上十年前的 Spanner。（@ragall）
担心 PlanetScale 分散精力影响原有 Vitess 发展
- 重度 Vitess/MySQL 用户乐见新品，但忧虑公司资源分流，希望 Vitess 侧持续改良。（少数人） > 作为 Vitess 重度用户，怕 PlanetScale 精力分散，不过仍恭喜发布。（@erulabs）
质疑一致性模型能否满足严苛负载需求
- 分布式 Postgres 常因最终一致性不被多数负载接受，好奇该产品如何依据 CAP 做妥协，以及是否支持查询级写后读一致性。（较多人） > 开发团队最大担忧是最终一致性不适合许多负载，不知这款产品怎么解决。（@Atreiden）
好奇与现有方案 Citus 对比及开源状态
- 用户自然将其与 Citus 比较，并询问是否开源。（少数人）
赞赏产品页面的品牌设计
- 有用户单纯表达对落地页视觉品牌的喜爱。（少数人）
调侃行星级规模只是“新手数字”
- 有评论讽刺所谓行星级规模远远不够，戏谑期待跨宇宙级方案，反映社区对规模宣称的调侃情绪。（少数人） > 只是行星级？菜鸟数字，我在找跨维度跨宇宙级。（@xyst）