What the data said, who changed it, and proof the record was not altered.

A regulator, an auditor or a court asks three questions: what did the record say on that date, who changed it, and can you show the log of changes was not edited. Tessera DB answers each from the store itself.

Three questions, answered by the store.

What did it say on that date?

On a table that keeps its history, SQL reads it as it was at any instant with FOR SYSTEM_TIME AS OF. An UPDATE or DELETE keeps the old row as history.

Who changed it?

Every write records who made it, through which door, when, and from which load. An end user signed in through your app is recorded as that user.

Was the log altered?

The audit trail is hash-chained and each entry is written before the change it records. Verifying the chain names an entry that was edited. Pro and above.

Around those three.

Encryption at rest

AES-256-GCM over the write-ahead log, the segments and the audit log. It fails closed: the server will not start if the key is missing.

Point-in-time restore

Restore to a moment, respecting transaction boundaries: a transaction still open at the cutoff is discarded, not half-applied.

Right to erasure

DELETE HISTORY FROM erases chosen rows' past, alongside DELETE, for an erasure request; erasing a whole tenant is a Pro feature.

Your own hardware

One program on machines you control, including air-gapped sites. A query needs no external service.

History in two statements.

-- A table that keeps its history from the first row
CREATE TABLE Transfer () WITH SYSTEM VERSIONING

-- The table as it was at that instant
SELECT tid, amount FROM Transfer FOR SYSTEM_TIME AS OF '2025-09-01T12:00:00Z'

History is opt-in per table and costs storage: one old row per UPDATE and per DELETE. On a table that keeps no history, AS OF is refused rather than answered wrongly.