NamiDB
Manifesto

The graph is the shapeof how things relate.

We're giving it a database worthy of the decade ahead.

Fonles Studios · v1 · 2026-05-17

I — What the world is made of

Everything we care about is a relationship.

A user is a person and the things they did. A document is a sentence and what it points to. A company is people and the agreements between them. A medical record is an event and the bodies it touched.

We do not usually store the world this way. We store the things in tables and the relationships in joins, and we pay for the joins forever. We tell ourselves it is the same thing. It is not the same thing.

II — Why the database for that world has not been built

The substrate finally caught up to graphs.

Graph databases existed before the cloud. They were built to live on a single beefy box, with data in RAM, with replication grafted on later. They were priced as if RAM was the universe.

The cloud, meanwhile, learned to keep its truth in object storage. Cheap. Durable. Multi-tenant by default. Every other category — analytics, vectors, queues — eventually moved its primary state there. Graphs did not. Until S3 quietly shipped conditional writes in 2024, they could not. After it shipped, they finally could.

And then the most thoughtful graph engine ever written — Kùzu — got acquired into a vault and went quiet. The bench moved. The category opened.

III — What we are building

One engine. Object storage underneath. AI on top.

A graph database that runs embedded like DuckDB, as a server like Memgraph, and cloud-native like turbopuffer — from the same Rust core. The state lives in object storage. The compute is yours to size. The query languages are Cypher and GQL, the two standards. The retrieval is hybrid — vector and graph in one engine, not two.

We are building it because the next decade will run on relationships. Knowledge graphs are the substrate of agent memory. GraphRAG is how retrieval becomes reasoning. The models will keep getting better. The substrate underneath has to catch up — and someone has to build it.

IV — How we are building it

In writing. In public. Under our names.

Every decision lives in an RFC before the code exists. Every benchmark is published with its dataset, its scale, its hardware, and its raw runs — including the ones that don't go our way. Every dependency is permissively licensed. The engine is source-available from day one under BSL 1.1, and each release converts to Apache 2.0 three years later. A commercial license is available for teams that redistribute it as a managed service or embed it in closed-source products.

We are not the only group that could build this. We are the group that has decided to try. The day we publish a number without its caveat is the day we forfeit the right to claim we work in the open. The team understands this. The team will hold itself to it.

V — What we owe you

Honest dates. Honest numbers. Honest postmortems.

We will not promise dates we cannot keep. We will not publish a metric whose context is more than one click away. We will not pretend a benchmark won on one query is a benchmark won on the suite. We will not call ourselves revolutionary — we will let you decide that, with the receipts.

When we slip, you will see it. When we are wrong, you will see why. When the engine misbehaves in production, the postmortem will land within seven days — including the ones that embarrass us. That is the floor. We will try to stay well above it.

Matías Fonseca
Founder, NamiDB — Fonles Studios, Corp.

Build the next decade with us.

Early-access is open. One launch email when the engine is ready — never spam.