Skip to content
NamiDB NamiDB

Cloud vs self-hosted

NamiDB is the same engine whether you run it yourself or consume the managed Cloud. The decision is operational, not technical.

Pick Cloud when…

  • You want zero operational work — no daemons, no buckets, no flush schedules, no Docker images to chase.
  • You have many tenants that need isolated graphs.
  • You want per-namespace scale-to-zero so you only pay when active.
  • You’d rather call hello@namidb.com when something breaks than page yourself.

Pick self-hosted when…

  • You have a strong data-residency requirement — your bucket has to live in your account, in a specific region.
  • You’re already running heavy infrastructure and prefer one more service over one more vendor.
  • You want deep control over caches, flush cadence, compaction thresholds, and observability tooling.
  • Your workload is single-tenant with predictable cost — the self-host overhead is small and Cloud’s per-tenant pricing isn’t a fit.
  • You’re air-gapped or have a regulator that doesn’t accept SaaS.

You can switch later

The bucket layout is identical. To migrate self-hosted → Cloud, we provide a one-time aws s3 sync recipe + DNS/URI cutover. To migrate Cloud → self-hosted, we provide the same in reverse. No lock-in.

Hybrid is fine too

A common pattern:

  • Cloud for the production multi-tenant SaaS that needs isolated graphs per customer.
  • Self-hosted namidb-server for the internal data team’s ad-hoc analytics, pointing at the same bucket layout in a read-only mirror.

Same engine. Same Cypher. Same client SDKs.

See also