SirixDB：给数据库加个 Git 版本管理
数据库最恶心的地方就是数据一旦覆盖就找不回来了，除非你得像傻子一样写一套复杂的 Event Sourcing 逻辑去回溯。SirixDB 的逻辑直接把“历史”变成了一个一等公民，简单说就是给数据库实现了类似 Git 的版本控制。
下一篇
Coasty：让没 API 的老旧软件也能被 AI 操控 →
最让我感兴趣的是它处理“交易时间”和“有效时间”的差异。比如 1 月 1 日录入的价格是 100 元，结果 1 月 20 日发现录错了，实际应该是 95 元。在普通数据库里，你改了就没了；但在 SirixDB 里，你可以分别查“1 月 16 日我们认为价格是多少”和“1 月 1 日实际价格是多少”。这种对数据的回溯能力，在处理审计或复杂财务对账时简直是救命药。
从开发体验来看，它的底层架构挺硬核，用了 append-only 物理日志和 copy-on-write 页面树，通过共享未更改页面来节省空间。
一个值得关注的细节是，这个项目之前因为 JVM 堆内存垃圾回收（GC）压力导致性能极差。作者在最近的迭代中用了 Java 的 Foreign Function & Memory API 把存储层直接搬到了堆外（off-heap），彻底解决了内存分配导致的吞吐量瓶颈。这其实给了我们一个启发：当 AI 介入开发后，这种枯燥的底层重构工作效率被大大提升了，很多之前因为太繁琐而搁置的优化现在都能快速落地。
目前它支持通过 JSONiq 进行查询。对于需要强版本管理、频繁对比数据差异（Diff）的场景，这东西比自己写版本表要高效得多。
其核心架构逻辑如下：
物理日志 (仅追加，顺序写)
┌────────────────────────────────────────────────────────────────────────┐
│ [R1:Root] [R1:P1] [R1:P2] [R2:Root] [R2:P1'] [R3:Root] [R3:P2'] ... │
└────────────────────────────────────────────────────────────────────────┘
t=0 t=1 t=2 t=3 t=4 t=5 t=6 → 时间线