区域数据库与全球数据库有什么区别？

区域数据库提供一个可写主节点、副本、可用区故障转移、备份和时间点恢复。全球数据库还尝试在整区域故障中存活、降低跨洲延迟、执行数据驻留并保持事务正确性，有时会接受来自多个区域的同时写入。

我是否总是需要双活多区域写入？

不。许多 SaaS 产品只需要一个可写主节点加上全球只读副本，PlanetScale Vitess 模式就能很好地满足。只有强全局一致性和多区域写入是真实业务需求时，才值得使用双活分布式 SQL。

Node.js 代码应如何处理分布式 SQL 事务重试？

将事务包装在重试循环中，只对可重试失败重新执行；将支付、邮件等非幂等副作用放在可重试事务之外；并使用幂等键和事务性发件箱模式。

我应该先选择哪个平台？

在选择厂商之前先确定一致性模型。AWS 原生双活无服务器 SQL 优先选 Aurora DSQL；成熟的关键任务全局一致性选 Spanner；PostgreSQL 兼容的可串行化 SQL 选 Cockroach Continuum；需要显式拓扑控制选 YugabyteDB Aeon；全球读取足够时选 PlanetScale Vitess。

2026 年 Node.js SaaS 应用最佳多区域 SQL 与全球数据库平台

一个多区域 Node.js 应用画起来很容易：

US users -> US API
EU users -> EU API
APAC users -> APAC API

下面这条线才是难点：

all regions -> one correct database

区域数据库可以提供一个可写主节点、副本、可用区故障转移、备份和时间点恢复。全球数据库则试图解决一组更难同时满足的问题：在整区域故障中存活、降低跨洲延迟、执行数据驻留、保持事务正确性，有时还要接受来自多个应用区域的同时写入。

这些目标彼此冲突。一旦写入必须在多个地理区域之间持久化协调，网络物理规律就会成为事务延迟预算的一部分。因此，强全局一致性不是免费的复选框；它是一种延迟和成本策略。

对 2026 年的 Node.js SaaS 团队来说，最强候选是 Amazon Aurora DSQL、Google Cloud Spanner、Cockroach Continuum / CockroachDB、YugabyteDB Aeon 和 PlanetScale。

快速建议

Amazon Aurora DSQL 是 AWS 原生无服务器分布式 SQL 中最强的新选择，具备双活多区域可用性。在美国东部（弗吉尼亚北部），当前定价为每百万 DPU 8 美元，外加每 GB 月 0.33 美元的存储费用；每月前 100,000 DPU 和 1 GB 月免费。AWS 于 2026 年 7 月扩展了多区域支持，并在 2026 年内新增了 CDC 正式可用、数据库洞察和外键支持。
Google Cloud Spanner 对于任务关键型全球一致性工作负载，仍是最成熟的选项。多区域和双区域配置需要 Enterprise Plus。当前 asia1 多区域示例按需为每小时每节点 3.705 美元，承诺使用价格更低，此外还有存储、复制和网络费用。
Cockroach Continuum / CockroachDB 对于希望获得强多区域语义和云托管运维的团队，是最强的 PostgreSQL 兼容分布式 SQL 选项。Cockroach Continuum 于 2026 年 9 月 15 日发布。新的云组织使用新定价模型。
YugabyteDB Aeon 在 PostgreSQL 兼容性、显式拓扑和多云部署很重要时表现强劲。当前 Standard 从每 vCPU 每月 125 美元起，Professional 为每 vCPU 每月 167 美元，存储为每 GB 月 0.10 美元。
PlanetScale Vitess 是最重要的提醒：许多 SaaS 产品并不需要双活写入。一个可写主节点加上全球只读区域，就能以低得多的复杂度带来大部分用户可感知的收益。

“多区域”到底意味着什么

这个说法背后至少藏着四种不同的架构。

