Azure SQL Database是否属于分布式SQL数据库？

你观察到的功能重叠确实存在，但二者从内核架构设计上有本质区别，Azure SQL Database（哪怕是Hyperscale层级）不属于真正意义上的原生分布式数据库，你漏掉的核心差异集中在架构底层的写入模型、扩展逻辑、跨域能力几个维度，并不是云托管SQL已经覆盖了分布式SQL的所有场景。

1. 写入架构有本质区别 #

• Azure SQL Database 无论哪个服务层级，始终采用单主写入架构：全局只有1个可处理写请求的主副本，所有写操作必须路由到该节点执行。你提到的跨可用区/跨地域只读副本，本质是从主节点异步/半同步复制的只读节点，不具备写入能力。这种架构下写性能永远受限于单主节点的硬件规格上限，跨地域部署时远离主节点的业务写延迟无法优化；主节点故障时需要走故障转移流程，存在秒级到分钟级的服务中断窗口，跨区域故障转移的RPO、RTO都有明确上限。
• CockroachDB这类原生分布式SQL采用无主对等架构：不存在全局唯一的写主节点，集群内任意节点都可以接收读写请求，数据按范围自动分片打散到多节点存储，写入时只要满足副本多数派确认即可提交。你可以把节点部署在靠近用户的各个区域，实现就近写入，单节点故障时不需要走传统故障转移流程，RTO可以做到亚秒级，RPO为0不会丢数据。

2. 扩展能力的上限和逻辑完全不同 #

• Azure SQL的扩容本质是垂直扩容为主，水平扩容有硬边界：你提到的增加核心数、切换Hyperscale层级，本质是提升单主节点的计算规格，或者拆分底层存储页节点分担读压力，写入吞吐的上限始终绑定主节点的配置，不可能通过无限加节点提升写性能；且扩容过程普遍存在一定的性能抖动，极端场景下会有秒级业务闪断。
• 原生分布式SQL支持读写全链路线性水平扩展：不管是读还是写负载，只要向集群新增节点，整体吞吐就会随节点数线性增长，不存在单主带来的性能天花板；整个扩容过程是在线自动完成的，集群会自动迁移分片均衡负载，业务侧完全无感知。

3. 跨区域场景的能力灵活性天差地别 #

• Azure SQL的跨区域副本默认是异步复制，副本存在数据延迟，无法提供跨区域强一致读能力；如果配置跨区域强同步，写延迟会因为跨区网络往返成倍升高。同时它不支持细粒度的数据放置规则，如果你需要满足数据驻留合规要求（比如欧盟用户数据必须存在欧盟区域、中国区数据不能出境），同时还要支持全局统一的事务查询，基本需要靠多实例+自定义数据同步拼方案，复杂度极高。
• 原生分布式SQL天生支持细粒度的数据放置策略，可以指定某张表、某个分区的副本存储在指定区域，原生支持跨区域ACID强一致事务，不需要额外搭建同步链路，业务层不需要做事务补偿就能满足合规和全球访问的需求。

4. 架构的云厂商绑定属性不同 #

• Azure SQL是Azure生态的闭源托管服务，只能运行在Azure云平台，无法部署到其他公有云或者自建机房，使用后会完全绑定微软云生态。
• CockroachDB这类分布式SQL支持多云、混合云部署，可以在不同云厂商、自建机房混部节点，对业务侧呈现为统一的数据库集群，不会被单个云厂商锁定。

如果你的业务是单区域部署、写负载规模在单台高配数据库实例可承载的范围内、不需要做多区域多活就近访问、也没有多云部署需求，那Azure SQL确实是更省心的选择——它的运维成本更低，针对Azure生态做了深度优化，常规场景下性能表现更好。
只有当你碰到单主架构解决不了的场景时，才需要选原生分布式SQL：

• 需要做全球多区域active-active多活，要求就近读写，不能接受单主架构的跨区写高延迟
• 写负载规模超过单实例的性能上限，需要线性扩展写能力
• 有严格的数据驻留合规要求，同时需要全局强一致事务
• 架构要求多云/混合云部署，不能被单个云厂商绑定

内容的提问来源于stack exchange，提问作者ng.newbie