数据库厂商晒跑分往往像车厂在无风盐湖测极速，数字越夸张，路况往往越真空。
PlanetScale 公布了面向原生 PostgreSQL 的分片路由层 Neki 的测试成绩。在 512 个分片和 480 个 Neki 路由器的协同下，集群管理着 1.22 PiB 数据，连续 16 分钟稳住了每秒 118,538,803 次查询，峰值甚至摸到 118,747,267 QPS。单分片 QPS 达到 231,521，集群总网络吞吐突破 2 Tb/s。
这组数字在技术社区掀起巨大波澜，甚至有人误以为 Postgres 内核发生了某种基因突变。事实并非如此，这更像一场把路由水平扩展推向物理极值的工业演练。
算力账本里的 1.18 亿查询
离开硬件规格谈吞吐，通常都会变成数字游戏。把 Neki 这套压测集群的底层账本拆开，才能看清这份战绩背后的物理代价。
集群由 512 个数据库主节点组成，清一色采用 AWS r8g.16xlarge 规格。单台机器挂载 64 颗 vCPU、512 GiB 内存、30 Gbps 网络带宽和 20 Gbps EBS 带宽。这意味着仅数据库底层，就一次性消耗了 32,768 个 vCPU 与 256 TiB 内存。按此折算，平均每个主库 vCPU 支撑的吞吐大约在 3,617 QPS，符合单台高配数据库处理简单查询时的正常物理表现。
格外扎眼的是路由层的配比。官方为这套分片系统布置了 480 个独立的 8xlarge 路由器实例，平均每台路由器分摊约 247,000 QPS。路由器与数据分片节点的数量比几乎达到了不可思议的 1:1。
有趣的是细节披露上的细微割裂：官方正文明确记录为 512 分片配 480 路由器，仪表盘截图的注释文字里却标着 513 分片和 483 路由器。抛开这些工程微瑕不谈，整个架构的核心逻辑非常直白，就是用近乎等量的计算节点专职负责线缆协议解析与流量转发，硬生生撑开了这道千兆级网络入口。
极速背后的三层温室变量
任何基准测试都要看它避开了什么。这次压测能拉出如此平直的线性曲线，是因为所有变量都被锁死在理想区间。
首先是数据分布的温室效应。集群存储了 1.22 PiB 数据，单分片负担 2.44 TiB，总数据量约为内存池（256 TiB）的 4.88 倍。看似突破了纯内存缓存的限制，但仪表盘泄露了底牌：高达 87.3% 的查询直接由内存命中。落到磁盘的 12.7% 产生了每秒约 15.1M 次读取，与实测的 15.8M 磁盘读 IOPS 吻合。这说明查询热点高度倾斜，绝非全集无规则的随机冷读。
其次是极度真空的工作负载。测试清一色采用了单分片主键点查（Point SELECT），只取单行数据。没有跨分片事务，没有 JOIN 关联，没有范围扫描，更没有写入锁竞争和 WAL 日志同步。生产环境最致命的故障转移（Failover）和多副本复制在测试中通通缺席，主库处于无任何备份的孤狼状态。
跨分片查询的扇出效应是分布式系统的尾延迟杀手，而单行点查恰好避开了所有泥坑。
延迟表现同样说明了问题。路由器层的 p99 延迟为 6.06ms，到了客户端端到端却放大到了 13.95ms，差距达 2.3 倍。在每秒 1.18 亿次的基数下，处于尾部 1% 的相对慢请求每秒就高达 119 万次。同时系统每秒产生约 67 个错误，16 分钟累计丢下 64,320 次失败，官方并未阐明这些错误来自丢包、连接池耗尽还是压测机瓶颈。
透明分片还是重写内核
PlanetScale 最早凭 Vitess 在 MySQL 生态上一战成名，曾跑出过 40 分片百万 QPS 的成绩。部分开发者在讨论中甚至把这次测试当成了老方案的续作。实际上 Neki 代表了一条完全不同的路线。面对开发者生态倒向 PostgreSQL 的大潮，PlanetScale 放弃了底层的自研存储，选择保留原生 Postgres 实例，仅在协议层截获并调度流量。
与 CockroachDB、YugabyteDB 那类彻底重写底层存储引擎与共识算法的分布式 SQL 阵营相比，Neki 的优势在于原汁原味：完全兼容 Postgres 插件、语法与生态工具，不会破坏单机单分片的执行语义。
这种兼容性并非毫无代价。480 台独立 8xlarge 实例构成的庞大中转层，直接暴露了协议解析和连接池代理的沉重负担。
- 提醒.如果你的业务缺乏明确的分片键，或者充斥着大量跨节点事务与复杂报表查询，Neki 的无瓶颈神话会在第一时间破灭，等待系统的将是不可控的散弹查询放大与尾延迟激增。
工欲善其事，必先利其器。PlanetScale 确实向外界证明了一件事：在分片键明确且读写解耦的理想假定下，这套路由器哪怕推到 500 个节点也不会成为吞吐的绊脚石。
但架构师该关心的从来不是跑车能开多快，而是这辆车拉进泥泞工地时每公里的油耗是多少。在真实的线上攻防战里，能决定系统生死的不是 1.18 亿只读点查，而是当复杂写入伴随网络抖动倾泻而下时，这套昂贵的分片体系究竟会吞噬多少硬件预算与延迟耐心。