What if your database could rewind?

What is it?

A chronological key/value database built around Git architecture and version history.

What problem does it solve?

Git-style history is a compelling idea. Compatibility is the harder question.

What does it replace?

Potentially a custom history layer around changing key/value records.

What doesn’t it replace?

Redis or PostgreSQL without workload-specific compatibility checks. Speaking a protocol does not establish feature parity.

Who is it for?

Developers exploring historical records, branches and time-aware data.

The review notebook

Most databases are good at telling you what a value is now. Asking what it used to be often means building another system beside the first one. A database organised around history changes that starting assumption.

The useful review would separate two questions: does the history model solve a real problem, and how far can existing clients travel without surprises? We have not run that comparison. Until we do, the presence of familiar protocol names should not be read as a drop-in replacement verdict.

Known catches & open questions

Protocol coverage, transaction behaviour and operational costs need checking against the exact application you intend to run.

Current judgement

This is a promising lead, not a recommendation. We will only make a hands-on judgement after the stated test has been run.

Next on the bench

Define a small client workload, list its required commands, and test those alongside historical reads and restart recovery.

Sources & evidence

Project repository and README ↗
Release history ↗

Public material checked 5 September 2026. Version labels are the latest stable release returned at that check, where available. Platform descriptions are upstream claims, not Toolglass acceptance tests.