灾备多区域在 A 区域保留主节点，在 B 区域保留复制备用节点。正常情况下只有 A 提供服务写入。这仍然可以提供出色的韧性，而不会带来分布式写入延迟。
区域写入 + 全局读取保留一个可写主节点，但把读副本放到离用户更近的地方。这就是 PlanetScale Vitess 的模式，对于写入只占少数的 SaaS 应用通常已经足够。
同步分布式 SQL在多个区域之间协调副本，可以在区域丢失后继续运行，同时保持强事务正确性。Spanner、CockroachDB、YugabyteDB 和 Aurora DSQL 都属于这一类，尽管它们的协议和放置模型不同。
租户主区域避免为大多数客户事务做全球共识。每个租户被分配到一个区域数据库，小型全球控制平面保存租户路由、套餐和部署元数据。对于数据驻留和可预测延迟来说，这通常是最简单的 B2B SaaS 架构。

2026 年对比

平台	最适合	当前定价信号	全球模型
Aurora DSQL	AWS 原生无服务器全球 SQL	弗吉尼亚北部每百万 DPU 8 美元 + 每 GB 月 0.33 美元	多区域双活、强一致性
Cloud Spanner	成熟的任务关键型全球事务	asia1 Enterprise Plus 按需每小时每节点 3.705 美元	原生多区域分布式 SQL
Cockroach Continuum	PostgreSQL 兼容分布式 SQL	Standard 示例每 vCPU 小时 0.092 美元；Mission Critical 为 0.162 美元	单/多区域，可串行化事务
YugabyteDB Aeon	PostgreSQL 兼容拓扑控制	Standard 每 vCPU 每月 125 美元；Professional 167 美元	同步 3–7 区域复制
PlanetScale Vitess	全球读取延迟，写入更简单	区域特定只读副本定价	一个可写主节点 + 全球读副本

Amazon Aurora DSQL

Aurora DSQL 与传统 Aurora PostgreSQL 有根本区别。它是一种无服务器分布式 SQL 服务，围绕分布式事务、多区域强一致性和双活可用性构建。

AWS 以 分布式处理单元（DPU） 对 DSQL 计费。DPU 覆盖查询计算、读取、写入以及多区域复制写入工作。在弗吉尼亚北部，当前价格为每百万 DPU 8 美元，存储为每 GB 月 0.33 美元。多区域持久性因此会直接出现在使用账单中，因为复制写入需要额外的数据库工作。

2026 年 7 月 31 日，AWS 将多区域集群扩展到斯德哥尔摩、西班牙、孟买和新加坡。AWS 将多区域集群描述为一个单一逻辑数据库，在两个对等区域中提供可写端点，即使一个区域不可用也仍然可用。

CDC 于 2026 年 7 月 8 日正式可用，可以将插入、更新和删除流式传输到 Kinesis Data Streams，而无需运行单独的逻辑解码基础设施。这为 Node.js SaaS 团队提供了一条从事务数据库进入 Lambda、OpenSearch、S3、Redshift 和事件驱动服务的清晰路径。

2026 年 8 月，AWS 还新增了 CloudWatch 数据库洞察和外键约束。这些变化很重要，因为 DSQL 仍然是一个相对年轻的 PostgreSQL 兼容系统；兼容性正在快速改善，但团队应该测试自己依赖的确切 schema、ORM、扩展和迁移工具。

Google Cloud Spanner

Spanner 仍然是全球分布式关系数据库的基准。其核心价值在于水平扩展、同步复制和强/外部一致性的组合。

当前 Spanner 版本为 Standard、Enterprise 和 Enterprise Plus。双区域和多区域基础配置需要 Enterprise Plus。当前 asia1 示例列出按需每小时每节点 3.705 美元，一年承诺为 2.964 美元，三年承诺为 2.223 美元。存储、复制和网络是单独的维度。

当全球事务正确性是业务需求而不是基础设施偏好时，Spanner 最有意义：金融账本、身份/控制平面、全球库存、物流状态以及其他高价值工作负载。

对于 Node.js 团队来说，迁移面可能比迁移到 PostgreSQL 连线兼容的分布式数据库更大。请为 schema/键设计、事务模式、查询审查、客户端适配和完整集成测试预留预算。

