在一个 YouTube 评论区，有人问：“你们怎么横向扩展？”这大概是关于时空数据库（SpacetimeDB）我最常被问到的问题。它看似简单，但扩展是个复杂话题，魔鬼往往藏在细节里；好在这件事还没复杂到不能从第一性原理讲清楚。下面先讨论扩展性的一般原理，再回答它如何扩展。

关于 Spacetime 能否水平扩展，这可能是我被问到最多的问题。这个问题看似简单，答案却藏在细节里。

扩展是一个复杂的话题，但我们可以从基本原则出发，在一篇博客中把它讲清楚。先探讨扩展的一般概念，再回答“Spacetime 是如何扩展的？”。

简单来说，扩展有三个维度：计算、存储和网络。水平扩展存储相对直接，Spacetime 计划于 2026 年 10 月 31 日推出该功能。但并非所有网络和计算都能水平扩展。那些声称具备通用水平扩展能力的 OLTP 数据库，往往每笔交易都会产生巨大的开销，且在遇到竞争事务时性能极差。Spacetime 在竞争环境下能提供高性能，并为用户提供了易于扩展可并行 OLTP 工作负载的工具。

注：文中多次提到 CockroachDB，它实际上是所有通用、水平扩展的关系型数据库（包括 Spanner 和 Aurora DSQL）的代表。虽然提到了这些技术的一些问题，但它们都是令人惊叹的工程壮举。

扩展

直觉上，每个人都对“扩展”有概念，即能够处理更多请求、跟上需求、处理海量数据或用户，让应用每年增长 10 倍或 100 倍而无需重写软件。

当人们说一个系统具备扩展性时，通常指它是否能水平扩展。垂直扩展是指用单台计算机做更多事，而水平扩展是指用更多计算机做更多事。如果计算机数量翻倍能让我们完成大约两倍的工作量，那么该计算就是水平扩展的。毕竟单台计算机的能力有限，但理论上购买计算机的数量没有上限，这个概念非常诱人。

注：“用更多计算机做更多事”的定义意味着所有水平扩展系统都必须是分布式系统，但这并不意味着分布式系统的唯一目的就是水平扩展。例如，分布式状态机复制是为了可靠性而在多台计算机上冗余执行相同计算，而非为了扩展。

“它能否水平扩展？”这个问题不够具体。更好的问法是：“它在哪些方面可以水平扩展？”因为扩展实际上有三个相对独立的维度： 1. 计算：能处理多少笔交易。 2. 存储：能存储多少数据。 3. 网络：能支持多少连接和带宽。

以几个提供 PostgreSQL 兼容接口的数据库系统为例，它们的架构截然不同：

• Postgres：基本上是一个单节点数据库，不自动水平扩展计算、存储或网络。当然可以通过部署多个实例来手动扩展，但 Postgres 本身并不感知这些实例。唯一的例外是只读副本，允许你将读请求手动导向副本，这有助于扩展网络和计算，但在读写一致性和性能上有权衡。Postgres 本身没有集群主节点的概念，无法跨节点运行事务或查询。
• Neon：Postgres 的修改版，水平扩展存储。其表由对象存储支持，并带有本地页面缓存结构。虽然缓存未命中的延迟可能较高，但这种架构让数据库拥有近乎无限的存储。然而，Neon 不自动水平扩展计算和网络，所有写事务仍必须通过单个主节点。不过作为 Postgres 变体，它也支持只读副本来水平扩展读工作负载的计算和网络。
• CockroachDB（及 Spanner）：原则上通过集群分摊表数据来水平扩展存储，每个表的一部分（称为“范围”）存储在每个机器上，通常复制到另外两台机器。如果写入者不都试图修改同一个范围，它也可以水平扩展网络。它具有对称架构，集群中的任何节点都可以服务任何 SQL 请求。对于能清晰并行化的计算（如分析或对无关键的写入），它也能水平扩展。你连接的节点会计算查询计划并返回结果，但读写操作都会作为分布式事务在集群中基于范围执行。

