Bases de datos de grafos embebibles más allá de SQLite

SQLite está en todas partes. Está en tu teléfono, en tu navegador, en tu smart TV, probablemente en tu coche. Resolvió un problema fundamental, darles a las aplicaciones una base de datos SQL completa sin necesidad de ejecutar un servidor aparte, y lo hizo tan bien que 'base de datos embebida' y 'SQLite' se volvieron casi sinónimos. Pero el modelo relacional de SQLite no siempre es la opción adecuada. Si tus datos tratan fundamentalmente de relaciones (conexiones sociales, grafos de dependencias, redes de conocimiento, problemas de enrutamiento), meterlos a la fuerza en tablas con claves foráneas da lugar a consultas o terriblemente complejas o dolorosamente lentas.

Una nueva ola de bases de datos de grafos embebibles intenta hacer por los datos en grafo lo que SQLite hizo por los datos relacionales: ofrecerte una base de datos rápida, sin dependencias y en proceso, que hable el lenguaje de consulta adecuado para datos conectados. Varias de ellas están escritas en Rust, lo que resulta ser una opción excelente para este problema. Veamos por qué las bases de datos de grafos se están volviendo embebibles, qué aporta el ecosistema de Rust y cuándo deberías considerar una de ellas.

El punto ciego del modelo relacional

Las bases de datos relacionales manejan bien la mayoría de patrones de datos. ¿Uno a muchos? Clave foránea. ¿Muchos a muchos? Tabla intermedia. Búsquedas simples, agregaciones, filtros: SQL se creó para esto. Los problemas empiezan cuando tus consultas se preocupan por caminos, profundidad y conectividad.

Piensa en un resolutor de dependencias. Tienes paquetes, cada uno depende de otros paquetes, y cada uno tiene restricciones de versión. Necesitas responder: '¿Qué árbol completo de dependencias transitivas se instala si instalo el paquete X? ¿Hay dependencias circulares? ¿Hay requisitos de versión en conflicto a cualquier profundidad?' En SQL, esto requiere CTE recursivos (expresiones de tabla comunes), que son verbosos, difíciles de optimizar y se vuelven exponencialmente más lentos a medida que el grafo se hace más profundo.

-- Finding all transitive dependencies in SQL
-- This works, but gets ugly fast
WITH RECURSIVE deps AS (
-- Base case: direct dependencies
SELECT dependency_id, 1 as depth
FROM package_dependencies
WHERE package_id = 'my-package'
UNION ALL
-- Recursive case: dependencies of dependencies
SELECT pd.dependency_id, d.depth + 1
FROM package_dependencies pd
JOIN deps d ON pd.package_id = d.dependency_id
WHERE d.depth < 50  -- safety limit to prevent infinite loops
)
SELECT DISTINCT dependency_id, MIN(depth) as min_depth
FROM deps
GROUP BY dependency_id
ORDER BY min_depth;
-- Now try detecting circular dependencies.
-- Or finding the shortest path between two packages.
-- Or querying all packages within 3 hops that match a version constraint.
-- Each query gets progressively more painful.

En una base de datos de grafos, este es el patrón de consulta nativo. No luchas contra el modelo de datos, trabajas con él. Recorrer aristas, seguir caminos, detectar ciclos: son operaciones de primera clase, no recursión añadida a posteriori.

Por qué importa que sea embebible

Neo4j ha sido la base de datos de grafos dominante durante más de una década, y es realmente excelente. Pero es un servidor. Lo ejecutas como un proceso aparte, te conectas mediante un protocolo de red, gestionas su memoria de la JVM y cargas con su sobrecarga operativa. Para una aplicación en producción con un equipo de operaciones dedicado, está bien. Para una herramienta CLI, una aplicación de escritorio, un sistema de compilación o un dispositivo embebido, es absurdo.

La lección de SQLite aplica aquí: muchos casos de uso necesitan capacidades de consulta de grafos sin la sobrecarga de un servidor. Una herramienta de análisis de código que construye un grafo de llamadas. Un motor de juegos que almacena relaciones entre entidades. Una app de notas local-first con enlaces bidireccionales. Un analizador de topología de red. Todos quieren consultas de grafos, y ninguno quiere pedirle a sus usuarios que instalen y configuren un servidor de base de datos.

Las bases de datos de grafos embebibles se ejecutan dentro de tu proceso, guardan los datos en archivos locales y exponen una API de librería en lugar de un protocolo de red. Tu aplicación se enlaza con ellas igual que lo haría con SQLite. Sin servidor, sin puertos, sin autenticación, sin complejidad de despliegue.

Lo que Rust aporta a las bases de datos de grafos

Rust se ha convertido en el lenguaje preferido de un número desproporcionado de nuevos proyectos de bases de datos, y las razones van más allá del discurso habitual de 'seguridad de memoria sin recolector de basura'.

