PlanetScale 发布的 Neki 在 Hacker News 获得 247 points 和 132 条评论。它把 Postgres 分布到多台机器，每个分片仍是完整的 Postgres 集群，应用通过标准 wire protocol 连接路由器。项目目前处于 platform preview，公开说明不建议承载生产负载。
分片解决的是什么问题
单机升级可以延后容量上限，却不能无限解决表太大、索引和 vacuum 影响流量、备份时间过长、连接数受限等问题。分片把数据和查询分散到多台机器，代价是路由、跨分片查询、事务和重分布都更复杂。
Neki 把 shard key 放在数据拓扑配置中，由路由器解析查询并决定访问哪些分片。每个分片有主节点和副本，控制面负责故障切换、扩容、版本升级和 resharding。应用仍使用常见驱动和 ORM，这能降低迁移入口的变化。
“兼容 Postgres”要具体问
看它是否保留需要的扩展、SQL 语义、事务边界和执行计划行为。标准连接串只是接入层兼容，不能保证跨分片 join、唯一约束、外键和长事务与单机完全一致。
还要看热点。按用户 ID 分片可能让单用户查询很快，却把公共配置、时间范围查询或热门租户集中到一处。shard key 是数据模型决定的长期选择，不能等容量耗尽后临时补上。
评估分片方案的步骤
- 统计表大小、增长率、读写比例、热点键和跨表查询。
- 画出事务边界，标出必须原子完成的操作。
- 用真实查询样本模拟单分片、跨分片和热点场景。
- 测试备份、恢复、故障切换、schema change 和 resharding。
- 先迁移可回滚的非核心负载，保留单机回退路径。
为什么 preview 标签很重要
在线迁移和无停机升级很吸引人，平台预览期间接口和行为可能发生破坏性变化。数据库基础设施的试用应隔离数据、限制权限并设置恢复演练，不能因为应用连接串没变就把风险当成没变。
分片前还要先处理数据访问习惯。把分页、排序和统计查询按 shard key 改写，往往比换数据库更费时间。跨分片聚合可能需要预计算、异步任务或专门的分析库。若产品经常需要全局排序和跨租户报表，分片带来的收益可能抵不过查询复杂度。
迁移评审应要求一份回退计划，包括如何停止写入、如何校验行数和校验和、如何切回旧连接、如何处理迁移期间新增数据。没有这些步骤，在线迁移无法成为可执行的运维方案。
数据库分片还会改变运维习惯。监控要从单实例 CPU、磁盘和连接数，扩展到每个分片的热点、路由器排队、跨分片查询和数据倾斜。告警若只看集群平均值，某一个已经过载的分片可能被平均数掩盖。
FAQ
Postgres 一到大规模就该分片吗？不该。先确认单机纵向扩展、索引、归档和查询优化是否仍能解决瓶颈。
标准驱动能否隐藏全部复杂性？不能，跨分片查询和事务语义仍需应用和 DBA 共同设计。
预览版适合做什么？适合用脱敏数据验证查询模型和运维流程，不适合承载关键生产数据。