在对象存储上跑版本化 LTAP，Penca 这种架构尝试能否解决数据湖的痛点？

最近在关注开源数据库项目时，Penca 这个项目引起了我的注意。它试图在对象存储（Object Storage）之上构建一套同时支持 OLTP（事务处理）和 OLAP（分析查询）的 LTAP 架构，而且最核心的竞争力在于它引入了类似 Git 的版本化管理和分支能力。

从目前的 PoC 阶段来看，Penca 的核心逻辑是将存储分成了“热层”和“冷层”。写入请求首先进入由 Postgres 承载的临时热层，确保事务的实时性；随后后台进程会将已提交的行数据异步刷成列式文件，持久化到对象存储的冷层中。在执行查询时，它利用 DataFusion 引擎将热层与冷层的结果集进行合并。这种设计思路虽然在 Databricks 等商业产品中已有体现，但 Penca 选择了 Apache 2.0 开源协议，并把“版本化”作为第一优先级。

我对这个项目最感兴趣的点在于它对“版本化”的实现。在传统数据库中，实现数据回滚或审计通常依赖于复杂的 WAL 日志解析或快照备份，而 Penca 利用了对象存储天然的不可变性（Immutability）。它将每次提交类比为 Git 的 commit，通过快照机制实现 as-of 查询。这意味着用户可以像切换代码分支一样切换数据版本，在进行大规模数据迁移或实验性分析时，这种分支能力能极大地降低误操作带来的风险。

不过，这种架构在实际落地时必然面临性能挑战。分支意味着多版本数据的共存，查询引擎在执行时必须在多个快照之间进行一致性选择，这在处理海量数据时会产生显著的元数据开销。如果索引机制不能在版本间高效传递，查询延迟可能会随着分支数量的增加而线性增长。

此外，这个项目的开发背景也很有意思。作者在仓库中坦诚该项目是重度依赖 AI 生成的，甚至将完整的 AI 开发工具链直接保留在仓库里。这其实成了一个很有价值的实验：一个复杂的数据库底层项目，在 AI 编程的支撑下，能否在短时间内完成从构思到 PoC 的闭环。

当然，目前的 Penca 还处于非常早期的阶段，距离生产环境还有很大差距。最明显的瓶颈在于隔离级别，目前仅支持最简单的 last-write-wins（最后写入获胜），这意味着它还无法处理复杂的并发冲突。同时，它目前还不支持多语句 SQL 事务，且 pgwire 前端尚未完成，这意味着你还不能直接用标准的 Postgres 客户端无缝接入。

即便如此，它的路线图（Roadmap）依然很激进，计划引入 Iceberg 导出、全文索引以及更完善的分支管理。如果 Penca 能将版本化能力打磨到生产级别，它实际上就变成了一个自带“时间旅行”功能的数据湖。对于很多需要频繁进行数据回溯、审计或环境隔离的数据工程团队来说，这种将数据库版本化与对象存储结合的方案，比传统的表结构变更要优雅得多。