• Latencia predecible. Los recorridos de grafos son sensibles a la latencia. Cada salto en un recorrido es un acceso a memoria, y los recorridos profundos hacen millones de ellos. Una pausa del GC en mitad de un recorrido de 10 saltos destroza tu latencia de cola. El modelo de ownership de Rust te da gestión de memoria determinista sin pausas de GC, algo crítico para un rendimiento de consulta consistente.
• Concurrencia segura. Las bases de datos de grafos se benefician enormemente de los recorridos paralelos. Explorar varios caminos a la vez puede convertir una consulta de 100 ms en una de 10 ms. El sistema de tipos de Rust evita las carreras de datos en tiempo de compilación, lo que significa que puedes paralelizar agresivamente sin miedo a corromper los datos del grafo.
• Binario pequeño, sin runtime. En una base de datos embebible, el tamaño del despliegue importa. Una base de datos de grafos en Rust se compila en una única librería nativa sin dependencias de runtime. Compáralo con una solución basada en la JVM que necesita un runtime de 200 MB, o con una solución en Go que incluye un recolector de basura que no pediste.
• FFI de C. La capacidad de Rust de exponer una API compatible con C significa que la base de datos se puede usar desde prácticamente cualquier lenguaje. Escríbela en Rust, llámala desde Python, JavaScript, Go, Swift o cualquier otro que hable C.

El modelo de grafo de propiedades

La mayoría de bases de datos de grafos embebibles usan el modelo de grafo de propiedades, que merece la pena entender si no has trabajado antes con bases de datos de grafos. El modelo tiene tres primitivas:

• Nodos: entidades con una etiqueta y propiedades clave-valor. Piénsalos como filas de una tabla, pero sin esquema fijo.
• Aristas: conexiones dirigidas entre nodos, también con una etiqueta y propiedades. La etiqueta describe el tipo de relación (DEPENDS_ON, AUTHORED_BY, LINKS_TO).
• Recorridos: consultas que siguen aristas de nodo en nodo, filtrando opcionalmente por propiedades, agregando resultados o encontrando caminos.

// Conceptual API for an embeddable graph database
let db = GraphDB::open("my_graph.db")?;
// Create nodes
let alice = db.create_node("Person", props! {
"name" => "Alice",
"role" => "engineer"
})?;
let project = db.create_node("Project", props! {
"name" => "Auth Service",
"language" => "Rust"
})?;
// Create edges
db.create_edge(alice, project, "WORKS_ON", props! {
"since" => "2025-01"
})?;
// Traverse: find all projects worked on by Alice's teammates
let results = db.traverse()
.from(alice)
.follow("WORKS_ON")        // Alice -> projects
.reverse("WORKS_ON")       // projects <- other people
.follow("WORKS_ON")        // other people -> their projects
.filter(|node| node.label() == "Project")
.collect()?;

El modelo de grafo de propiedades es más flexible que los esquemas relacionales para datos que evolucionan rápidamente. No necesitas definir el esquema por adelantado ni ejecutar migraciones cuando añades un nuevo tipo de relación. Basta con crear aristas con nuevas etiquetas. Esta flexibilidad sin esquema es un arma de doble filo: pierdes las garantías de seguridad de un esquema bien definido, pero para aplicaciones donde la estructura del grafo evoluciona (bases de conocimiento, redes sociales, seguimiento de dependencias), es un compromiso pragmático.

Cuándo usar realmente una base de datos de grafos

Se recomiendan bases de datos de grafos en situaciones donde no hacen falta, y se pasan por alto en situaciones donde realmente ayudarían. Aquí está mi evaluación sincera de dónde brillan y dónde no.

Buen encaje: resolución de dependencias, control de acceso (quién puede acceder a qué a través de qué membresías de grupo), detección de fraude (encontrar conexiones entre entidades), motores de recomendación (a los usuarios que les gustó X también les gustó Y), análisis de topología de red, grafos de conocimiento y herramientas de análisis de código. El nexo común: tus consultas expresan naturalmente caminos y conectividad.

Mal encaje: aplicaciones CRUD simples, datos de series temporales, cargas de analítica y agregación, cualquier cosa donde tus consultas sean principalmente 'obtener los registros que cumplen la condición X'. Si estás haciendo SELECT * FROM users WHERE country = 'US' ORDER BY created_at, una base de datos relacional es la herramienta correcta. No uses una base de datos de grafos porque suene interesante; úsala porque tus consultas son realmente de forma de grafo.

La prueba de fuego que uso: dibuja tu modelo de datos en una pizarra. Si son sobre todo cajas en filas (entidades con atributos), usa una base de datos relacional. Si son cajas conectadas por flechas y las flechas importan tanto como las cajas, considera una base de datos de grafos.

Motores de almacenamiento y compromisos

Bajo el capó, las bases de datos de grafos embebibles enfrentan decisiones interesantes sobre el motor de almacenamiento. Los enfoques más comunes:

