Three deployments, one engine
NamiDB ships one engine in three shapes. They all converge on a single S3-compatible bucket as the source of truth.
┌──────────────┐ ┌──────────────┐ ┌──────────────┐│ Embedded │ │ Server │ │ Cloud ││ (Python / │ │ (REST API │ │ (managed ││ Rust lib) │ │ daemon) │ │ multi- ││ │ │ │ │ tenant) │└──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │ │ └─────────────────┴─────────────────┘ │ ▼ ┌──────────────────────┐ │ Object storage │ │ (S3 / R2 / GCS / │ │ Azure / local FS) │ └──────────────────────┘What’s shared
- The Cypher / GQL parser — identical query language across all three deployments.
- The cost-based optimizer — same plan rewrites, same selectivity
estimates, same
EXPLAIN VERBOSEoutput. - The vectorized executor — morsel-driven, optionally factorized.
- The storage format — SST layout, manifest schema, WAL framing are identical across deployments.
- The bucket layout — Embedded and Server write to the same paths.
You can boot an embedded notebook against the same
s3://…URI a production daemon is serving.
What differs
| Aspect | Embedded | Server | Cloud |
|---|---|---|---|
| Transport | In-process function calls | HTTP REST (/v0/cypher) | HTTP REST + per-tenant routing |
| Auth | None (in-process) | Bearer token | API keys + IAM |
| Concurrency | 1 writer per process, many readers | 1 writer per daemon, many readers | Managed |
| Failure domain | Your process | The daemon | Managed cell |
| Scale-to-zero | Trivial (stop your app) | Stop the daemon | Built-in, per-namespace |
| Ops surface | None | Docker / systemd / k8s | None (managed) |
Why this matters
- You don’t have to choose early. Start embedded, migrate to a daemon when you need a network boundary. Same code path, same data.
- You can mix them: a long-lived
namidb-serverfor ad-hoc query work, an embedded library in your hot service. - Cloud is opt-in. The engine is open and self-hostable forever.