Most databases store data. SapixDB remembers it.
There's a difference — and once you see it, you can't unsee it.
Let me start with a story you've probably lived
You're on-call. 2am. A customer calls — their account balance is wrong. Your team starts digging.
You check the database. The number is there. But how did it get there? Who changed it? When exactly? Was it a bug, a race condition, a bad deploy, or something worse?
You spend four hours piecing together server logs, application logs, and git history trying to reconstruct what happened. At the end you're not even sure you found the full story.
This is the problem SapixDB was built to eliminate.
What SapixDB actually is
SapixDB is an AI-native database built on three ideas that no existing database combines:
Let's make each of those concrete with real situations.
Real situation 1: The corrupted financial record
The problem:
A fintech company processes 50,000 transactions a day. One morning a customer's balance is $12,000 lower than it should be. The Postgres transactions
table shows the current state. The application logs are partial. Nobody can tell if this was a bug, a double-debit, or something that needs to go to compliance.
How SapixDB handles it:
Every write to the transactions
agent is signed by the writing service with Ed25519 and BLAKE3-chained to the record before it. The chain is the record — you can't modify a past entry without breaking every hash that follows it.
Instead of four hours of log archaeology, you run:
"Show me every record written to the transactions agent for customer #4821 since Monday"
SapixDB returns the full chain — every credit, every debit, with cryptographic proof of the exact order they happened. You find the double-debit in 90 seconds. You can prove to the auditor it wasn't tampered with after the fact.
For SOX-regulated companies: mutation proposals targeting financial agents require dual-admin sign-off before they apply. No single person can modify the schema of a financial agent alone.
Real situation 2: The HIPAA audit
The problem:
A healthcare SaaS gets a compliance audit. The auditor wants to know: which patient records were accessed in the last 90 days, by whom, and whether any PHI was exported without authorization. The engineering team has a patients
table in Postgres and application-level logging. But the logs live in a different system. Matching them up takes days.
How SapixDB handles it:
The HIPAA package auto-detects 39 known PHI identifiers — patient_name
, dob
, ssn
, diagnosis
, medication
, ip_address
, and 33 more — the moment you write a record containing them. Each PHI blob is AES-256-GCM encrypted before it touches disk. Every read of a PHI-containing record is logged directly to the graph index with timestamp, record ID, and accessor identity.
When the auditor asks, you call one endpoint:
GET /v1/hipaa/report
You get a complete, machine-readable report: every PHI field, every encrypted blob, every access in the audit window — cryptographically linked to the strand. No cross-referencing. No assembly required. The report is the evidence.
Real situation 3: The AI agent that went off-script
The problem:
A company runs an AI agent that writes customer recommendations to a database. One week it starts recommending the wrong products. By the time someone notices, thousands of records are affected. Nobody can tell which records were written by the bad agent version, which were written by the good version, and what the agent "believed" when it made each decision.
How SapixDB handles it:
Every agent in SapixDB writes to its own strand with its own cryptographic identity. When you deploy a new version of the agent, the strand records which key signed which record. Time-travel queries let you reconstruct exactly what the agent saw and wrote at any point in time:
"Show me what the recommendations agent wrote between Tuesday 9am and Wednesday 2am"
You isolate every record from the bad window in seconds. You know exactly which customers were affected. You can prove to your team — and to your customers — that the records outside that window are clean, because the chain is unbroken and the signatures verify.
Epigenetics adds another layer: if the agent's write rate suddenly spikes (a classic signal of runaway behavior), SapixDB can automatically switch the agent into high_load
profile — throttling writes and disabling expensive LLM queries — until a human reviews what's happening.
Real situation 4: The schema that broke production
The problem:
An engineer drops a column from the orders
table. Three downstream services break immediately. Rolling back takes 45 minutes. Nobody approved the change. Nobody was notified. Post-mortem blame is everywhere.
How SapixDB handles it:
Schema changes in SapixDB go through Mutants — specialized meta-agents that propose structural changes and can never apply them without human approval.
The engineer's change would have been submitted as a mutation proposal. The Mutant tests it in an isolated sandbox against real query patterns. It produces a signed report: "removing this field breaks 3 known query patterns." That report lands in an admin dashboard. A human approves or rejects it. Nothing touches production until someone clicks approve.
When the change eventually lands, the approval is itself appended to the strand — signed, timestamped, immutable. The post-mortem has a clear answer: here is who approved what, and when.
Real situation 5: "What did our database look like last Thursday?"
The problem:
A SaaS company pushes a bad deploy on Thursday. By Friday they've patched it — but some records written during the window are corrupted. They need to know the exact state of the database before the deploy to restore clean data.
How SapixDB handles it:
Every record carries a Hybrid Logical Clock timestamp. Time-travel is not a snapshot feature you have to set up in advance — it works on every agent, always, because the chain is the history.
{ "type": "as_of", "timestamp_hlc": 1716400005000, "limit": 100 }
You get back the exact strand state at that moment. No backup restore. No point-in-time recovery configuration. No RDS snapshot lag. The history is in the chain — you just query it.
SapixDB vs Postgres — comparison
SapixDB is not a drop-in replacement. It speaks a different language (SaQL, not SQL) and it thinks differently (append-only strands, not mutable rows). But it covers every capability you rely on Postgres for — storage, relationships, blobs, auth, replication, backup, triggers, views, compliance — and adds a layer Postgres can never have: cryptographic proof that your data is exactly what it claims to be.
If you are starting a new project, especially one involving AI agents, SapixDB is the complete foundation. If you have an existing Postgres app, SapixDB can run alongside it via the built-in PostgreSQL CDC connector — pulling every change from your existing database into a tamper-evident strand — so you get the audit layer without rewriting anything.
The difference in one line: Postgres gives you a database. SapixDB gives you a database that proves itself.
Where to go from here
SapixDB is Live. SDKs available for TypeScript, Python, and Go. Self-hosted — your data never leaves your infrastructure.
If any of the situations above sound familiar, I'd genuinely like to hear about it. Drop a comment or message me directly.