Cockroach Continuum / CockroachDB

CockroachDB 的吸引力在于，它通过 PostgreSQL 兼容的应用模型暴露分布式 SQL，同时提供可串行化的分布式事务和多区域放置。

当前最大的变化是商业和运营层面的：Cockroach Continuum 于 2026 年 9 月 15 日发布。从该日期起创建的新云组织使用 Continuum。现有 CockroachDB Cloud 客户暂时可以继续使用当前计划。

当前 Continuum 定价页面给出 AWS us-east-1 Standard 示例为每 vCPU 小时 0.092 美元，展示的两 vCPU/100 GB 配置约为每月 203 美元。Mission Critical 显示为每 vCPU 小时 0.162 美元，展示的 12 vCPU/100 GB 示例约为每月 1,528 美元。存储、备份和数据传输另行计费，不同区域的费率也不同。

对于应用代码来说，最重要的分布式 SQL 要求是事务重试安全。可串行化事务在争用下可能被中止。Node.js 代码必须重试已知的可重试失败，同时将支付、邮件和置备等非幂等副作用保持在可重试数据库事务之外：

async function runWithRetry<T>(txn: () => Promise<T>, maxRetries = 5): Promise<T> {
  let attempt = 0;
  while (true) {
    try {
      return await txn();
    } catch (err) {
      const code = (err as { code?: string }).code;
      const retryable = code === "40001" || code === "40002"; // 序列化失败 / 可重试
      if (!retryable || ++attempt > maxRetries) throw err;
      await new Promise((r) => setTimeout(r, 50 * 2 ** attempt + Math.random() * 25));
    }
  }
}

使用业务幂等键和事务性发件箱模式，让外部副作用在重试下保持安全。

YugabyteDB Aeon

当团队需要 PostgreSQL/YSQL 兼容性以及显式拓扑控制时，YugabyteDB Aeon 特别有用。

当前公开定价从 Standard 每 vCPU 每月 125 美元起，Professional 为每 vCPU 每月 167 美元，存储为每 GB 月 0.10 美元。对于高级多区域和驻留工作负载，Professional 是更相关的基线。

Aeon 支持跨 3–7 个区域的同步复制。首选区域可以承载 tablet leader 并处理正常读写，从而减少常见事务路径上的跨区域跳转，而其他区域中的副本保留区域级韧性。当应用接受有界陈旧时，follower reads 可以提供更低延迟的本地读取。

2026 年 7 月 24 日，Aeon 新增了三区域 RF5 拓扑，使用五个区域中的五个节点，可容忍两个可用区故障。8 月 25 日，针对独立 YSQL 数据库的资源治理多租户进入 Early Access。

对于需要显式控制哪个区域是首选区域、副本位于何处以及远程读取可接受多大陈旧程度的组织来说，Yugabyte 很合适。

PlanetScale：当全球读取已经足够

PlanetScale 成熟的 Vitess 拓扑采用了一种刻意更简单的方法：一个可写主区域和可选的只读区域，用于低延迟全球读取。

副本凭据可以将读取路由到附近的副本，而插入、更新和删除仍保留在可写主节点上。这提供了一种非常容易理解的一致性模型：

writes                        -> primary
read-after-write              -> primary
latency-sensitive non-critical reads -> regional replica

当前美国示例显示 PS-10 只读区域为每月 16 美元，其他区域定价不同。额外只读区域存储根据当前计划规则单独计费。

权衡在于副本滞后。用户更改对象后，如果 UX 承诺 read-your-writes 行为，应用不应立即从可能陈旧的副本读取。对这些工作流使用主节点读取、版本/水位逻辑或临时会话粘滞。

PlanetScale 的 Neki 分片 Postgres 于 2026 年 9 月 10 日进入预览，但不应将预览功能视为满足强制生产需求的正式可用双活 Postgres 解决方案。

多区域 Node.js 架构

一种务实的全球应用流程是：