我们能找到圣杯吗？

既然 CockroachDB 能在三个维度上扩展，那它肯定在所有方面都优于 Postgres 和 Neon，对吧？也许它在 CAP 定理或原子钟方面有什么特别之处？

遗憾的是，这里没有魔法。虽然 CockroachDB 是现代奇迹，确实能水平扩展某些计算，但并非所有计算都能水平扩展。水平扩展本质上是一个并行计算问题：我们能否将计算拆分成不同计算机可以同时执行的部分？答案往往是否定的。问题在于，即使数据竞争迫使你必须依次更新，CockroachDB 仍需支付水平扩展带来的巨大协调成本。它在水平扩展上获得的收益，在垂直扩展上损失殆尽，甚至更多。

一个残酷的事实是，水平扩展往往意味着用更多计算机做更少的事：单台计算机 1 毫秒能完成的事，10 台计算机可能需要 100 毫秒。

CockroachDB 水平扩展方法有两个主要问题： 1. 每笔交易涉及的数据很少位于同一台机器上。 2. 没有事务能独占一个范围，因此每笔事务都要支付分布式并发控制的开销，冲突的事务必须等待、中止或重试。

第一个问题是由数据在集群中平均分布造成的。如果数据分散在各处，几乎每笔交易都需要网络请求。分片虽然听起来麻烦，但如果大多数交易都在单个分片内操作，性能会好得多。Neon 的设计在许多工作负载下没有这个问题，因为它在本地机器上缓存了热页面。

注：Spanner 通过“表交错”部分解决了这个问题，允许你告诉 Spanner 将相关表放在一起。CockroachDB 曾支持表交错多年，但在 v21.2 中移除了该功能，认为收益太小，不值得增加复杂性。

第二个问题是并行化任意计算的普遍问题：竞争下的协调。即使是普通 Postgres 也会遇到同样的问题，只是规模更小。Postgres 可以在多个 CPU 核心上运行事务，但一旦这些事务触及相同数据，就需要花时间协调。CPU 本身必须协调 L1、L2 和 L3 缓存之间的原始内存访问。另一个修改同一缓存行的写入者会使你的本地副本失效，迫使核心同步。Postgres 必须协调事务本身：谁拥有锁、哪些行版本可见、事务提交的顺序，以及冲突的工作是否需要等待、中止或重试。

例如，假设一个涉及用户行和相关元数据行的小型 OLTP 事务。在单节点 Postgres 中，这两行都在同一台机器上，关键部分大约只需 3 微秒。而在拥有 N 个节点和随机主键的 CockroachDB 集群中，它们位于同一租约持有者/领导者上的概率约为 1/N。原本 3 微秒的关键部分现在变成了 1 毫秒的分布式关键部分，且包含多次网络请求。即使在这 1/N 的概率下，事务在写入被复制到法定人数之前仍无法释放锁，因此锁定时间大致相同。更重要的是，另一笔想读取或修改相同行的事务现在必须等待 1 毫秒让我们的事务提交或中止。这两个问题成倍叠加。一个热键在 3 微秒关键部分下每秒可处理约 30 万笔竞争事务；而在 1 毫秒下，每秒只能处理约 1000 笔事务。反直觉的是，在这种场景下，单线程解决方案的“扩展性”是集群的 300 倍！

在 100% 竞争和 1.0 毫秒提交延迟下，热行将每个集群的吞吐量限制在 1000 TPS。无论增加多少核心，都无法击败单核心。成本方面，单核心每月 36.50 美元，每 10 亿笔交易成本 0.05 美元；而集群每月 1095 美元，每 10 亿笔交易成本 417 美元，单笔交易成本是单核心的 9000 倍。

