Mandala and traditional databases.
PostgreSQL and MySQL have run the world’s applications for about thirty years. Karma, the ledger inside Mandala, is not trying to replace them. It makes one different choice at the bottom: it keeps what happened, and derives what is. That choice suits some work very well and other work not at all.
Checked 12 October 2026
Three decades of getting it right.
A general-purpose SQL database with a planner that handles questions nobody planned for, strong transactions, and extensions for vectors, maps, time series, graphs and ranked text search. Version 18 added temporal constraints for application time.
The database behind a very large share of the web, with long-term support releases, mature replication, and every hosting company and framework ready for it. MariaDB, its relative, has built-in system-versioned tables that keep a row’s history.
A full SQL engine in a library, with the database in one file. Like Karma it lives inside the program that uses it. Unlike Karma it speaks SQL, and it is deployed almost everywhere.
If keeping history is your main need and you want a mature, standalone database for it, these exist: immutable facts with as-of queries, bitemporal SQL, an event store, and SQL you can branch and merge.
A row that is updated, or a fact that is added.
A traditional database stores the current row and changes it in place. Its write-ahead log exists for recovery and replication, not as a history you query. To know who changed what, you add something: triggers and history tables, temporal tables, change data capture, or an audit extension that logs statements. Karma starts from the other end. The signed fact is what is stored, and the row you read is a view of the facts.
- v1
RequestMira, for HermesLumon Industries · Moon · 120 units · 2 crates - v2
CheckCrateBendercrate 1 of 2 - v3
CheckCrateBendercrate 2 of 2 - v4
PayHermespaid - v5
ConfirmLeelanot the one who asked - v6
ShipFryto the Moon
1 requested · 1 confirmed · 1 shipped
“moon” → Lumon Industries
| where status == Requested→ Los Pollos Hermanos · 2 msWhere they differ.
| PostgreSQL · MySQL | Mandala (Karma) | |
|---|---|---|
| What is stored | The current row, updated in place | Every change, as a signed fact. Rows are derived |
| History | Added by you: triggers, temporal tables, change captureMariaDB has system-versioned tables built in; PostgreSQL does not | Built in. It is the data |
| Who changed it | A database role or an application user, if your code records it | A signature on each fact: who, for whom, under which rule |
| Rules | Constraints, triggers and row-level security, plus your application code | The contract, checked before a write is accepted, for every caller |
| Asking questions | SQL: any question, any time, planned on the spot | Queries and views declared in the contract and kept current. No SQL, no ad-hoc joins |
| Other shapes of data | Extensions: vectors, maps, time series, graphs, ranked search | Tables, totals and ranked text search today. Vector, graph and time-series modes are built and not yet released |
| How you run it | A server you operate, or a managed service from any cloud | Inside Mandala’s one program. Nothing separate to run, and no managed offering |
| Around it | Drivers for every language, ORMs, migration tools, BI, backup and monitoring tools, people who know it | Mandala’s own API and tools. A small world |
| Track record | About thirty years in production at every scale | Young. In daily production use, at small scale |
Said plainly.
An analyst with SQL can ask a database anything. In Karma a question must be declared before it can be asked. That makes answers fast and checkable, and exploration slower.
ORMs, BI tools, managed hosting, point-in-time recovery tooling, consultants. None of that exists for Karma.
Karma’s engine measures well on one machine, and those are engine numbers, not years of production at scale. PostgreSQL and MySQL have the years.
Today Karma comes with Mandala. You can’t point your own application at it the way you point it at Postgres. That will change: Karma on its own, with contracts as its schema, is planned.
{ "at_ms": 1791983040000, "tenant": "planet-express", "namespace": "com.planetexpress.delivery", "subject": "delivery-lumon-0412", "id": "9f3c2a71…e81d", "version": 1, "assertion": "b41e07d9…3a6c", "actor": "mira", "action": "Request", "args": { "customer": "Lumon Industries", "destination": "Moon", "units": 120, "crates": 2, "credit_terms": false }}
The real shape, with the cast’s values. actor is whose signature it carries, here Mira’s own; assertion is the signed fact it receipts; version counts the record’s facts.
Other shapes, declared like the rest.
Where Postgres reaches vectors and graphs through extensions, Karma’s way is the contract: it declares the index, and a query may only use what was declared. Exact indexes can take part in a decision. Approximate ones are for reading.
This is working on a development branch and is not in any release. The syntax is the one that branch implements and may still change.
aggregate Partner state public name: Text(len=100) public active: Bool = true public notes_embedding: Vector(dims=1024) index vector(notes_embedding) cosine query Nearest(qv: Vector(dims=1024), k: Int) dhlq com.planetexpress.partner | where active == true | vsearch notes_embedding $qv top $k | select subject as id, name aggregate Base state public name: Text(len=100) public open: Bool = true public lanes: List<SubjectRef<Base>>(capacity=8) index graph(lanes) query Reach(start: Identity, d: Int) dhlq com.planetexpress.base | where open == true | traverse lanes from $start depth $d direction both | select subject as id, name, depth
Excerpts from the examples in Karma’s design document, which uses a delivery company: partners nearest in meaning to a query, and bases within a number of hops. Not yet available in a release.
Choose honestly.
Choose PostgreSQL or MySQL if…
- You are building your own application, with your own schema and code.
- You need SQL, ad-hoc analysis, or BI tools.
- You need proven scale, replicas, managed hosting, or software that expects a SQL database.
- Your team already knows it. That counts for a lot.
Choose Mandala if…
- The history matters as much as the state: who did what, for whom, under which rule.
- You want the rules enforced at the data, for every caller, people and AI alike.
- You want the whole thing, storage included, in one program on one small machine.
- You want an application, not a database to build one on.
If history is the need but you want a standalone database, look at XTDB, Datomic, KurrentDB or Dolt before you look at us. How Karma works · Nothing is ever lost
We checked every statement about other products on 12 October 2026, against their own sites, documentation and repositories where we could. Products change. If something here is wrong or out of date, write to hello@getmandala.org and we’ll correct it.