Transacciones ACID con fsync real. Búsqueda full-text en <1ms. Analítica sobre millones de registros. Búsqueda vectorial con HNSW para IA/RAG. Audit log inmutable. Recuperación ante desastres con WAL. Un solo binario. Una sola fuente de verdad.
$ ./neodb --data-dir ./data SLM NeoDB SLMTR1 starting... Engine: SLMTR1 | Status: READY Listening on 127.0.0.1:7700 $ curl -X POST :7700/banco/user/1 \ -d '{"nombre":"Luis","saldo":1500.25}' 201 Created — 8ms, fsync'd $ curl :7700/banco/user/_search \ -d '{"query":{"match":{"nombre":"luis"}}}' 200 OK — <1ms, 1 result
NeoDB es la primera base de datos que unifica datos transaccionales, búsqueda full-text, analytics en tiempo real, y RAG/AI en un solo motor. Sin sincronizar PostgreSQL con Elasticsearch con Pinecone. Un binario. Una fuente de verdad. ACID real.
Tiene vectores pero búsqueda de texto lenta y sin aggregations rápidas.
Tiene búsqueda pero no tiene ACID ni vectores nativos eficientes.
Solo vectores. No son bases de datos transaccionales.
Todo en uno. ACID + búsqueda + analytics + vectores.
Otras bases de datos te obligan a elegir entre 8+ tipos numéricos. Elige mal y pierdes dinero. NeoDB tiene UN solo tipo.
8+ tipos numéricos: NUMBER, DECIMAL, FLOAT, DOUBLE PRECISION, REAL, BIGINT, SMALLINT, NUMERIC. Elige el incorrecto y pierdes centavos. En millones de transacciones, pierdes miles.
Usa IEEE 754 double. 0.1 + 0.2 = 0.30000000000000004. Inaceptable para dinero. Inaceptable para auditoría. Inaceptable.
UN tipo: number[n]. n = decimales. Precisión exacta. NUNCA redondea. Si envías decimales de más, rechaza con error.
// Elasticsearch (IEEE 754 double) 0.1 + 0.2 = 0.30000000000000004 <-- WRONG // NeoDB (number[2]) 0.1 + 0.2 = 0.30 <-- EXACT. Always.
number[0] = entero. number[2] = dinero. number[8] = crypto. Un tipo. Cero errores.
El developer describe QUÉ es su dato. El motor decide CÓMO almacenarlo, indexarlo y buscarlo.
NeoDB es como un mapa mental para tus datos. No necesitas diseñar todo desde el principio. Empieza a guardar, descubre lo que necesitas, y crece progresivamente.
Sin schema. Manda JSON y NeoDB lo acepta. No necesitas saber la estructura final.
Haz queries, busca por texto, filtra. Los datos te dicen qué estructura necesitas.
Define tipos, validaciones, strict mode. En caliente. Sin downtime. Sin migrar datos.
Agrega campos, crea nuevos tipos, nuevos índices. Los datos existentes no se tocan.
En SQL, diseñas tablas antes de escribir la primera línea de código. En NeoDB, escribes código desde el minuto uno y el schema evoluciona contigo. Es la base de datos para equipos que construyen productos, no para equipos que diseñan schemas.
360 tests · 0 warnings · 21K docs/sec · <1ms search · 27MB binary
No es un plugin. No es un add-on. Está en el motor.
Tu DBA no puede filtrar un PAN porque fisicamente nunca toca el disco. El motor lo hashea con BLAKE3 antes de almacenarlo. El valor original se descarta en RAM. Para siempre.
Una API key robada es inútil fuera del rango de IP autorizado. Silent drop — el atacante ni siquiera recibe un mensaje de error.
El equipo de reportes ve transacciones pero nunca ve números de tarjeta. Field masking por key, aplicado a nivel del motor.
Cada operación. Cada key. Cada IP. Inmutable. PCI DSS REQ 10 compliant de fábrica.
Los requests inválidos reciben TCP close. Sin respuesta HTTP. Sin código de error. Sin fuga de información. El atacante no sabe en qué paso falló.
BLAKE3 de 256 bits — 128 bits de seguridad post-quantum. Los datos hasheados con blind (PANs, identificaciones, datos sensibles) permanecen protegidos incluso contra computadoras cuánticas futuras. Impracticable con tecnología actual o futura previsible.
Disaster recovery y compliance en un solo flujo. Los backups son NDJSON auditable — texto plano, una línea por documento, verificable con wc/grep/diff. Los campos blind exportan solo el hash BLAKE3 — el valor original nunca sale del servidor. Import a ~22K docs/seg para RPO/RTO medibles.
Cada operación queda en un ledger inmutable con timestamp, identidad y evidencia criptográfica. Sin nodos, sin gas, sin consenso distribuido.
Soft deletes. Cada versión de cada documento queda en el historial. Un auditor puede reconstruir el estado de cualquier dato en cualquier momento del pasado.
Cada operación registrada con: quién (key_id), cuándo (timestamp), desde dónde (IP), qué hizo (acción), resultado (ALLOWED/DENIED), duración. Append-only. Nadie puede modificarlo.
BLAKE3 de 256 bits (quantum-resistant). Cada hash es prueba matemática de integridad. IDs con UUID v7 cronológico — orden garantizado por el protocolo, no por un reloj.
Nodos, consenso distribuido, gas fees, latencia de confirmación, throughput limitado, complejidad operativa extrema.
Un binario, fsync inmediato, 21K escrituras/segundo, audit log inmutable, hashing quantum-resistant, zero complejidad operativa. Misma inmutabilidad. Sin el overhead.
Consistencia o búsqueda. ACID o velocidad. Y luego pegarlos con cinta. NeoDB elimina esa elección.
✓ ACID
✗ Búsqueda lenta
✗ Sin analytics rápido
✓ Búsqueda rápida
✗ Sin ACID
✗ Consistencia eventual
✗ Dos sistemas
✗ Sincronización rota
✗ ¿Cuál es la verdad?
✓ ACID
✓ Búsqueda <1ms
✓ Una fuente de verdad
1.1 millones de documentos. 5 módulos de negocio. Hardware estándar.
Sin JVM. Sin cluster. Sin tuning de shards. Sin replica sets. Sin heap sizing. Sin GC tuning. Descarga, ejecuta, funciona.
No es solo un cliente IoT. Es la base de datos completa corriendo EN el dispositivo. ACID, búsqueda full-text, aggregations, vectores — todo en 27MB de binario y 128MB de RAM.
~500MB binarios. ~4GB RAM mínima. JVM. Imposible en Raspberry Pi 3. Costoso en Pi 4.
~200MB binario. ~1GB RAM mínima. Sin full-text serio. Sin ACID multi-doc.
27MB binario. 128MB RAM. Sin JVM, sin GC. Corre en Pi 3, Pi Zero 2, OpenWrt routers, ARM industriales.
Sin JVM (Elasticsearch), sin V8 (Node), sin Python interpreter. El binario es código máquina compilado para ARM o x86. Footprint mínimo.
Memoria gestionada por ownership. Sin pausas GC, sin pico de RAM por compactación. Latencia predecible incluso con 128MB.
Un archivo ejecutable. Sin libc dinámica obligatoria, sin packages, sin systemd, sin Docker. scp neodb pi@host && ./neodb. Listo.
El motor de storage es el mismo que usa Facebook en producción para petabytes. Pero compilado dentro del binario, no como servicio separado. Cero overhead de IPC.
Raspberry Pi en una fábrica recibiendo telemetría de 100 sensores. Almacena local con ACID. Sincroniza al cloud cuando hay red.
POS en una bodega sin internet estable. NeoDB local guarda ventas con ACID. Búsqueda de productos en <1ms. Sincroniza después.
Monitor de paciente en hospital rural. NeoDB embedded guarda mediciones con audit log inmutable. PCI/HIPAA-ready sin nube.
Vector search nativo en el edge. Embeddings + KNN en la misma Raspberry. Sin enviar datos sensibles a servidores externos.
# Compilar para ARM cargo build --release --target=aarch64-unknown-linux-gnu # Copiar binario (27MB) al dispositivo scp target/aarch64-unknown-linux-gnu/release/neodb pi@192.168.1.42:~/ # Arrancar — sin instalación, sin servicios, sin Docker ssh pi@192.168.1.42 './neodb --data-dir ./data --bind 0.0.0.0:7700' # Ya tienes base de datos completa en el edge: # - ACID con fsync # - Full-text search <1ms # - Aggregations # - Vector search # - REST + JSON, audit log, métricas
Sin nube obligatoria. Sin internet permanente. Sin licencias por core. La base de datos vive donde viven los datos.
El mismo motor. La misma API. Las mismas capacidades. Donde quieras que vivan tus datos.
Descarga el binario, lo corres en tu servidor. Tu hardware, tu nube, tu data center. Sin licencias por core. Sin call home. Tus datos nunca salen de tu infraestructura.
El motor corre EN el dispositivo. Raspberry Pi, gateway IoT, POS, dispositivo médico. La base de datos vive donde viven los datos. Sin nube obligatoria, sin internet permanente.
Instancias gestionadas por SLM. Cluster administrado por nosotros: provisioning, backups, monitoreo, parches, alta disponibilidad. Tú te enfocas en tu producto, nosotros en el motor.
El motor es exactamente el mismo en las tres modalidades. Puedes empezar en SLM Cloud, exportar tus datos cuando quieras y mover la instancia a tu infraestructura — sin lock-in, sin reformat. Es tu base de datos.
REST + JSON. Sin SQL. Sin ORM. Sin drivers.
# Crear curl -X POST :7700/banco/user/1 \ -H "SLM-KEY: $KEY" \ -d '{"nombre":"Luis","saldo":1500.25}' # Buscar curl -X POST :7700/banco/user/_search \ -H "SLM-KEY: $KEY" \ -d '{"query":{"match":{"nombre":"luis"}}}' # Agregar curl -X POST :7700/banco/transaction/_search \ -H "SLM-KEY: $KEY" \ -d '{"aggs":{"total":{"sum":{"field":"monto"}}},"size":0}'
Cada función está implementada y probada. 365 tests. 0 warnings.
fsync antes de ACK. Sobrevive corte de luz.
Tantivy — Apache Lucene reescrito en Rust. La misma tecnología que usa Elasticsearch pero sin JVM, sin GC pauses, 2x más rápido. BM25. <1ms sobre millones.
Fuzzy + accent folding + prefix en cualquier posición + terms (SQL IN). "rodrigez" encuentra "Rodríguez". "cirugia" encuentra "Cirugía". Todo en <1ms.
SUM/AVG/MAX/MIN/terms/histogram. Fast fields nativos. Filtradas por query.
GET /_summary: stats de cada campo en un call. Sin escribir aggs.
Precisión decimal exacta. Sin errores IEEE 754.
BLAKE3 hash. El PAN nunca toca el disco. PCI DSS.
API key + binding por IP. Silent drop.
Cada operación registrada. Inmutable. PCI REQ 10.
Nada se pierde. Historial completo.
Campos calculados. Aggregations stateful. Sandbox.
KNN con cosine/dot/euclidean. Auto-normalización.
geo_distance, geo_bounding_box, Haversine.
Feed de cambios en tiempo real desde el WAL.
21K docs/seg. Un solo fsync por batch.
Dev tools embebido. Como Kibana.
Endpoint /_metrics. Grafana-ready.
Rotación zero-downtime. Blue-green deploys.
Migración nativa. curl /_export > backup.ndjson. curl /_import. Renombra índices al importar.
Rotación de índices, búsqueda con glob, TTL automático y date_histogram. Sin Loki. Sin InfluxDB. Sin TimescaleDB. Con ACID y full-text search.
# Index rotation — one index per month curl -X POST :7700/trxs-2026-01/transaction/1 \ -d '{"tipo":"deposito","monto":500.00,"fecha":"2026-01-15"}' # Glob search — query across all months curl -X POST :7700/trxs-2026-*/_search \ -d '{"query":{"range":{"monto":{"gte":100}}}}' # date_histogram — aggregate by month curl -X POST :7700/trxs-*/_search \ -d '{"aggs":{"by_month":{"date_histogram":{ "field":"_created_at","fixed_interval":"30d"}}}, "size":0}' # TTL — auto-expire logs after 90 days curl -X PUT :7700/logs-2026-01/_settings \ -d '{"ttl":"90d"}'
Scripts server-side en Rhai. Sin round-trips. Sin descargar datos. El cálculo se ejecuta dentro del motor.
// Apply IVA to 100K transactions in one request POST /banco/transaction/_update_by_query { "query": {"term": {"tipo": "deposito"}}, "script": "this.monto = this.monto * 1.16" } // 100,000 transactions x IVA calculation = 6.81 seconds
Actualiza miles de documentos con un script
Campos calculados en tiempo de búsqueda
Relevancia personalizada con lógica de negocio
Aggregations stateful con acumulador
Una consola de desarrollo embebida en cada instancia de NeoDB. Como Kibana Dev Tools — pero sin instalar nada extra.
Editor Monaco (el mismo de VS Code) con autocompletado del DSL de NeoDB. Escribe GET /_health, presiona Ctrl+Enter, ve el resultado al lado. Sin Postman, sin curl, sin configurar nada.
Abre http://tu-servidor:7700/_console desde cualquier máquina. Tus workspaces se guardan en la misma base de datos. Cambias de laptop y todo está ahí.
# Así se ve. Escribe el verbo, el path, y el body. # Ctrl+Enter para ejecutar. Resultado a la derecha. GET /_health POST /banco/user/_search { "query": { "match": { "nombre": "luis" } }, "size": 10 } POST /banco/transaction/_search { "aggs": { "total": { "sum": { "field": "monto" } } }, "size": 0 }
Disponible en /_console de cada instancia. Zero instalación. Zero configuración.
NeoDB es REST + JSON. No necesitas driver, SDK, librería ni ORM. Cualquier dispositivo o lenguaje con un cliente HTTP puede escribir, leer, buscar y agregar datos.
WiFi + HTTP POST = base de datos
Edge computing con ACID real
fetch() nativo, sin SDK
Python, Rust, Go, Node, C, Java...
// Un ESP32 escribiendo telemetría a NeoDB // Solo necesita WiFi y HTTP. Nada más. HTTPClient http; http.begin("http://neodb:7700/iot/sensor/temp-001"); http.addHeader("SLM-KEY", KEY); http.addHeader("Content-Type", "application/json"); int code = http.POST("{\"temp\":23.5,\"humidity\":65,\"ts\":1774477000}"); // 201 Created — ACID, durable, searchable, aggregatable
Sin drivers que mantener. Sin compatibilidad de versiones. Sin dependencias. Si tu dispositivo puede hacer un HTTP POST con JSON, ya puede usar NeoDB con todas sus capacidades: ACID, búsqueda, aggregations, vectores.
No decimos que NeoDB es mejor en todo. Estos son los hechos.
| PostgreSQL | Elasticsearch | MongoDB | NeoDB | |
|---|---|---|---|---|
| Full-text search | Lento | Excelente | Básico | Excelente (<1ms) |
| Vector search | pgvector ext | Limitado | Atlas Search | HNSW nativo |
| Aggregations | Lento en escala | Bueno | Bueno | Rápido (fast fields) |
| Consistencia ACID | Fuerte | Eventual | Configurable | Fuerte (fsync siempre) |
| Schema flexible | ALTER TABLE | Dinámico | Dinámico | Dinámico, zero downtime |
| Audit log | Manual | Manual | Manual | Nativo, automático |
| Crash recovery | WAL | Translog | Journal | WAL + auto-replay |
| PCI DSS | Manual | Plugin | Manual | Nativo (blind, audit, CIDR) |
| RAM min | ~256MB | 4-16GB | ~256MB | 128MB |
| Setup | Horas | Horas | Horas | 30 segundos |
| Oracle | MySQL | SQL Server | Supabase | NeoDB | |
|---|---|---|---|---|---|
| Full-text search | Oracle Text (complejo) | Muy básico | Básico | pg tsvector (lento) | Excelente (<1ms) |
| Vector search | No | No | No | pgvector ext | HNSW nativo |
| Aggregations | Requiere tuning | Lento en escala | Requiere tuning | SQL GROUP BY | Rápido (fast fields) |
| Consistencia ACID | Fuerte | Fuerte (InnoDB) | Fuerte | Fuerte (PostgreSQL) | Fuerte (fsync siempre) |
| Schema flexible | ALTER TABLE | ALTER TABLE | ALTER TABLE | Migraciones | Dinámico, zero downtime |
| Audit log | Enterprise ($$) | Plugin | Enterprise ($$) | Manual | Nativo, automático |
| Crash recovery | REDO log | InnoDB log | Transaction log | WAL | WAL + auto-replay |
| PCI DSS | TDE ($$) | Manual | TDE ($$) | Manual | Nativo (blind, audit, CIDR) |
| RAM min | 2-4GB | ~512MB | 2GB | ~512MB | 128MB |
| Setup | Días/semanas | Horas | Días | Minutos (cloud) | 30 segundos |
Dos bases de datos. Dos schemas. Un pipeline de sincronización que eventualmente se rompe. Cuando eso pasa, preguntas: ¿cuál tiene el dato real? NeoDB es una sola fuente de verdad.
| Supabase | NeoDB | |
|---|---|---|
| Full-text search | PostgreSQL tsvector | Tantivy <1ms |
| Aggregations | SQL GROUP BY | Nativos (sum, terms, histogram) |
| Vector search | pgvector ext | HNSW nativo |
| PCI | Manual | Nativo (blind, audit, CIDR) |
| Schema changes | Migraciones | Sin downtime |
Pinecone, Weaviate, Qdrant — solo hacen búsqueda vectorial. ¿Necesitas transacciones? Agrega PostgreSQL. ¿Búsqueda de texto? Agrega Elasticsearch. ¿Analítica? Agrega ClickHouse. Son 4 sistemas. NeoDB hace los 4. Un binario. Una factura.
PostgreSQL: ACID sí, búsqueda necesita ES.
Elasticsearch: Búsqueda sí, ACID no.
NeoDB: ACID + búsqueda + dashboard. Todo inmediato.
Tradicional: PostgreSQL + ES + auditoría custom.
NeoDB: match + fuzzy + aggs + _audit. Un sistema.
Tradicional: PostgreSQL + ES + Pinecone + Redis.
NeoDB: text + vector + range + aggs. Un query.
NeoDB es una base de datos vectorizada. Almacena embeddings junto a tus datos transaccionales y los busca por similitud semántica. Sin Pinecone. Sin infraestructura extra. Sin otra factura.
# 1. Guarda tu documento con su embedding curl -X POST :7700/knowledge/article/1 \ -d '{"titulo":"Política de cancelación", "contenido":"El cliente tiene 48 horas para cancelar...", "embedding":[0.023, -0.041, 0.018, ...]}' # 2. Busca por significado (no por palabras) curl -X POST :7700/knowledge/article/_search \ -d '{"query":{"knn":{ "field":"embedding", "vector":[0.019, -0.038, ...], "k":5, "min_score":0.7}}}' # 3. Los resultados van a tu LLM como contexto # NeoDB no sabe de LLMs. Solo guarda y busca vectores. # Tú eliges el modelo. Hoy OpenAI, mañana Ollama. NeoDB no cambia.
NeoDB es agnóstica. No genera embeddings. No depende de ningún LLM. Solo almacena arrays de números y los busca por similitud matemática. De dónde vengan esos números es decisión tuya.
Cada afirmación que hacemos es verificable con comandos que puedes ejecutar tú mismo. Sin confianza ciega.
Inserta un doc, haz kill -9, reinicia. El doc está ahí.
Guarda un PAN, haz grep en disco. No existe.
Haz un request, consulta _audit. Está registrado.
Usa una key fuera de su CIDR. Silencio.
Suma 0.10 + 0.20. El resultado es 0.30. Exacto.
Verifica el hash con b3sum. Coincide.
La migración es directa. El query DSL es similar. Lo que cambia es más simple, no más complejo.
| Lo que hacías | Elasticsearch | NeoDB | Beneficio |
|---|---|---|---|
| Crear doc | POST /index/_doc/id | POST /index/type/id | Type en URL, no en el body |
| Update | POST /index/_update/id {"doc":{...}} | PATCH /index/type/id {...} | Sin wrapper {doc:{}} |
| Buscar exacto | {"term":{"status.keyword":"active"}} | {"term":{"status":"active"}} | Sin .keyword |
| Refresh | ?refresh=true | No necesario | ACID nativo |
| Numéricos | float/double/long/integer/scaled_float | number[n] | Un tipo. Precisión exacta. |
| Auth | Basic Auth (user:pass) | SLM-KEY + CIDR | Binding por IP |
El motor de storage es RocksDB — usado por Facebook, Uber, Netflix, CockroachDB. El motor de búsqueda es Tantivy — Apache Lucene reescrito en Rust, la misma base que usa Elasticsearch pero 2x más rápido y sin JVM. Lo usa Brave Search en producción. El lenguaje es Rust — adoptado por Microsoft, Google, el kernel de Linux, Discord, Cloudflare. Lo nuevo es la integración.
Porque eventualmente tus datos en Elasticsearch van a diferir de los de PostgreSQL. Y vas a pasar semanas descubriendo cuál tiene la razón. Con NeoDB hay una sola fuente de verdad. Siempre.
1.1 millones de documentos en 60 segundos. Búsqueda full-text en <1ms. SUM de 500K transacciones en 14ms. 21,000 escrituras/segundo. En un solo nodo con 128MB de RAM.
Cada escritura hace fsync al WAL antes de responder. Si el proceso muere, el WAL recovery completa las operaciones pendientes. Si el servidor pierde energía, el dato está en disco. Pruébalo: inserta un documento, haz kill -9 al proceso, reinicia. Tu documento está ahí.
El DSL JSON de NeoDB maneja: combinaciones booleanas (AND/OR/NOT), rangos numéricos y de fechas, búsqueda full-text con relevancia, fuzzy (tolerancia a typos), geo por radio, vectores por similitud, wildcards, y aggregations con sub-aggregations. Todo en un request. Y lo que SQL no puede: búsqueda de texto en <1ms sobre 100 millones de registros.
En NeoDB el middleware hace los JOINs — y resulta que es más rápido. Haces 2-3 queries paralelos a NeoDB (cada uno en <1ms) y ensamblas en tu middleware con la lógica de negocio que ya tienes. En SQL un JOIN de 3 tablas con millones de filas puede tomar segundos. En NeoDB son 3 requests paralelos de <1ms cada uno.
{"query":{"bool":{"must":[{"term":{"active":true}},{"range":{"balance":{"gt":1000}}}]}},"sort":[{"name":"asc"}]}
Misma lógica, sintaxis JSON. Y a diferencia de SQL, también puedes buscar texto, agregar aggregations, y filtrar por geo o vectores en el mismo query.
Agrega campos nuevos en caliente con PATCH /_schema. Sin ALTER TABLE. Sin migraciones. Sin downtime. Sin bloquear lecturas ni escrituras. Los documentos existentes siguen funcionando — los campos nuevos simplemente no existen en los viejos. Sin schema (modo dinámico), aceptas cualquier JSON sin declarar nada.
NeoDB no usa punto flotante para números. El tipo number[n] almacena como entero escalado: 25.10 con number[2] se guarda como 2510 (i64). Aritmética exacta. Sin IEEE 754. Sin redondeo. Si mandas 3 decimales a un campo de 2, el motor rechaza con error. No inventa, no redondea, no trunca.
NeoDB fue diseñado desde el día uno con PCI DSS v4.0 en mente. El tipo blind hace que el PAN nunca toque el disco (solo hash BLAKE3 irreversible). El audit log registra cada operación de forma inmutable. SLM-KEY con CIDR binding asegura que una credencial robada no sirve fuera de las IPs autorizadas. Field masking elimina campos sensibles por key. Tenemos un documento completo mapeando cada requerimiento PCI.
En v1, cada documento es atómico por separado. Para operaciones que involucran múltiples documentos, el middleware maneja la coordinación — que es donde vive tu lógica de negocio de todas formas. El update_by_query permite actualizar miles de documentos en una sola operación atómica con scripts.
Somos honestos: NeoDB es un proyecto joven. Estamos en fase de adopción temprana. Lo que NO es joven son los componentes: RocksDB tiene más de una década en producción en Facebook, Uber y Netflix. Tantivy (Apache Lucene en Rust) es la misma tecnología probada que impulsa a Elasticsearch y Brave Search. Rust es el lenguaje adoptado por el kernel de Linux. La integración es nueva. Los cimientos no lo son.
La replicación maestro-réplica está planificada para v2. En v1, NeoDB es single-node. La alta disponibilidad se logra con ZFS snapshots + replicación a nivel de filesystem + backups automáticos con el endpoint nativo. Para producción bancaria hoy: un nodo primario con ZFS mirror + snapshots automáticos + failover a nivel de infraestructura.
Es un solo binario. Paras el proceso, reemplazas el binario, arrancas. El WAL recovery completa cualquier operación pendiente automáticamente. Total: segundos. Si necesitas zero-downtime absoluto, un load balancer con dos nodos alternando (blue-green con ZFS snapshot) lo resuelve.
Es un hecho técnico. BLAKE3 produce hashes de 256 bits, lo que ofrece 128 bits de seguridad contra ataques cuánticos (algoritmo de Grover). ¿Es exclusivo de NeoDB? No — cualquier hash de 256 bits tiene la misma propiedad. La diferencia es que nosotros lo usamos. Hay bases de datos que todavía usan MD5 o SHA-1 internamente, que NO son quantum-resistant. Elegimos BLAKE3 porque es el hash más rápido disponible con seguridad criptográfica completa. No inventamos nada nuevo — elegimos la herramienta correcta.
Guías completas para cada caso de uso.
Cada documento también está disponible como .md raw para herramientas de IA — click "Raw .md" en la barra superior del visor.
Pega esta URL en Claude Code, Cursor, Copilot o cualquier AI coding tool y entiende NeoDB al instante — qué es, cómo se compara con Elasticsearch, el esquema de licencias, tipos, query DSL y patrones de integración.
Todos los endpoints REST con ejemplos curl
De cero a producción en 5 minutos
Guía paso a paso para migrar desde ES
Cumplimiento PCI DSS con NeoDB
Verificación de controles y evidencia para auditoría
Configuración, backup, monitoreo y mejores prácticas
Embeddings, búsqueda semántica, integración con LLMs
Para Cursor, Claude, Lovable, Bolt, v0
Las decisiones de arquitectura y sus razones
RocksDB + Tantivy, protocolo ACID, structs internos
El contrato completo del producto — tipos, queries, seguridad
Dev tools embebido en cada instancia. Escribe queries, explora datos. Accesible en /_console.
Todo binario oficial está firmado. Puedes verificar que no fue modificado antes de instalarlo.
Esta clave está integrada en todos los binarios oficiales en tiempo de compilación. Está publicada aquí para que puedas verificar que tu binario no fue modificado.
Ver archivo completo → neodb.slm.cloud/slm-public-key.txt# Verify the key is embedded in the binary
strings neodb | grep 5547c996
# Verify GPG signature (official releases)
gpg --verify neodb.sig neodb
Si alguien modifica el binario para cambiar la clave, el strings check falla. Si alguien modifica cualquier otra parte, la firma GPG falla.