注：即使只有 1% 的事务竞争单个行，在 1 毫秒分布式提交延迟下，任何水平可扩展集群都会比单核心慢。这就是阿姆达尔定律应用于水平扩展的结果。竞争事务必须串行执行，总吞吐量永远不能超过串行速率除以串行事务的比例。只有一种场景集群吞吐量能超过单核心：完全没有竞争且每月花费超过 3600 美元。这是一些公司会遇到的情况，但属于小众场景。

在竞争下，多个写入者会使事务比依次执行慢得多，因为核心花在商定谁可以修改共享状态上的时间，比做有用工作的时间还多。

但即便是对于可以并行执行的计算，人们也常常严重低估仅仅为了克服协调开销就需要多少额外的硬件。粗略来说，L1 缓存延迟比 L3 低约 20 倍。如果并行化工作负载将廉价的本地缓存访问变成了频繁的同步和跨核心通信，那么很可能你需要 10 个以上的核心才能匹配一个经过精心缓存优化的核心的性能。这甚至还没算上更大的工作集和元数据（如 MVCC 簿记）将有用数据推出缓存后，访问主内存的更高成本。更不用说分布式 MVCC 簿记所需的网络请求和序列化，以及它们导致的缓存未命中。你确定要花 10 个核心的钱，而 1 个核心就能搞定吗？也许对于某些问题，我们最终实现了扩展，但代价是什么？

对于本质上串行计算的任务，你可以把它移到更快的机器上、优化代码或复制结果以实现容错，但无论你多么想，都无法让十台机器做得更快。每个读过《人月神话》的程序员都直观地知道这一点。给项目增加程序员并不意味着写软件更快，而是意味着写得更慢，但会议更多。10 个作者不能比 1 个作者更快地写出小说，尤其是如果他们通过蜗牛邮件协调的话。

这个故事的寓意是，水平扩展性不仅仅是一个系统有或没有的属性。它首先是工作负载的属性。

Spacetime

Spacetime 最初是我们实时 MMORPG《BitCraft Online》的后端，因此从一开始就有极高的事务延迟和吞吐量要求。我们不能为了让罕见的情况能跨任意数量的机器，就让常见情况变得极其昂贵。这些要求迫使我们从头开始构建自己的定制存储和执行引擎。

也许令人惊讶的是，如今 Spacetime 数据库的执行模型是设计为单线程的。直觉上，尤其是对于那些缓存性能优化经验有限的工程师来说，这听起来像是坏消息。最初我们也这么认为：我们定制数据库引擎的早期版本使用由 MVCC 事务启用的并行执行。但问题在于，当我们实际测量时，发现单线程执行彻底击败了并行执行。从某种意义上说，仅仅为了弄清楚我们应该使用一个大的锁，我们就花费了超过 100 万美元。未来并非不可能在单个数据库内实现并行执行，并在有限的情况下获得更好的性能，但这需要极其谨慎的工程和性能测量，以确保不会引入比其价值更多的复杂性和开销。

这是否意味着 Spacetime 无法水平扩展？远非如此。

水平扩展 Spacetime

Spacetime 水平扩展方案的基础受演员模型启发。该模型旨在实现由数十、数百甚至数千个独立单处理器组成的高并行计算机器。

如今在 Spacetime 中，每个数据库都是一个单线程的演员，我们有一个六步策略，让水平扩展成为对开发者越来越友好的体验。

下一阶段已确定日期：异步数据库间通信和分层存储将于 2026 年 10 月 31 日 作为可扩展性发布的一部分推出：Spacetime Continuum。

| 步骤 | 功能 | 状态 | | :--- | :--- | :--- | | 1 | 提供具备世界级性能的复制数据库 | 已上线 | | 2 | 提供世界级的分片体验（异步 IDC） | 2026 年 10 月 31 日 | | 3 | 水平扩展每个数据库的存储（分层存储） | 2026 年 10 月 31 日 | | 4 | 水平扩展每个数据库的网络（只读副本） | 计划中 | | 5 | 实现数据库间事务（同步 IDC） | 计划中 | | 6 | 实现数据库内分区 | 计划中 |