Global DNS / Anycast
        |
+-- US Node.js API
+-- EU Node.js API
+-- APAC Node.js API
        |
        v
  chosen SQL topology

每个区域 API 应该是无状态的，使用有界连接池，知道自己的应用区域，并连接到正确的数据库端点。配置应显式指定区域，而不是到处复制同一个全局 DATABASE_URL：

const region = process.env.APP_REGION ?? "us-east-1";
const dbConfig = {
  "us-east-1": process.env.DB_URL_US_EAST_1,
  "eu-west-1": process.env.DB_URL_EU_WEST_1,
  "ap-southeast-1": process.env.DB_URL_AP_SOUTHEAST_1,
} as const;

export const DATABASE_URL = dbConfig[region as keyof typeof dbConfig];

对于 B2B SaaS，可以考虑租户主区域模型：

tenant_id | home_region | database_cluster

身份认证解析租户后，请求被路由到主区域。全球控制平面数据保持很小。这通常提供更清晰的驻留、更小的爆炸半径和更低的写入延迟，而不是让每个客户事务都变成全球事务。

生产规则

**在选择厂商之前，先选择一致性。**确定哪些操作需要强一致性、有界陈旧或最终一致性。
**保持跨区域事务简短。**不要在调用支付提供商或其他外部 API 时让全球事务一直打开。
**使用幂等键。**故障转移期间，客户端可能不知道写入是否已提交。重试不能创建第二张发票、第二个订阅或第二笔付款。
**对外部副作用使用发件箱。**原子地提交业务状态和发件箱事件，然后用各自的幂等键异步执行外部工作。
**有意识地设计 read-your-writes。**全球副本可能返回旧状态。变更后使用主节点/leader 读取或新鲜度令牌。
**把数据驻留当作放置策略。**区域选择必须覆盖主数据、副本、备份、CDC 目的地和分析系统。
**使用全局唯一 ID。**UUIDv7 或其他分布式安全的身份策略，避免让顺序 ID 分配成为全局瓶颈。
**使用扩展-收缩 schema 迁移。**在分区域发布期间，旧版和新版应用可能同时针对同一个全球 schema 运行。
**在负载下测试区域故障。**模拟可用区丢失、区域丢失和网络分区。测量写入错误、重试率、陈旧读取、连接恢复和应用 RTO。
**按区域监控。**使用 app_region、tenant_home_region 和 database_region 维度跟踪事务延迟 p50/p95/p99、重试率、路由、复制/follower 滞后、跨区域字节数和数据库成本。

购买决策

如果 AWS 原生无服务器工作负载确实需要双活多区域 SQL，且其当前 PostgreSQL 兼容性足够，请选择 Aurora DSQL。

当成熟的全球一致性数据库值得进行专门的应用设计并接受企业级成本时，请选择 Spanner。

当 PostgreSQL 兼容性、可串行化分布式事务和灵活云部署是优先事项时，请选择 Cockroach Continuum。注意新的 Continuum 模式，因为定价过渡于 2026 年 9 月 15 日生效。

当显式的首选区域/follower-read 拓扑以及 PostgreSQL/YSQL 兼容性很重要，尤其是跨多个云时，请选择 YugabyteDB Aeon。

当全球读取性能才是真正需求，并且可以接受单个可写主节点时，请选择 PlanetScale Vitess。这通常正是最佳选择，因为它避免了不必要的分布式写入复杂度。

最终建议

架构原则是：

先选择一致性模型，再选择全球数据库厂商。

不要因为双活在架构图上看起来很有韧性就购买双活。

测量写入延迟。建立复制成本模型。让事务保持本地且简短。让每次写入都可以安全重试。只有在产品允许时才使用有界陈旧读取。把租户驻留与全球控制平面数据分开。在生产需要之前进行区域故障演练。

全球分布式数据库无法废除网络物理规律。

最好的全球数据库，是那个你的 Node.js SaaS 能在事故发生之前解释清楚其一致性、故障行为和成本的数据库。