• Almacenamiento por lista de adyacencia. Cada nodo guarda una lista de sus aristas salientes. Rápido para recorridos locales (encontrar los vecinos de un nodo), pero lento para consultas globales (encontrar todas las aristas con la etiqueta X). La mayoría de bases de datos de grafos embebibles usan este enfoque porque los recorridos locales son la operación más común.
• Almacenamiento por lista de aristas. Las aristas se guardan en una estructura ordenada separada, indexada por origen, destino o etiqueta. Mejor para consultas globales y operaciones masivas, pero añade indirección a los recorridos locales.
• Enfoques híbridos. Algunas bases de datos usan listas de adyacencia para recorrer y mantienen índices secundarios sobre etiquetas de aristas o propiedades de nodos para consultas filtradas. Es el enfoque más flexible, pero usa más almacenamiento y hace las escrituras más costosas.

Muchas bases de datos de grafos en Rust se construyen sobre almacenes clave-valor embebidos existentes como RocksDB o sled. Es una elección pragmática: obtienes persistencia probada en batalla, recuperación ante fallos y compactación gratis. La capa de grafo traduce nodos y aristas a operaciones clave-valor. La desventaja es que el techo de rendimiento queda limitado por las características del almacén clave-valor, y las optimizaciones específicas de grafos (como guardar las aristas de un nodo de forma contigua en disco para recorridos amigables con la caché) pueden ser más difíciles de implementar.

Lenguajes de consulta: la cuestión sin resolver

SQL es el lenguaje universal de las bases de datos relacionales. Las bases de datos de grafos no tienen un consenso equivalente. Cypher (de Neo4j), Gremlin (de Apache TinkerPop), SPARQL (para grafos RDF) y el emergente estándar GQL compiten por la atención.

La mayoría de bases de datos de grafos embebibles evitan esto ofreciendo una API con patrón builder en el lenguaje anfitrión en lugar de un lenguaje de consulta. Construyes recorridos con encadenamiento de métodos, lo que resulta ergonómico en lenguajes tipados y evita la complejidad de analizar y optimizar un lenguaje de consulta. El compromiso es que tus consultas no son portables entre bases de datos: cambiar de una base de datos de grafos embebible a otra significa reescribir tu código de consultas.

GQL (Graph Query Language) es el estándar ISO que se supone que unificará las consultas de grafos. Toma mucho de Cypher y poco a poco gana adopción. Si estás eligiendo hoy una base de datos de grafos embebible, merece la pena comprobar si tiene soporte para GQL en su hoja de ruta: los lenguajes de consulta estandarizados tienden a imponerse a largo plazo, aunque los propietarios sean más pulidos al principio.

Consideraciones prácticas

Si estás evaluando una base de datos de grafos embebible para tu proyecto, esto es lo que realmente importa en la práctica:

1. Mide con tu carga de trabajo. Los benchmarks de bases de datos de grafos son notoriamente engañosos. Una base de datos que destaca en recorridos superficiales y anchos (amigos de amigos en una red social) puede sufrir con recorridos profundos y estrechos (resolución de cadenas de dependencias). Haz un prototipo con tus patrones de consulta reales.
2. Revisa la historia de seguridad ante fallos. Las bases de datos embebidas viven o mueren por sus garantías de durabilidad. ¿Usa la base de datos write-ahead logging? ¿Es segura ante caídas? ¿Puede recuperarse de un corte de luz sin perder datos? 'Corrupción ante apagados inesperados' no es una respuesta aceptable para producción.
3. Mira el modelo de memoria. Algunas bases de datos de grafos embebibles mapean en memoria el grafo completo, lo que funciona de maravilla hasta que el grafo supera la RAM disponible. Otras usan un enfoque centrado en disco con caché. Conoce qué modelo usa la base de datos que elijas y si tu grafo cabe.
4. Considera la calidad de los bindings. Si la base de datos está escrita en Rust pero la usas desde Python, los bindings de Python importan más que los internos de Rust. Comprueba si los bindings están mantenidos, documentados y son eficientes, o si son una ocurrencia tardía.
5. Piensa en las migraciones. Sin esquema no significa sin cambios. Cuando tu modelo de grafo evolucione, ¿cómo gestionas los datos existentes? Algunas bases de datos admiten scripts de migración o esquemas versionados. Otras lo dejan enteramente en tus manos.

El ecosistema de bases de datos de grafos embebibles todavía es joven comparado con el mundo relacional. SQLite lleva más de dos décadas puliéndose. La mayoría de bases de datos de grafos embebibles tienen menos de cinco años. Eso significa aristas más ásperas, menos recursos de la comunidad y más riesgo. Pero la propuesta de valor central, consultas de grafos sin sobrecarga de servidor, es sólida. Para el caso de uso adecuado, una base de datos de grafos embebible puede reemplazar cientos de líneas de SQL recursivo con unas pocas líneas de código de recorrido, correr más rápido en el proceso y hacer que tu modelo de datos encaje de verdad con el problema que resuelves.