在深入细节之前，值得区分两个版本的 Spacetime： * SpacetimeDB Standalone：GitHub 上提供的单节点版本。 * SpacetimeDB Cloud：专有的、集群化的版本。

具备世界级性能的复制数据库

我们已经详细讨论过每个 Spacetime 数据库如何实现世界级单线程性能，但值得注意的是，SpacetimeDB Cloud 也支持数据库的分布式状态机复制。

这意味着尽管每个数据库是单线程的，但它不一定只在单台机器上运行。这听起来违反直觉，但大致思路是，我们可以将单线程正在做的事情复制到多台机器上，这样即使机器故障，数据库也能保持可用。这意味着 SpacetimeDB Cloud 中的每个数据库都作为一个分布式系统运行。

重要的是，通过我们的流水线实现，我们在基准测试中证明，复制数据库能达到与未复制数据库相同的吞吐量（基准交易约为 30 万 TPS），前提是节点间有足够的网络带宽和管道深度的内存。

注：默认设置 confirmedReads(true) 配置客户端仅在事务达到集群上的持久状态后才读取。

世界级的分片体验

分片你的数据库能让操作仅限于单个分片内的交易获得最佳性能。分布式事务让你能运行跨分片的事务。为什么不能两全其美？如果大多数交易都在单台机器内操作，且我们给程序员工具来组织数据，使大多数交易发生在该机器内，会怎样？只有在极少数情况下我们才需要进行分布式事务。

关键在于让分片边界明确且易用。在演员模型中，每个分片可以像独立的演员一样调度：分片内的事务保持快速、本地化和单线程化，只有真正需要触及多个分片的事务才支付协调成本。这让架构在保留 Spacetime 今日速度特性的同时，不假装分布式协调是免费的。

每个数据库都是一个拥有自己状态和事务日志的独立演员，因此针对不同数据库的交易可以在无协调的情况下并发执行。

Spacetime 已经提供了管理这种架构的工具。数据库可以作为其他数据库的子项创建。过程可以发布数据库并调用其上的函数。根数据库可以跟踪其下数据库的身份和状态。

我们的几个客户以这种方式运行着数百或数千个数据库，BitCraft 也是如此扩展的。单个根数据库维护全局数据，而区域数据库处理世界的不同部分和不同的玩家组。一个区域内的交易保持快速和本地化，而区域本身则并行执行。

我们计划通过一流的数据库间通信（IDC）让这个模型变得更容易。异步 IDC 将允许一个数据库以类型安全的方式调用另一个数据库上的函数。

从高层次来看，TypeScript API 大致如下： typescript // 异步 IDC：向另一个数据库发送类型安全的消息。 // 这将导致目标数据库上恰好一次 reducer 调用。 ctx.db.receivePlayer.insert({ msgId: 0n, target: regionDb, player, });

水平扩展每个数据库的存储

截至今天，Spacetime 将所有表数据存储在领导者节点的内存中。这意味着单个数据库中能放入表的数据量受限于机器的物理内存。

然而，这一限制并非 Spacetime 或其惊人性能的根本原因。我们将内存、磁盘和对象存储视为 CPU 缓存模型的自然延伸。从精神上讲，我们将内存视为 L4 缓存，磁盘视为 L5 缓存，对象存储视为 L6 缓存。这种缓存模型是从单个写入者获得最大性能的传统方法，通常被称为“分层存储”。

缓存行和预取允许你主动从更便宜、更慢的存储中批量拉入数据到更昂贵、更快的存储中。为数据库提供分层存储可以分摊缓存未命中的成本，实现整体接近更快、更昂贵存储的性能，同时保留更大、更便宜存储的可扩展性。

页面调度不会阻塞单线程吗？

如果每笔交易都在一个线程上执行，那么对对象存储的单个缓存未命中似乎会让整个数据库停滞 50 毫秒。这就像经营一家图书馆，只要顾客预订一本书，你就让整队顾客站在那里等两周书到货再处理下一位顾客。显然很傻。让分层存储与单线程执行兼容的规则很简单：不要在持有锁的时候等待缓存未命中。异步订购书籍，并在等待时处理下一位顾客！

