SirixDB: Git-like Versioning for Databases
The distinction between "transaction time" (when we recorded it) and "valid time" (when it actually happened) is where this gets powerful. If you record a price as $100 on Jan 1, but realize on Jan 20 that it was actually $95, SirixDB lets you query both perspectives. You can ask what you thought the price was on Jan 16, or what the price actually was on Jan 1.
The architecture is built on an append-only physical log and a persistent copy-on-write page trie. Here is the high-level view:
Physical Log (append-only, sequential writes)
┌────────────────────────────────────────────────────────────────────────┐
│ [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 → timeEach revision is indexed, and unchanged pages are shared across versions:
[Rev 1] [Rev 2] [Rev 3]
│ │ │
▼ ▼ ▼
[Root₁] [Root₂] [Root₃]
│ │ │ │ │ │
│ └─────────┐ │ └────────┐ │ └─────────┐
▼ ▼ ▼ ▼ ▼ ▼
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│ P1 │ │ P2 │ │ P1' │ │ P2' │
└──────┘ └──────┘ └──────┘ └──────┘
Rev 1 Rev 1+2 Rev 2+3 Rev 3
(shared) (shared)From a performance standpoint, the project hit a massive wall with JVM garbage collection because it stores fine-grained nodes. Too many small objects on-heap killed the throughput. To fix this, I used an AI workflow to automate the tedious migration of the storage layer to Java's Foreign Function & Memory API. Moving pages completely off-heap was a huge win!
Since the design is immutable and append-only, it's a perfect fit for S3 or Kafka. For any indie hacker worried about data integrity and audit trails, this "Git for data" approach is way more secure than just overwriting rows in a standard SQL table. Everything is queryable via JSONiq through the Brackit compiler.