Saltearse al contenido

Tres despliegues, un motor

NamiDB distribuye un solo motor en tres formas. Las tres convergen en un único bucket compatible con S3 como fuente de verdad.

┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Embedded │ │ Server │ │ Cloud │
│ (Python / │ │ (REST API │ │ (managed │
│ Rust lib) │ │ daemon) │ │ multi- │
│ │ │ │ │ tenant) │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
└─────────────────┴─────────────────┘
┌──────────────────────┐
│ Object storage │
│ (S3 / R2 / GCS / │
│ Azure / local FS) │
└──────────────────────┘

Qué se comparte

  • El parser de Cypher / GQL — lenguaje de queries idéntico en los tres despliegues.
  • El optimizador basado en costos — mismas reescrituras de plan, mismas estimaciones de selectividad, misma salida de EXPLAIN VERBOSE.
  • El ejecutor vectorizado — morsel-driven, opcionalmente factorizado.
  • El formato de almacenamiento — layout de SST, schema del manifest y framing del WAL son idénticos entre despliegues.
  • El layout del bucket — Embedded y Server escriben a los mismos paths. Se puede arrancar un notebook embebido contra el mismo URI s3://… que está sirviendo un daemon de producción.

Qué difiere

AspectoEmbeddedServerCloud
TransporteLlamadas a función in-processHTTP REST (/v0/cypher)HTTP REST + routing por tenant
AuthNinguna (in-process)Bearer tokenAPI keys + IAM
Concurrencia1 writer por proceso, muchos readers1 writer por daemon, muchos readersManejada
Dominio de fallaTu procesoEl daemonCelda manejada
Scale-to-zeroTrivial (frenar la app)Frenar el daemonBuilt-in, por namespace
Superficie de opsNingunaDocker / systemd / k8sNinguna (manejada)

Por qué importa esto

  • No hace falta elegir temprano. Empezar embebido y migrar a un daemon cuando se necesite un boundary de red. Mismo code path, mismos datos.
  • Se pueden mezclar: un namidb-server long-lived para trabajo de query ad-hoc, una librería embebida en el servicio caliente.
  • Cloud es opt-in. El motor es abierto y auto-hospedable para siempre.

Ver también