幸运的是，这是一个经过充分研究的问题。H-Store 称该技术为反缓存：正常执行事务，一旦触及不驻留的数据，就中止它，异步获取数据，并在等待时运行其他事务。当数据到达时，重新运行事务。中止几乎是免费的，因为没有任何提交，每次重新执行只需微秒级的 CPU 时间，避免了毫秒级的 I/O 串行化。Calvin 使用了类似的技术，称为侦察查询：针对最近的快照“试运行”事务以发现它读取的内容，预取这些内容，然后真正执行。TigerBeetle 在同步应用每批事务之前运行显式的预取阶段。

Spacetime 异常适合这些技术，因为 reducer 是确定性的。Reducer 不能执行 I/O、读取时钟或生成随机数，每次数据访问都通过 reducer 上下文进行，因此引擎能观察到事务进行的每次读取。这意味着中止没有可见影响，针对相同状态的重新执行会触及完全相同的行，试运行能发现真实运行所需的数据。

数据集 10 TB，热集 90% 读取触及 1.0%。85% 的读取永远不会离开内存；其余的则分摊到磁盘和对象存储。分层方案每月成本 1.9 万美元（含 1.7 万美元 S3 GET 费用），而全内存方案每月 5.2 万美元。分层读取延迟平均为 3.0 毫秒，p50 为 100 纳秒，p99 和 p100 为 50 毫秒。使用中止和重启技术，吞吐量可达 273,666 TPS，最多约有 831 个事务在等待故障；而理想预取下可达 294,121 TPS。

这就是 TigerBeetle 团队所称的“对角扩展”。

磁盘和对象存储表将于 2026 年 10 月 31 日发布。我们认为这是 Spacetime 可扩展性的一项关键改进。通过磁盘表，我们可以大大增加存储限制并降低数据存储价格。通过对象存储表，我们可以有效消除存储限制，允许你在单个数据库中存储理论上无限量的数据。

水平扩展每个数据库的网络

如前所述，与计算类似，水平扩展网络并非总是可行，因为在某些情况下，写入者希望修改相同的状态，因此需要连接到同一台计算机并向其发送数据。这就是为什么 CockroachDB 建议使用随机键以避免集群中的热点。然而，即使在这种情况下，我们也应努力支持最大可能的读取器和写入器吞吐量。

与 CockroachDB 类似，SpacetimeDB Cloud 也具有对称架构，这意味着你可以连接到任何节点，SpacetimeDB Cloud 将确保你的写请求被处理或代理到正确的地方。从外部看，它有点像一个巨大的计算机。对于写入者，这允许我们“扇入”连接。客户端连接到任何节点，该节点会将这些连接多路复用到通往托管数据库的节点的单个连接上。

原则上，我们还可以通过引入一致的只读副本来将 SQL 订阅和读查询的处理从领导者移开。一致的只读副本允许我们从领导者那里“扇出”。订阅评估可以被路由到一致的只读副本，而不是直接连接到领导者。这样，我们可以水平扩展读取器连接和带宽。

“一致”意味着副本按照相同的总顺序应用领导者的事务日志，因此订阅看到完全相同的更新序列，只是有延迟。对于点时间 SQL 查询，领导者将为每个查询分配事务日志中的一个位置而不执行它，副本在应用到该偏移量之前不会回答查询。因此，读取相对于每次写入都是线性一致的，领导者的唯一成本是分发序列号。

数据库间事务

同步 IDC 提供了执行真正的分布式事务（CockroachDB 提供的那种）所需的内置两阶段提交机制。这将允许事务在需要真正原子性的情况下跨越集群中的多个数据库。

其 TypeScript API 看起来就像调用普通的 reducer，只是在外部数据库上。 typescript // 同步 IDC：在当前事务内调用另一个数据库。 ctx.at(regionDb).reducers.receivePlayer(player);

