Cloud vs self-hosted
NamiDB es el mismo motor ya sea que se corra in-house o se consuma el Cloud manejado. La decisión es operativa, no técnica.
Cuándo conviene elegir Cloud
- Se busca cero trabajo operativo — sin daemons, sin buckets, sin schedules de flush, sin imágenes de Docker que perseguir.
- Hay muchos tenants que necesitan grafos aislados.
- Se quiere scale-to-zero por namespace para pagar sólo cuando hay actividad.
- Es preferible escribir a hello@namidb.com cuando algo se rompe antes que estar de on-call.
Cuándo conviene elegir self-hosted
- Hay un requerimiento fuerte de residencia de datos — el bucket tiene que vivir en la cuenta del equipo, en una región específica.
- El equipo ya opera infraestructura pesada y prefiere un servicio más antes que un vendor más.
- Se quiere control profundo sobre los caches, la cadencia de flush, los umbrales de compaction y las herramientas de observabilidad.
- El workload es single-tenant con costo predecible — el overhead de self-host es chico y el pricing per-tenant de Cloud no encaja.
- El entorno es air-gapped o hay un regulador que no acepta SaaS.
Se puede cambiar después
El layout del bucket es idéntico. Para migrar self-hosted → Cloud,
proveemos una receta aws s3 sync one-time + cutover de DNS/URI. Para
migrar Cloud → self-hosted, proveemos lo mismo a la inversa. Sin
lock-in.
El híbrido también está bien
Un patrón común:
- Cloud para el SaaS multi-tenant de producción que necesita grafos aislados por cliente.
namidb-serverself-hosted para los análisis ad-hoc del equipo interno de datos, apuntando al mismo layout de bucket en un mirror read-only.
Mismo motor. Mismo Cypher. Mismos SDKs de cliente.