cockroachdb/cockroach

如果你的业务已经超出单机 Postgres 的容量，但仍想保留 SQL 和事务，CockroachDB 值得认真评估。但请先读许可证，再决定是否投入。

解决什么问题

团队通常从一台 Postgres 起步，随后数据量或写入压力逼着做选择：手工分库分表、加只读副本，或者把数据层改写成非关系型存储。每条路都会把路由逻辑、故障切换和数据搬运脚本塞回应用代码。CockroachDB 的做法是继续提供一个标准 SQL 入口，把复制和再均衡留在集群内部处理。应用侧仍可使用兼容 Postgres 的驱动或 ORM，运维精力则从改应用代码转移到维护和调优一个分布式集群。

有什么不同

SQL 之下是一个事务型键值存储，数据在节点间复制，并对 ACID 负载提供强一致性，项目在产品概览和架构文档中有说明。实际好处是节点、机架甚至数据中心故障交由集群处理，而不是靠一份故障切换手册；扩容时横向加节点即可，不必重新设计表结构。

代价是它并非可直接替换的 Postgres。协议层兼容带来了大量驱动和 ORM，但边界行为以及多节点集群的运维方式仍需要用你自己的查询和工具链去验证。本地跑起来很简单，跑好却需要理解复制和拓扑选择，架构文档正是为此存在。另一个真实差异是许可证，见下文。

谁值得试

适合：拥有关系型负载、有多地域或高可用要求、并且愿意运维分布式系统（或愿意付费使用托管集群来跳过这部分）的后端团队。CockroachCloud 快速入门和免费套餐注册路径让你不必先准备机器就能评估数据库本身。

不适合：跑在单台服务器上的小应用，单机 Postgres 或 MySQL 在注意力和成本上都更划算；需要深度依赖 Postgres 专有扩展和生态行为、而不只是线路协议兼容的团队，也不适合。无法接受当前许可证条款的人同样不适合，详见下文。

使用条件与边界

第一是许可证。根据 README 的许可说明，v24.3 及之后的版本采用 CockroachDB Software License，部分 v23.x/v24.x 补丁版本也重新授权。它不属于 OSI 意义上的开源，条款会影响再分发以及基准测试的方式。2025-03-19 有一位 HN 评论者表示因反复的许可证变更而移除了 CRDB，同时肯定其分片和复制能力；这只是某个团队对当时决策的说法，不能当作对现行条款的结论。请自行阅读对应版本的许可证文本。

第二是运维负担。手工部署、云部署和编排指南都有，但多节点集群需要监控、容量规划，并理解故障时的行为。低承诺的评估路径有两条：云端免费套餐和本地单节点集群。第三，从源码构建是一个比较大的 Go 构建任务，文档与二进制安装分开，多数人应直接使用预编译可执行文件。第四，Postgres 兼容性要在自己的应用上验证，不能默认成立。

HotRepo 点评

HotRepo 只有一条日榜记录：2026-10-26，32,584 stars，当日 +4。单个快照无法说明关注度在上升、消退还是持续，暂时不能判断持久性；2014 年 HN 帖子的 98 分和 66 条评论只是当时的讨论量，不是当下采用情况的证据。真正要决定的是许可证和运维模式是否适合你的团队，而不是 CockroachDB 是否有意思。建议核对计划部署的具体版本的许可证文本，并在迁移前用最重的 Postgres 查询在集群上实测。