这里存在明显的张力。如果每个数据库都是一把大锁背后的单线程，那么从数据库 A 到数据库 B 的同步调用会持有 B 的锁，直到 A 的事务提交或中止，这需要一次网络往返。我们的计划是保持执行单线程，但为这些分布式事务重新引入 MVCC，以便在往返过程中允许并发事务继续进行。

我们设计了一个流水线化的两阶段提交协议，该协议首先在内存中提交事务，并且从不在磁盘 I/O 期间持有数据库锁，并且我们已经在 TLA+ 中对其安全属性进行了建模检查。细节值得单独写一篇文章。

这些功能加在一起，将使多个数据库变成一个连贯的分布式应用，而无需将分布式协调置于每笔交易的路径上。大部分工作将保持本地和异步。只有真正需要跨数据库原子性的操作才需要支付分布式事务的成本。

数据库内分区

多个数据库是一个自然的扩展边界，但它们也要求你管理多个模块、独立更新其模式，并弄清楚如何在负载变化时重新平衡。解决这些用户体验问题的下一步是在单个逻辑数据库内引入分区。

分区将允许一个数据库模块包含多个独立执行的分片。这保留了一个部署工件，并允许模式更改原子地应用于整个数据库，而针对不同分区的事务则并发执行。

Spacetime 中的分区与 CockroachDB 中的范围不同。范围是一个放置决策：它说明哪台机器存储表的某个切片，但任何事务仍然可以触及任何范围，并且无论落在哪里，每次写入都会以相同方式进行复制和协调。Spacetime 分区是一个执行单元。它拥有自己的数据，有自己的串行事务日志，操作该数据的 reducer 代码在其中运行。开发者选择分区边界以匹配其工作负载的结构，这样常见的事务永远不会离开其分区，Spacetime 可以在不削弱该保证的情况下在机器之间移动整个分区。

一笔从不离开其分区的事务，不会因其他分区的存在而付出任何代价。这就是零开销原则：除非你使用它，否则不应为水平扩展性付出代价。

那么，它能扩展吗？

是的，它能。如今，你可以通过跨数据库分片来扩展并行工作负载，同时保持每个分片快速且本地化。正如我们所见，如果你的工作负载几乎存在任何竞争，或者你宁愿不为获得单核心性能而支付大型集群的费用，这种架构就是最好的选择。

随着时间的推移，分层存储、数据库间通信、分布式事务和分区将使这种架构变得越来越透明。目标不是让协调免费，而是确保只有当你的工作负载真正需要时，你才需要为此付费。

围绕这篇文章的评论，像是几群人在各说各话：数据库基础设施圈的人认为拿 SpacetimeDB 对比 CockroachDB 之类分布式 OLTP 并不公平，因为前者把应用服务器、数据库塞进同一进程后测出的“快”，其实绕开了分布式最难的部分；而在侧项目、游戏场景里实际试用过的人则真心觉得“逻辑入数据库”的体验好、单机性能也够用——反正他们的用户量根本没到需要分片的程度。还有一小撮人拿“它能扩展吗？”这个让无数 demo 冷场的问题玩梗，反问这类系统过早背上扩展包袱是否合理。

认为拿 SpacetimeDB 对比 CockroachDB，是把两个不同的问题混为一谈

