流式数据库，开始把命押给 Postgres

做流式数据库的 Materialize，最近干了一件在分布式系统圈子里近乎『叛逆』的事：它没有自研 Raft 日志，也没有把元数据再挂到 Kafka 上，而是把整个线性一致元数据日志，直接建在了 PostgreSQL 的 READ COMMITTED 隔离级别之上。结果写入吞吐提升 3 倍，还顺手给出了一份 Lean 4 形式化证明。

几乎同一时间，PostgreSQL 18 正式发布，又一次完成开源数据库的年度大版本更新。

这两件事撞在一起，不是巧合。一个越来越清晰的信号是：Postgres 已经不只是『一个数据库』，它正在变成整个数据基础设施行业的公共地基。连最讲究一致性语义的流式数据库，都开始把最要命的元数据命脉押在它身上。

🧩 元数据日志：最不能出事的那块骨头

每个分布式数据库，都有一根不能断的脊梁。

对 Materialize 来说，这根脊梁就是元数据日志。作为一款流式数据库，它需要一条线性一致的日志来记录所有元数据变更——集合定义、索引、视图、订阅关系。这条日志一旦乱序、一旦出现脑裂，整个系统的『真相』就会分叉，下游所有物化视图都会变成薛定谔的查询结果。

按照分布式系统的传统剧本，这一步通常只有两条路：要么自己撸一套 Raft/Paxos 共识，要么依赖 Kafka 这类外置日志系统。前者意味着数年的工程投入和无数个通宵 debug 一致性 bug；后者意味着运维栈变厚，故障域变大。

Materialize 选了第三条路：把日志架在 PostgreSQL 上，但只用 READ COMMITTED 这个『最低配』隔离级别。

直观理解，这件事相当于：在不承诺严格串行化的地基上，盖出一栋要求严格串行的大楼。

据业内熟悉 Materialize 架构的人士评价，这个选择本质上是承认了一件事：共识问题的最难部分，PostgreSQL 早已替你解决——单节点的持久化、崩溃恢复、事务原子性，这些是 PG 打了三十年补丁的成熟地盘。Materialize 要做的，只是在这一层之上补齐『跨事务的日志语义』。

产业逻辑很朴素：当底座足够稳，上层创新的正确姿势不是重造底座，而是精确利用底座的最弱承诺，去构造你需要的最强保证。

🔬 Lean 4 证明：数据库工程的新军备竞赛

这次发布里最『学院派』的部分，恰恰最有产业含金量：一份 Lean 4 形式化证明。

在 READ COMMITTED 上构造线性一致日志，正确性论证是出了名的难写——你要证明的是：即便底层只保证『读已提交』，上层的日志序号分配、去重、提交协议组合起来，依然能对外呈现线性一致的日志视图。这种证明用自然语言写，审稿人很难服气；用测试覆盖，更不可能穷尽并发交错。

Materialize 的解法是把协议直接用 Lean 4 写出数学证明。

这不是孤例。近几年，形式化验证正从论文走进行业头部团队的生产流程：共识协议、日志复制、隔离级别实现，越来越多核心组件开始带证明上线。背后的驱动力很现实——分布式系统里最难复现的 bug，恰好是最贵的 bug。一个元数据分叉，损失的是整个集群的可信度。

多位深耕数据库内核的工程师私下表达过类似判断：未来几年，『带机器可检验证明的核心组件』会从加分项变成门槛项，尤其是在元数据、事务协议这种一错就全盘皆输的模块上。

对用户而言，这意味着一个可感知的变化：数据库厂商之间比拼的，正在从『功能多不多』转向『正确性能不能被证明』。

📈 在最弱隔离上造最强语义，账是这么算的

『READ COMMITTED 上建线性一致』听起来反直觉，但拆开工程账本，逻辑非常清楚。

第一笔账是吞吐。更高隔离级别意味着更多锁冲突和更长的关键路径；Materialize 把一致性逻辑上移到自己控制的协议层，让 PG 只承担它最擅长的事，结果是写入吞吐提升约 3 倍。对元数据日志这种『高频小写入』的负载，3 倍不是优化，是可用性的分水岭。

第二笔账是故障域。自研共识的故障，藏在几万行状态机代码里；而 PG 的崩溃恢复、磁盘损坏处理、备份恢复工具链，是整个行业几十年实战淬炼出来的。把最难验证的部分外包给最成熟的组件，等于把风险换成了已知量。

第三笔账是运维。对 Materialize 的客户来说，元数据存储就是一个标准的 PostgreSQL 实例——备份、监控、高可用，全部走熟悉的老路。没有新的运维面，就是最实在的产品力。

这笔账背后有一条对全行业都成立的判断：隔离级别不是越高越好，而是『最弱够用的那个』才最大化系统整体收益。把一致性责任放到正确的层，比在每一层都堆最强保证，工程上便宜得多。

🐘 PostgreSQL 18 发布：底座时代的注脚

把镜头拉远，Materialize 的选择正好落在一条大趋势线上：PostgreSQL 18 正式发布，开源数据库完成又一次年度大版本迭代。

今天的数据基础设施版图里，PG 的角色早已超出『一个关系型数据库』。它是大量分布式数据库的兼容目标和存储底座，是各类 SaaS 的事务核心，如今又成了流式数据库元数据层的宿主。年度大版本的稳定节奏，意味着这个生态的演进有可预期性——而可预期性，恰恰是『底座』最核心的商业属性。

用四象限看当下『元数据日志方案』的格局，会看得更清楚：

注意 Materialize 方案的位置：技术门槛不算最高，但商业价值最高——因为它同时兑现了吞吐、可靠性和运维成本三重收益。而自研 Raft 虽然技术含金量拉满，在没有规模效应的团队手里，往往沦为『高门槛、低回报』的沉没成本。

据多位接近数据库创业公司的人士透露，『新项目还该不该自研存储/共识层』已经成为不少团队立项时的真实争论，而过去一年，天平明显在向『复用 Postgres』一侧倾斜。

⚠️ 底座之上，创新的重心在换层

Postgres 化的终局是什么？是数据库行业的一次『重心上移』。

当存储、复制、恢复这些最难的部分被 PG 标准化，竞争就不再是『谁的存储引擎更好』，而是：谁能在底座之上，用更薄的协议层、更可证明的正确性、更低的运维成本，交付差异化语义。Materialize 这次给出的答案——READ COMMITTED 加上层协议加 Lean 4 证明——很可能成为后续团队抄作业的标准模板。

当然，这条路有边界：元数据日志的写入规模终究有限，PG 单实例的可用性上限仍需上层高可用方案兜底。它不是万能公式，但在『正确性 > 一切』的元数据场景里，它可能是当前性价比最高的公式。

真正值得记住的，是这次发布背后的方法论转向：强者不做最难的事，强者做最正确的事。当 PostgreSQL 18 如约而至、底座继续稳固，下一个把核心组件押上来的，会是谁？