The database your agents can’t outgrow.
Describe your data, and who’s allowed to see it, in one schema. Napalm runs it on as many machines as you need, with the same rules for every person and every agent.
Your schema is the backend.
Types, links, constraints and computed fields all live in one file. Ask for the exact shape you want, nested as deep as you like, and it comes back in one round trip.
Change the schema and Napalm writes the migration.
type User { required name: str;} type Workspace { required name: str; multi members: User;} type Doc { required title: str; required workspace: Workspace; author: User; content: str;}select Doc { title, author: { name }, workspace: { name },}filter .workspace.name = 'Harbor'order by .titlelimit 2;[ { "title": "Launch checklist", "author": { "name": "Maya" }, "workspace": { "name": "Harbor" } }, { "title": "Pricing notes", "author": { "name": "Sam" }, "workspace": { "name": "Harbor" } }]Every query knows who’s asking.
Write who can read and change each type right in the schema. Napalm applies those rules to every query, whoever writes it, including an agent acting for one of your users.
Sign-in is built in too. Passkeys, email, and Google, Apple or GitHub accounts work out of the box.
global current_user_id: uuid;global current_user := ( select User filter .id = global current_user_id); type Doc { required workspace: Workspace; author: User; access policy members_can_read allow select using (global current_user in .workspace.members); access policy authors_can_edit allow update, delete using (.author ?= global current_user);}Gold from your app, white from an agent. A request the rules don’t allow stops at the worker.
Fast, even with every rule on.
Napalm compiles each access rule into its own small program and works out who’s asking once per request. A query full of policies plans like a simple one, instead of carrying a copy of every rule it touches.
Your rules stay exactly as strict as you wrote them.
Add machines, not rewrites.
Napalm grows underneath your schema. Your queries and your rules don’t change as it does.
More query workers
Workers compile and run queries behind one endpoint. When traffic climbs, add workers and the endpoint spreads requests across them.
Reads on replicas
Read-only queries run on Postgres replicas, with every access rule still applied. Writes and transactions stay on the primary.
Storage that splits itself
As your data grows, Napalm spreads it across partitions. It works out what belongs together from the schema, so there’s no shard key to choose.
Rebalanced while it runs
Partitions move between machines while queries keep running. Each move copies, catches up, then cuts over in a moment.
A network of your own
Every tenant gets its own private network and its own machines, so another team’s busy night never reaches yours.
White is an agent’s search, through the vector index to the docs it matched. A doc it isn’t allowed to read stops at the gate.
Give agents your data, safely.
Embeddings are an index in your schema, kept current as the text changes. Search by meaning and join the matches to anything else you store.
Agents read your schema to learn what your data means, then ask for exactly the shape they need. Each one runs under the rules of the person it works for. When agents multiply your traffic, the rules stay cheap and Napalm adds the machines.
type Doc { required title: str; required content: str; deferred index ext::ai::index( embedding_model := 'text-embedding-3-small' ) on (.content);} with hits := ext::ai::search(Doc, <str>$question)select hits.object { title, author: { name } }order by hits.distancelimit 5;Think in types. We’ll run the machines.
Napalm is a service. You bring the schema and we take care of everything under it.
- Branches
- Give every environment and every feature its own copy of the database, then merge the schema when it’s ready.
- Migrations
- Edit the schema and Napalm writes the migration.
- Backups
- Taken on a schedule, and restored in place when you need one.
- Upgrades
- New versions roll out under you. Nothing to schedule.
- Watching
- Memory, slow queries and replica lag are watched all the time, so trouble gets caught while it’s small.
- Your clients
- It speaks the same HTTP and binary protocols your clients already use.