Copy-on-write timelines, explained
The second most important architectural decision in Trubase DB is how data is stored and shared between backends. The write-ahead log is the database; state lives as immutable copy-on-write layers on object storage, organized into branchable timelines. This is what makes branching O(1) and storage sharing nearly free.
In traditional PostgreSQL, data is stored in 8KB pages on local disk. Platforms that added 'branching' to that engine had to coordinate it from outside — an external storage service copying references, a control plane updating metadata, compute being provisioned. It takes seconds because it is infrastructure pretending to be an operation.
In Trubase DB, state lives as immutable layers on object storage, addressed by timeline and position in history (LSN). When you branch a backend, the engine writes a new timeline record that says: parent, fork point. That's it. No data copied. No control plane involved. A metadata write, milliseconds.
When the branched backend reads page N, the engine walks the timeline ancestry: current timeline first, then parent, then grandparent, up to the root. First hit wins. This is exactly how Git resolves file contents through commit ancestry, applied to database pages — and the same read path serves time-travel queries, because 'as of yesterday' is just another position in the ancestry.
When the branched backend writes to page N, only that page's new version lands in the branch's timeline. Everything else still resolves to the parent. This is copy-on-write at page granularity — not file level, not volume level.
The storage math is compelling: 10,000 branches of a backend with 1TB of data. If each branch modifies 800KB of pages, total additional storage is ~8GB. Not 10 petabytes. Storage overhead scales with actual divergence, not with the number of branches.
Because layers are immutable once written, branches get snapshot isolation for free. A branch sees exactly the state that existed at its fork point, regardless of what the parent does afterward. No locking. No coordination. The timeline structure provides natural isolation.
This design is only possible because object storage provides effectively infinite, cheap, durable capacity. Traditional databases assumed expensive, limited, local disk. That assumption is 30 years out of date — and one correction matters: the object store is never on the commit path. Commits are acknowledged by a quorum of engine nodes first; layers upload asynchronously.