在分布式系统领域，CAP 定理长期被视为设计决策的基石。然而，2010 年数据库领域的传奇人物 Michael Stonebraker 连发两篇重磅文章，对这一理论提出了尖锐的工程化批判。Stonebraker 是 Ingres 和 PostgreSQL 的创始人，2014 年图灵奖得主，他在工业界和学术界都有着举足轻重的地位。他的批判并非出于学术争议，而是源于数十年构建数据库系统的实战经验。理解这些批判，对于把握现代数据库技术的发展脉络至关重要。
Stonebraker 对 CAP 定理的首要批评在于其错误模型过于理想化和不完整。传统的 CAP 定理只关注网络分区这一种故障模式，但现实世界中的数据库管理员需要应对远比这更加复杂的故障场景。Stonebraker 在其文章中详细列举了 CAP 定理忽略的几种关键故障类型：第一类是 Bohrbugs，即可重复的数据库引擎错误，当这种缺陷被触发时，所有副本都会崩溃，无论系统设计多么精妙，高可用性都无从谈起；第二类是应用层错误，应用程序可能无意中同时污染所有数据副本，此时任何理智的数据库管理员都会选择停止系统并进行恢复；第三类是人为失误，管理员可能执行了错误的批量操作导致全局故障；第四类是资源重配置，许多数据库系统在进行硬件扩容或缩容时需要停机，这同样是 CAP 定理未能考虑的场景。Stonebraker 强调，这些「不可屏蔽」的故障在任何分布式系统中都会导致不可用，单纯讨论 CAP 三选二在工程实践中毫无意义。
将单机故障归类为网络分区是 Stonebraker 批评的另一个重点。在他看来，把一个失效节点视为一个独立分区是对 CAP 定理的误用。当一个节点宕机时，系统完全可以无缝切换到备份节点并保持事务一致性，这正是 Tandem 和 Vertica 等传统商业数据库多年来一直在做的事情。因此，用 CAP 定理来论证单机故障场景下必须在可用性和一致性之间做选择，在工程上是明显错误的。这一观点揭示了 CAP 定理在描述真实系统行为时的局限性，也提醒开发者不应机械地套用理论模型。
Stonebraker 最具影响力的批评集中在工程决策层面。他观察到 NoSQL 运动将 CAP 定理作为放弃 ACID 事务的理论依据，主张在网络分区时优先保证可用性而非一致性。然而他的分析表明，网络分区的实际发生频率远低于 Bohrbugs、应用错误、人为失误和系统重配置等事件。这意味着即使完美处理了网络分区，对整体可用性的提升也微乎其微，因为更高频的故障会持续导致系统中断。换言之，为了一个低概率事件牺牲数据一致性，却得不到任何实质性的可用性收益，这是一笔极其糟糕的工程交易。Stonebraker 批评这种做法是「用大炮打蚊子」，在错误的战场投入了过多的战略资源。
在解决方案层面，Stonebraker 提出了一个颠覆性的视角：与其在大量不可靠节点上通过冗余来掩盖故障，不如使用更少数但性能更强的节点来减少故障发生的概率。他以自己创办的 Volt Active Data 为例，指出新一代数据库技术相比传统 SQL 引擎可以实现约 50 倍的性能提升。如果某个应用需要 200 个节点来支撑，Volt 只需要 4 个节点就能完成同样的工作。200 个节点发生故障的概率与 4 个节点相比有着本质区别，「以数量换可靠」的粗放策略在故障率面前显得苍白无力。这一观点深刻影响了后来的 NewSQL 系统设计哲学，即通过极致的单节点性能配合精心设计的分布式协调机制，在保证强一致性的同时实现可扩展的高性能。
Stonebraker 的批判对现代数据库设计产生了深远影响，催生了多条技术路线的演进。首先是以 Google Spanner 为代表的 TrueTime 系统，它通过原子钟和 GPS 接收器实现精确的时间同步，在保证强一致性的同时提供全球分布式的扩展能力，证明了 CAP 中的 C 和 A 并非不可兼得。其次是 HTAP（混合事务分析处理）架构的兴起，这类系统如 TiDB、Snowflake 等试图在同一系统中同时满足 OLTP 和 OLAP 的需求，其设计理念正是 Stonebraker 所强调的「不妥协」—— 既不放弃一致性也不放弃性能。第三是学术界对 HAT（高可用事务）的研究，UC Berkeley AMPLab 的研究表明，在许多实际场景下可以实现同时满足可用性和强语义的事务系统。这些技术发展路径都可以追溯到 Stonebraker 对 CAP 定理的批判精神：不被教条束缚，而是从工程实际出发寻找最优解。
值得注意的是，Stonebraker 的批评也带有其时代背景和商业利益考量。他的文章发表于 NoSQL 运动兴起的高潮期，而他是 Volt Active Data 的创始人，该公司主打的是强一致性 OLTP 数据库。然而，这并不削弱其批判的核心价值 ——CAP 定理作为一个数学模型，其假设前提与工程实践之间确实存在显著鸿沟。现代数据库从业者应当将 Stonebraker 的观点视为一种「解毒剂」，在面对 CAP 定理的教条化应用时保持清醒的工程判断。最终，数据库设计应当基于具体的业务需求、故障频率分析和技术约束的综合考量，而非简单地在 C、A、P 三个字母之间做选择题。
参考资料：Stonebraker, M. (2010). "Clarifications On The CAP Theorem And Data-Related Errors", Volt Active Data Blog.