• 有在 Cockroach Labs 工作过的评论者指出，分布式数据库是用吞吐换跨节点的一致性、持久性和故障可用性，而 SpacetimeDB 没有展示如何在节点故障时保证零数据丢失；它解决的可能是另一个问题（较多人认可）。 > 分布式数据库放弃一些吞吐，是为了在节点甚至机房挂掉时仍然保持一致的可用状态；我没看到 SpacetimeDB 如何不付这笔代价就做到同样的事。（@timssopomo）
• 另有观点点出分布式 SQL 没真正占领市场的原因：自增列/序列、二级唯一索引、外键，以及 DISTINCT、LIMIT/TOP-N、非同位连接这类 SQL 特性，本质上都很难水平拆开。如果 SpacetimeDB 不走标准 SQL 路线，等于换了一条不需要回答这些难题的赛道。
• 一位用过 Vitess 的人以自己的痛苦经历提醒：选分布式数据库前要想清楚领域是否真的无法拆分，否则每个表、每个 shard key 都要防 join、防广播查询，反而把精力耗在建表设计上（较多人认可）。 > 分布式数据库在技术上确实更强，但不代表在你的业务场景里就更强；不如先花时间切开领域边界，让数据库保持简单。（@whsoul）

认为“把服务器并进数据库”之后测出的快，是一种修正过的比赛

• 有评论者仔细读了 benchmark 方法后不满：官方承认最主要的速度来源是把应用服务器、ORM、数据库合到一个进程，减少 99.95% 的往返延迟；但同进程的 SQLite 却没有被列入对照结果，等于回避了最可能拆穿宣传的对手。 > 对速度的主要解释是消除数据库和应用服务器之间的往返；可 SQLite 同样在进程内运行，他们却不愿意把这组数据放进 benchmark 里。（@Rohansi）
• 该评论者还质疑营销场景错位：实时多人游戏本来就没有人用 Web API 做网络层，拿这类 benchmark 去说服游戏后端开发者没有意义。他们自己用 SpacetimeDB 做的 MMO，Steam 在线峰值不到 5000 人，这点量单机就能舒服跑起来。
• 另有人从授权条款里读出讽刺：开源版本的生产环境只允许部署一个 SpacetimeDB 实例，也不许拿它做数据库服务。对一个号称解决扩展问题的 OSS 产品来说，这等于自己先放弃了规模化的可能（@themgt）。

觉得这套“业务逻辑长在数据库里”的思路确实有吸引力

• 一位数据库学习者说，读完开头拿分布式事务数据库和分布式数仓作对比的引子，一下子被勾起兴趣；最让他兴奋的是以 Actor/Reducer 组织并发写进数据库的做法。 > 通信顺序进程这套设计 1984 年就发表了，到今天仍是解释并发的好工具；把服务器逻辑拆进子库、表和 reducer 里，从开发者视角看非常直观。（@gandreani）
• 也有已经拿 SpacetimeDB 做真实 side project 的人给出好评，说速度令人印象深刻，并希望团队尽快补上运维侧的欠账：可快速恢复的备份、灾难恢复流程、面向分析负载的读副本、以及把持久化写到 S3 这类能力（@echohack5）。这说明它的短板不在即时性能，而在“出了事怎么回来”。

用“它能扩展吗？”嘲笑早期项目的人很多，但真创过业的人有不同感受

• 一位工程师形容：总有个同事在每次 demo 时抛出“它能扩展吗？”，像往自行车辐条里扔标枪；而当时大家只盼着有几十个用户。类似的评论还有“我们为 100 个用户跑在 16xlarge 实例上”的自嘲。
• 但也有人承认，自己曾把这当成商学院式的装聪明问题，直到真的创业才意识到它并不傻；只是当默认路径是 VC 融资时，这个问题本身变成了循环论证——既然拿了钱就必须讲增长故事，扩展性当然得提前回答（@chermi）。

有价值的补充

• 评论附带了一个少见的一线观察：在处理过大量 CockroachDB 事故后，几乎没见过真正被网络拖垮的集群；更常见的代价是吞吐换一致性，瓶颈并不在网络本身。
• 有评论者晒出自己做过的公开基准测试：单节点 PostgreSQL 对多节点 CockroachDB，结果和这篇文章描述的“分布式系统被网络开销拖累”一致，可复现。
• 有人留意到产品叙事在漂移：SpacetimeDB 最早是游戏后端，后来转向 AI Agent 场景，让人怀疑下一步是不是要做成 IaaS；定位反复反而削弱了技术讨论的可信度。