SpacetimeDB在2022年4月的一篇技术博客里，算了一笔账。
同一把数据锁，单机内存里加锁解锁大约耗时3微秒。放到分布式集群里，跨节点提交要花约1毫秒，差了300多倍。按这组假设推算，理论吞吐量从单机的30万TPS掉到分布式集群的1千TPS。
这篇文章真正想说明的，不是数据库能不能横向扩展，而是哪些负载适合横向扩展。协调成本什么时候会让"加机器"变成"降性能"，才是关键。这个判断对做实时多人应用、高并发交易系统的团队有用——热点数据争用在这类场景里并不少见。
把"能不能扩展"拆成三件事
文章的核心方法是拆指标：计算、存储、网络是三个相对独立的维度。一个系统在某一维度强，不代表其他维度也强。
作者拿三款兼容PostgreSQL接口的数据库做对比。Postgres基本是单机架构，横向能力只来自手动配置的读副本，且有读写一致性延迟。Neon把存储和计算分离，数据放进对象存储，本地缓存热页，存储近乎"无限扩展"，但写事务依然走单一主节点。
CockroachDB通过分片和多副本复制，理论上让计算、存储、网络三个维度都能横向扩展。这类分布式SQL数据库的架构思路，和Google Spanner、AWS Aurora DSQL接近。代价是几乎每次跨节点事务都要付协调开销。
为什么分布式数据库不必然更快
文章给出的关键推演：假设一个OLTP事务涉及用户行和关联的元数据行。
单机Postgres上，两行大概率在同一台机器，临界区约3微秒。N个节点的CockroachDB集群里，随机主键让两行落在同一节点的概率约为1/N。一旦不在同一节点，就要经历一次网络往返，提交时间拉长到约1毫秒。
热点行会把这个差距放大成量级差距：
| 场景 | 临界区耗时 | 理论吞吐上限 | 每十亿次交易成本（示例） |
|---|---|---|---|
| 单机（数据共置） | 约3微秒 | 约30万TPS | 约5美分 |
| 分布式集群（跨节点提交） | 约1毫秒 | 约1千TPS | 约417美元 |
同样十亿次交易，成本差了两个数量级以上。
这组数字来自SpacetimeDB自设的假设模型，不是第三方独立基准测试的结果。真实业务里的网络延迟、副本数量、事务大小都会改变具体数值，不能直接套用到所有部署环境。
谁该在意，接下来该做什么
水平扩展只对能并行拆解的负载有效。热点行、冲突写入、跨分片事务，都会撞上串行化瓶颈。
文章也承认，CockroachDB这类系统在无争用、高预算的场景下确实能靠加节点换来更高吞吐。但这是小众场景，不是大多数OLTP应用的常态。CockroachDB此前支持过表内嵌（table interleaving）来缓解数据不共置的问题，但在v21.2版本里因收益不足以覆盖复杂度而移除。
值得留意的是，SpacetimeDB自己提到的存储横向扩展能力，标注的交付时间是2026年10月31日，截至这篇文章发布时还没上线。评估基础设施预算的技术决策者，不该把这条能力当成已经交付的产品去做采购判断。
对设计实时多人应用或高争用事务系统的工程团队，更现实的动作是：先测自己的负载里热点行占比有多高，再决定要不要上分片架构。数据共置和事务模型的选择，比单纯数节点数量更能决定扩展效果。