Ledgerstore is an immutable, append-only database for the records that get subpoenaed. Every write is hash-chained to the one before it, so your history can be proven instead of trusted. There is no UPDATE. There is no DELETE. There is no quiet edit at 2am.
INSERT INTO audit.events (actor, action, target)
VALUES ('u_8821', 'role.grant', 'admin');
-- seq 4,210,338 · committed in 6ms
-- prev 9f2c…a17e
-- hash c4d1…7b09 ✓ chain intact
UPDATE audit.events SET action = 'noop';
ERROR 42P01: relation "audit.events" is append-only
DELETE FROM audit.events WHERE seq = 4210337;
ERROR 42P01: relation "audit.events" is append-onlyHolding the records that show up in discovery
A normal database answers "what is the data right now?" Ledgerstore answers "what happened, in what order, and can you prove nobody rewrote it after the fact?" That gap is the difference between a log and evidence.
Every record carries the hash of the record before it. Change one row and every hash downstream stops matching — tampering doesn't hide, it screams. Verifying the whole chain is one API call, not a forensics engagement.
The two statements that erase the past aren't in the grammar. Corrections are new events that supersede old ones, so the mistake and the fix both survive. Auditors read the full story, not the cleaned-up version.
Every few seconds a Merkle root is anchored to write-once storage outside the cluster. A rogue admin with root can rewind their own copy, but they can't rewind the anchor — the two stop agreeing, and that disagreement is the alarm.
Reconstruct the exact state of any record at any second in its history. "Who had admin on March 3rd at 14:02?" becomes a SELECT, not a week of log spelunking.
Query with plain SQL over your existing Postgres drivers. Writes are immutable; reads behave like the database you already run. Nothing new to learn, nothing to rewrite.
Built for records that outlive the engineers who wrote them
Immutability here isn't a permission you can revoke or a flag an admin can flip. It's structural — built into how every byte is stored, sealed, and proven.
An event lands with a monotonic sequence number and the hash of its predecessor. The moment it commits, its bytes are frozen: there is no code path anywhere in Ledgerstore that mutates a committed event.
Batches roll into a Merkle tree, and the root is anchored to write-once object storage off-platform every few seconds. The seal ends up somewhere your own operators can't reach to undo it.
Pull an inclusion proof for any record and verify it yourself — with our open verifier or fifty lines of your own code, no Ledgerstore access required. The proof is a few hundred bytes and travels straight into an audit binder.
A background verifier re-walks the entire chain around the clock and pages you the second a single link fails to match. You hear about tampering in seconds — not from a regulator a year later.
Wherever "who did what, and when" has to survive a lawyer, an auditor, or a breach, Ledgerstore is the layer sitting underneath it.
Every grant, revoke, and login lands as a frozen event — so when you're reconstructing a breach, the timeline is one nobody could have edited on their way out the door.
Append each ledger movement and approval as it happens. Hand regulators a portable cryptographic proof of the sequence — not a CSV export and your word that it's complete.
Capture consent, access, and chart edits under HIPAA in a history that survives staff turnover and litigation, because no clinician or DBA can quietly revise what was recorded.
Seal every training set, prompt, and deploy decision the moment it's made, so two years later you can prove exactly what the model was trained and shipped on — to a board, a court, or a regulator.
Record each hand-off and inspection as a sealed event that every partner can verify independently — a chain of custody with no single party holding the eraser.
Treat every infra change as an immutable event. After an incident, replay the exact order of what shipped before it broke — instead of arguing over who pushed what.
“SOC 2 evidence used to be a quarterly fire drill of screenshots and spreadsheets. Now the audit trail is the source of truth and we hand over a proof file. Our auditor stopped asking for screenshots three cycles ago.”
“A former engineer swore a record had been altered after he left. We pulled the inclusion proof and the hash chain ended the argument in four minutes. On vanilla Postgres that's a forensic firm and a very bad week.”
“What sold our board was the part where I admitted I can't cheat it either. Not me, not with root, not on a bad day — the system simply has no path to delete a consent record. That's the whole point.”
Metered on writes — not seats, not storage tiers. Reads and verification are always free, because proving your data shouldn't cost extra.
For prototypes and side projects.
For products with real audit requirements.
For finance, health, and government.
Both can still be UPDATEd or DELETEd by anyone with the right access — your audit trail is only as honest as your most privileged admin on their worst day. Ledgerstore removes mutation from the data model entirely and hash-chains every write, so tampering breaks the chain and is provable, not just frowned upon.
No, and that's deliberate. There's no token, no consensus network, no proof-of-work tax on every write. You get the one property teams actually need from that world — tamper-evident, independently verifiable history — at database latency, behind plain SQL, anchored to storage you control. It feels like Postgres, not like running a node.
You append a correcting event that supersedes the original. The reads API resolves to the current state, while the full lineage — original error included — stays intact. Your app sees the right answer; your auditor sees the correction and the history behind it.
Yes — that's the design goal. Inclusion proofs and Merkle roots are portable and standards-based, so you can verify any record with our open-source verifier or your own code, against an anchor you hold. The guarantee never reduces to "trust Ledgerstore."
Keep personal data encrypted off-chain and store only hashes and pointers in the ledger. Crypto-shredding the key makes the payload permanently unrecoverable, while the immutable proof that the event existed and where it sat in the order stays intact. Erasable contents, unerasable record.
Median append latency is around 8ms and a single cluster sustains over a million events per second. Hash-chaining happens inline as part of the commit, so immutability costs you almost nothing at write time.
Bulk-import your historical records, we seal them into a starting chain, and you point your app at the append API. Reads stay standard SQL over your existing drivers, so most teams are live the same afternoon.
Spin up a ledger, append an event, and pull a cryptographic proof of it — in under five minutes, with no sales call between you and your first write.