Choose a deployment

NamiDB ships one engine in three shapes. They write to the same bucket layout, so you can mix and match.

TL;DR

If you…	Use
are building a notebook, a single-process service, or a CI fixture	Embedded
want a network boundary with bearer-token auth between app and DB	Server
want zero-ops, per-namespace scale-to-zero, multi-tenant by default	Cloud

The three shapes

Embedded

Your application imports NamiDB directly and points at a bucket you control. The “DuckDB for graphs” mode.

Lowest latency, zero network overhead
Works in Python (pip install namidb) and Rust
Two replicas of your service can independently open the same namespace — epoch-CAS fences out stale writers automatically
No new auth surface to wire

Server

namidb-server opens a namespace and exposes it over HTTP.

One Rust binary, one Docker image
Bearer-token auth (--auth-token)
Periodic memtable → L0 flush loop
Right when DB and app live on different machines
REST endpoints: /v0/cypher, /v0/health, /v0/admin/flush

Cloud

Hosted multi-tenant SaaS on namidb.com.

Per-namespace scale-to-zero
Encrypted-at-rest tenants
Managed control plane, NamiDB team on-call
Closed beta — request access

Decision matrix

Dimension	Embedded	Server	Cloud
Setup effort	Pip install	Docker image + bucket	Sign up
Latency	Lowest (in-process)	+ 1 network hop	+ 1 hop, managed
Concurrent writers	1 / namespace (your process)	1 / namespace (the daemon)	1 / namespace (managed)
Concurrent readers	Many	Many (1 mutex today, RFC-021 for full fan-out)	Many
Auth model	None (in-process)	Bearer token	API keys + IAM
Storage	Any URI you own	Any URI you own	Managed bucket
Multi-tenant	Yes (one namespace per tenant)	Yes (one daemon per tenant)	First-class
Pay model	Storage + your compute	Storage + your compute	Per-namespace metering
Self-host?	Yes	Yes	No

Questions to ask yourself

Where does the data live, and who else needs it? If only your single Python service ever reads or writes, Embedded is the lowest-friction call. If multiple services need the same namespace and you want one authoritative endpoint, Server gives you that network boundary.
Is read fan-out your bottleneck today? namidb-server serialises requests behind a tokio Mutex today (RFC-021 removes that). If you need horizontal read scale right now, run multiple namidb-server processes against the same bucket — each can serve reads off the same manifest version. Only one will be allowed to commit writes.
Do you want to operate any infrastructure? Cloud is the right answer when the answer is “no”. Multi-tenant from day one, scale-to-zero, no flush schedules to tune, no Docker images to bump.
Are tenants first-class in your app? Embedded and Server both let you do “one namespace per tenant” manually. Cloud makes it the unit of billing, isolation, and scale-to-zero.

You can mix them

Same engine, same bucket layout, same s3://… URI.

A common pattern:

Embedded in your application for the hot read path.
A namidb-server in the same VPC for ad-hoc analytics from a notebook or a teammate’s laptop, both pointing at the same namespace.

namidb-server will fence the embedded writer if it tries to mutate at the same time — single-writer-per-namespace is enforced via manifest CAS, regardless of how the writer was reached.