Elegir un despliegue

NamiDB entrega un motor en tres formas. Escriben al mismo layout de bucket, así que se pueden mezclar.

TL;DR

Si estás…	Usa
armando un notebook, un servicio de un solo proceso o un fixture de CI	Embebido
buscando un boundary de red con auth por bearer token entre app y DB	Servidor
buscando zero-ops, scale-to-zero por namespace, multi-tenant por default	Cloud

Las tres formas

Embebido

Tu aplicación importa NamiDB directamente y apunta a un bucket que tú controlas. El modo “DuckDB para grafos”.

Latencia mínima, sin overhead de red
Funciona en Python (pip install namidb) y Rust
Dos réplicas de tu servicio pueden abrir el mismo namespace de forma independiente — el CAS por epoch fenceará a los writers viejos automáticamente
Sin superficie nueva de auth que cablear

Servidor

namidb-server abre un namespace y lo expone por HTTP.

Un binario Rust, una imagen Docker
Auth por bearer token (--auth-token)
Loop periódico de flush memtable → L0
Justo para cuando la DB y la app viven en máquinas distintas
Endpoints REST: /v0/cypher, /v0/health, /v0/admin/flush

Cloud

SaaS multi-tenant manejado en namidb.com.

Scale-to-zero por namespace
Tenants cifrados en reposo
Control plane manejado, equipo de NamiDB on-call
Beta cerrada — solicitar acceso

Matriz de decisión

Dimensión	Embebido	Servidor	Cloud
Esfuerzo de setup	Pip install	Imagen Docker + bucket	Registrarse
Latencia	Mínima (in-process)	+ 1 salto de red	+ 1 salto, manejado
Writers concurrentes	1 / namespace (tu proceso)	1 / namespace (el daemon)	1 / namespace (manejado)
Lectores concurrentes	Muchos	Muchos (1 mutex hoy, RFC-021 para fan-out completo)	Muchos
Modelo de auth	Ninguno (in-process)	Bearer token	API keys + IAM
Almacenamiento	Cualquier URI tuyo	Cualquier URI tuyo	Bucket manejado
Multi-tenant	Sí (un namespace por tenant)	Sí (un daemon por tenant)	First-class
Modelo de pago	Almacenamiento + tu compute	Almacenamiento + tu compute	Medición por namespace
¿Self-host?	Sí	Sí	No

Preguntas que hacerse

¿Dónde vive el dato y quién más lo necesita? Si solo tu único servicio Python lee o escribe alguna vez, Embebido es la opción de menor fricción. Si varios servicios necesitan el mismo namespace y quieres un endpoint autoritativo, Servidor te da ese boundary de red.
¿El fan-out de lectura es tu cuello de botella hoy? namidb-server serializa las solicitudes hoy detrás de un Mutex de tokio (RFC-021 lo elimina). Si necesitas escala horizontal de lectura ahora, corre varios procesos de namidb-server contra el mismo bucket — cada uno puede servir lecturas desde la misma versión de manifest. Solo uno tendrá permiso de commitear escrituras.
¿Quieres operar infraestructura? Cloud es la respuesta correcta cuando la respuesta es “no”. Multi-tenant desde el día uno, scale-to-zero, sin horarios de flush que tunear, sin imágenes Docker que actualizar.
¿Los tenants son first-class en tu app? Embebido y Servidor te dejan hacer “un namespace por tenant” de forma manual. Cloud lo convierte en la unidad de facturación, aislamiento y scale-to-zero.

Se pueden mezclar

Mismo motor, mismo layout de bucket, mismo URI s3://….

Un patrón común:

Embebido en tu aplicación para el hot path de lectura.
Un namidb-server en la misma VPC para analítica ad-hoc desde un notebook o desde la laptop de un compañero, ambos apuntando al mismo namespace.

namidb-server va a fencear al writer embebido si intenta mutar al mismo tiempo — el single-writer-per-namespace se aplica vía CAS del manifest, sin importar por dónde llegó el writer.