前言

在刚刚圆满落幕的 PGConf.Russia 2026 开发者大会上，YMatrix提出了一个打破常规的命题：PostgreSQL 或许从诞生之日起，就是一个被低估的流处理系统。

本文将深度解读演讲背后的核心逻辑，带您揭开 Domino 如何通过对 WAL（预写日志）的重新定义，构建起一套基于 PostgreSQL 的原生增量计算模型。

01 一个从未被提及的问题——如果 PostgreSQL 本身就是一个流处理系统呢？

乍听之下，这个观点似乎不合常理 。在我们的认知中，流处理系统应该是像 Kafka 或 Flink 那样，专为持续数据处理而设计的架构。而 PostgreSQL，通常被视为一种传统的“存储+查询”型关系数据库。

但事实上，这两者之间的界限或许并没有我们想象中那么不可逾越。

02 WAL（预写日志）即是“流”

PostgreSQL 中，每一次数据变动都会记录在 WAL（Write-Ahead Log） 中。WAL 具备三个核心特性：

• 仅限追加（Append-only）

• 严格有序（Strictly ordered）

• 持久化存储（Durable）

这正是“流”的定义性特征 。从系统底层视角来看：WAL 不仅仅是日志，它本质上就是一个流。

一旦接受了这个设定，一个新的问题便随之而来：既然 PostgreSQL 已经拥有了流，为什么它在表现上却不像一个流处理系统？

03 缺失的拼图：计算模型

PostgreSQL 与流处理系统之间的真正差异不在于“数据”，而在于“计算”。

• 传统 PostgreSQL： 采用“批处理”模型。查询读取快照、计算结果、返回数据。一旦数据发生变化，必须重新执行整个查询 。

• 流处理系统： 采用“增量”模型。对变更做出反应，并实时更新结果。

核心差异在于：批处理是重新计算（Recomputes），而流处理是实时响应（Reacts）。

04 从 SQL 到增量计算

如果 WAL 是流，那么下一个挑战就是：SQL 可以在流上运行吗？

答案是肯定的，但这需要改变 SQL 的执行方式——将其从传统的全量计算转变为增量计算模型。这就是我们所说的：DeltaPlan

DeltaPlan 彻底改变了执行范式：

• 不再重新计算结果，而是传播变更

• 每一次更新都变成一个增量（Delta）

• 每一个算子都演变为增量算子

这让 SQL 变成了一个持续计算引擎 。

05 PostgreSQL 流处理模型

基于此，我们可以构建出一个统一的模型：

WAL → Logical Decoding → Events
                ↓
             DeltaPlan
                ↓
       Streaming Execution
                ↓
         Continuous Results

在这个核心理念下：

• WAL 提供流来源

• DeltaPlan 定义计算逻辑

• 执行过程变为持续性

• 查询结果不再是静态表，而是一个实时更新的视图

06 重新思考 PostgreSQL

这将引发我们对 PostgreSQL 认知的根本性转变 ，PostgreSQL 不仅仅是一个数据库，它已经包含了：

• 流数据源（WAL）

• 强大的计算语言（SQL）

它原本唯一欠缺的，是连接两者的桥梁 。一旦这座桥梁搭建完成：PostgreSQL 就会蜕变为一个真正的流处理系统。

07 Domino 的使命：将隐性范式显性化

Domino 并不是在引入一种全新的范式，而是将那些隐藏在幕后的特质显性化 。

• 流化 WAL：将预写日志提升为一等公民的“流”；

• 重塑 SQL：将传统查询转化为高效的增量计算；

• 进化 Table：将静态数据库表转化为持续更新的实时视图。

简而言之：

Domino 是 PostgreSQL 流处理模型的具象化实现。

08 结语

回到最初的那个问题：PostgreSQL 已经是一个流系统了吗？

如果 WAL 是流，如果 SQL 可以实现增量化，那么答案显而易见：是的。

PostgreSQL 本身就是一个流系统，只是在此之前，我们未能窥其全貌。