Namespaces y multi-tenancy

Un namespace es la unidad fundamental de aislamiento en NamiDB. Cada URI lleva un parámetro de query ?ns=… que lo nombra.

client_a = tg.Client("s3://my-bucket?ns=tenant-acme")
client_b = tg.Client("s3://my-bucket?ns=tenant-globex")

Estos dos clientes no comparten nada a nivel del motor — distintos manifests, distintos SSTs, distintos WALs, distinto schema. Lo único que comparten es tu prefix de bucket.

Qué vive en un namespace

Schema — labels, tipos de propiedades, índices
Datos — cada nodo, arista, propiedad, vector
WAL — segmentos de log append-only
SSTs — archivos columnares inmutables (Parquet para nodos, custom para aristas)
Manifest — el CAS root que nombra todo lo que está actualmente vivo
Epoch — un contador de fencing para hacer cumplir el single-writer

Un solo writer por namespace

Cada namespace tiene un writer activo por vez, fenceado por CAS de epoch. Si dos procesos intentan mutar el mismo namespace, solo uno commitea — el que pierde ve un 412 Precondition Failed en el PUT del manifest, vuelve a leer, y reintenta o hace backoff.

Esto es lo que da correctness sin un tier de consenso. También es por eso que “más throughput de escritura” significa “más namespaces”, no “más writers por namespace”.

Multi-tenancy es namespacing

El modelo canónico de tenancy de NamiDB:

s3://my-bucket/data/
├── tenant-acme/         ← un namespace
├── tenant-globex/       ← otro
└── tenant-initech/      ← otro

Cada tenant:

Tiene su propio manifest, WAL, SSTs
Puede ser backupeado, restaurado, eliminado como un único prefix de S3
Escala a cero independientemente
Está fenceado de cualquier otro tenant

Este es el mismo patrón que funcionó para turbopuffer (vectores) y para otros sistemas object-storage-native.

Cuándo crear un namespace nuevo

Nuevo tenant — siempre.
Nuevo entorno (dev / staging / prod) — generalmente.
Divergencia de schema — cuando dos partes de tu app tienen grafos no relacionados.
Se necesitan backups independientes — los namespaces se backupean limpio con aws s3 sync.

Cuándo NO hacerlo

“Quiero más throughput de escritura en este único workload.” Shardear escrituras entre varios namespaces solo ayuda si tus queries también entran dentro de un shard. Los joins cross-namespace no existen en NamiDB.