Saltearse al contenido
NamiDB NamiDB

Qué es NamiDB

NamiDB es un motor de base de datos en grafo construido desde los primeros principios para la era del object storage, la ejecución columnar y los agentes de IA.

Es embebido como DuckDB, multi-tenant por namespace, y corre el mismo motor sin importar si lo importas como librería, lo ejecutas como daemon o lo consumes en nuestro cloud manejado. El object storage es la fuente de verdad.

Por qué ahora

Cambiaron tres cosas. Cambiaron todo.

  1. El object storage maduró. En 2024, S3 sumó conditional writes (If-Match / If-None-Match) — la última primitiva que faltaba. Por primera vez se puede construir un sistema coordinado y durable donde el object storage es la base de datos — sin Raft, sin ZooKeeper, sin etcd.
  2. El mejor motor de grafos columnar dejó el mercado. En octubre de 2025, Apple adquirió Kùzu y archivó el repositorio. El motor de grafos columnar más pensado que se había publicado quedó en silencio. Se abrió un hueco.
  3. Los agentes necesitan grafos. La búsqueda vectorial es necesaria. No es suficiente. Los knowledge graphs son el sustrato de la memoria de los agentes, la recuperación profunda y el razonamiento bajo incertidumbre. La próxima década de IA va a correr sobre relaciones.

Por eso estamos construyendo la base de datos para esa década.

NamiDB es abierto bajo BSL 1.1 (convierte a Apache 2.0 a los tres años por release). El motor es abierto; el cloud es el negocio — un producto multi-tenant hosteado en namidb.com es el modelo de financiamiento que mantiene el motor en movimiento.

La forma

NamiDB escribe Cypher a tu bucket de S3.

Sin control plane que aprovisionar. Sin Raft que tunear. Sin etcd que cuidar. Los conditional writes (If-Match / If-None-Match) sobre object storage reemplazan la capa de consenso — el bucket mismo es la fuente de verdad.

Tu base de datos en grafo es solo archivos en tu bucket:

  • La durabilidad es la que ya te dan S3, R2, GCS o Azure
  • El costo escala a cero cuando nadie hace queries
  • Los backups son aws s3 sync
  • Los tenants son carpetas

El motor es el mismo si lo corres como librería, como daemon de Rust sobre HTTP o sobre nuestro cloud multi-tenant manejado — y funciona igual de bien contra AWS S3, Cloudflare R2, GCS, Azure Blob, MinIO o tu disco local.

Tres despliegues, un motor

Embebido

pip install namidb. El modo “DuckDB para grafos” — tu aplicación importa la librería y habla directamente con un bucket. La latencia más baja, sin saltos de red, sin red de por medio, sin superficie de auth.

Servidor

namidb-server abre un namespace y lo expone por HTTP con auth por bearer token. Justo para cuando la DB vive en una máquina distinta a la app, o cuando quieres un boundary de red.

Cloud

SaaS multi-tenant manejado en namidb.com con scale-to-zero por namespace, tenants cifrados en reposo y un control plane manejado. Beta cerrada — solicitar acceso.

Las tres hablan el mismo Cypher, devuelven los mismos tipos y escriben al mismo layout de bucket. Puedes arrancar un notebook embebido contra el mismo URI s3://… que está sirviendo un daemon en producción.

Qué hay en el motor hoy

  • Parseo de Cypher + GQL — subset estricto de GQL (ISO/IEC 39075:2024) + openCypher 9. Las 12 queries en scope de LDBC SNB Interactive Complex Read (IC01–IC12) parsean, planifican y ejecutan de punta a punta.
  • Escrituras vía Cypher — CREATE, MERGE, SET, DELETE, DETACH DELETE, REMOVE. Durables al commit_batch (append al WAL
    • CAS del manifest).
  • Optimizador basado en costos — predicate pushdown, projection pushdown, reordenamiento de joins, conversión a hash-join, hash semi-join (decorrelación de EXISTS), pruning de row-groups de Parquet. EXPLAIN VERBOSE imprime el plan elegido con anotaciones de selectividad y costo.
  • Ejecución vectorizada — ejecutor morsel-driven con representación intermedia factorizada opcional (RFC-017) para queries cargadas de paths.
  • Almacenamiento columnar sobre object storage — SSTs de nodos en Parquet, formato custom de edge-SST con CSR adjacency (RFC-002), compresión zstd, bloom filters, índices fence-pointer.
  • Corrección sin coordinación — single-writer-per-namespace con epoch fencing vía CAS del manifest.
  • Caches tiered — AdjacencyCache, NodeViewCache y SstCache a nivel de proceso. Reuso entre snapshots con memoria compartida vía Arc y presupuestada en bytes.
  • Seis backends de almacenamiento — memory://, file://, s3://, gs://, az:// y cualquier endpoint compatible con S3 (R2, MinIO, Tigris, LocalStack).
  • Bindings de Python, CLI y daemon HTTP namidb-server.

A dónde seguir

Una probada en 30 segundos

Inicio rápido — seis líneas de Python, sin credenciales.

Tu grafo en S3

Tu grafo en S3 — apunta a un bucket de AWS. Reinicia el proceso. El grafo sigue ahí.

Elegir un despliegue

Elegir un despliegue — Embebido vs Servidor vs Cloud, con matriz de decisión.

Deep dive

Los RFCs — 17 documentos de diseño que cubren el storage engine, formato SST, optimizador, factorización, caches.