Temporal KV: A Key-Value Store That Remembers History
Temporal KV is a key-value database where a key doesn’t just have a current value. The database automatically remembers how that value changed over time.
In an ordinary KV store, you might write price = 100, then later price = 110, then price = 125. Ask for price and you get 125. The earlier values have normally been overwritten. In a Temporal KV store, all three states stay logically accessible. You can ask for the current value and get 125, or ask “what was price at 10:00 yesterday?” and get 100. The basic abstraction stops being key → value. It becomes key + time → value.
The underlying storage can stay quite simple. Instead of storing something like A → X, it stores versions: A → X @ 10:00, A → Y @ 10:15, A → Z @ 11:20. A normal GET A returns the newest version. A temporal operation such as GET A AT 10:30 returns Y. You could also expose HISTORY A to return the sequence of changes, or GET A BETWEEN t1 AND t2 to look at a period.
Configuration makes a good practical example. A service stores api.timeout = 30. Someone changes it to 10, and two hours later the application starts failing. With ordinary KV storage you know the timeout is 10 now, and you may have no idea it used to be 30. Temporal KV lets you ask what the configuration looked like right before the failures started. The same primitive applies to device state, prices, inventory, feature flags, user preferences, infrastructure configuration, sensor readings and plenty of other values where “what was true then?” matters.
A primitive, not a temporal database product
What makes the idea appealing as a primitive is that history doesn’t have to grow into a large temporal database product. The API can stay tiny: PUT(key, value), GET(key), GET_AT(key, time), HISTORY(key) and maybe DELETE(key). Internally, every PUT appends a new version instead of destroying the old one. Compaction policies can come later, along the lines of “keep every version for seven days, hourly versions for a year, then one daily version forever.”
There’s also an interesting connection with AltSql. AltSql’s KV side could store changing device state locally while keeping versions, and the gateway’s SQL side could query that history. A sensor just does KV operations on a small device. The gateway can later ask something like SELECT value FROM history WHERE key='temperature' AND timestamp <= .... The same records serve both models.
In the money-first screen of the infrastructure primitives, TemporalKV ranked below Distill and Precomputing. Not for technical weakness. The problem clearly exists and the technology is easy to explain, but temporal features already exist in several database forms. “A tiny embedded temporal KV store” is interesting engineering. It isn’t yet a strong business differentiation.
The version worth keeping: history that knows what matters
There is a more distinctive variation: TemporalKV where history is bounded intelligently instead of kept forever. Combine it with Distill and the engine remembers every important change, not every write.
If a sensor reports 20.01, 20.02, 20.01, 20.03 thousands of times, those records hold almost no new information. If it suddenly jumps to 27.4, that state matters. A temporal store that keeps meaningful state transitions while collapsing redundant history on its own starts to look a lot more original.
That version stays on the primitive-project board.