El backend AI-native.
Idea dentro, API fuera.
Modela la realidad tal cual es — en grafos. Tus agentes componen queries JSON tipadas de forma programatica. Sin SQL, sin joins, sin ORMs.
Datos en vivo, sin cuenta.
Queries, hooks, validaciones, campos computados — todo incluido. Monta tu propio backend gratis →
Conecta desde Claude o Codex
Anade BlitzGraph como servidor MCP remoto y trabaja sobre el mismo backend en vivo.
Anade el servidor MCP:
claude mcp add --transport http blitzgraph https://blitzgraph.com/mcpAnade el servidor MCP:
codex mcp add blitzgraph --url https://blitzgraph.com/mcpLa auth va automatica. Haces login una vez en el navegador y tu agente ya puede usar las tools.
Modela la realidad,
no tablas.
Entidades con múltiples clases. Relaciones en ambas direcciones. Un lenguaje de consultas JSON tipado que tu agente compone correctamente.
Entidades multiclase
Un Usuario también puede ser Administrador y Moderador al mismo tiempo. Sin tablas de roles ni migraciones. Las entidades evolucionan al ganar y perder clases con el tiempo.
Relaciones bidireccionales
¿Quién escribió esta publicación? y ¿Qué escribió este usuario? Mismo coste, mismo índice, O(1) en ambas direcciones. Sin tablas de búsqueda inversa ni consultas adicionales.
Consultas JSON tipadas (BQL)
Tu agente compone objetos de consulta, no cadenas SQL. Filtros, expansiones anidadas, proyecciones y búsqueda de texto completo en una petición. Cero N+1.
Tipos de contenido ricos
EMAIL, URL, DATE, JSON, FLEX. No solo varchar. Validación integrada en la base de datos. Tu esquema describe qué son realmente los datos.
Integridad referencial
El motor aplica restricciones de cardinalidad y políticas onDelete (cascade, restrict, unlink). Tu grafo se mantiene consistente por defecto.
Búsqueda de texto integrada
Motor BM25 nativo con autocompletado, prefijo, coincidencia exacta y todas las raíces. Sin Elasticsearch ni servicios externos. Funciona dentro de recorridos de grafo.
Transacciones inteligentes
Las mutaciones se ordenan topológicamente y se validan sobre el resultado final, no línea a línea. Las reglas de negocio comprueban el estado final de toda la transacción, por lo que las operaciones complejas con varias entidades simplemente funcionan. Todo o nada, siempre consistente.
Lógica de negocio en la base de datos
Validaciones, campos calculados, transformaciones y efectos, todo definido en el esquema. Tus reglas de negocio viven junto a los datos, no dispersas por middleware y código de aplicación.
El lenguaje de consultas
que los agentes escriben correctamente.
SQL obliga a los agentes a generar cadenas y adivinar resultados. PostgREST añade REST sobre tablas. BQL son datos estructurados del cliente al motor.
Compón consultas desde código, no cadenas.Los agentes y la aplicación crean objetos JSON tipados, no cadenas SQL ni cadenas de ORM. La consulta ES la estructura de datos. Sin generación previa ni ambigüedad de análisis.
Lecturas tipo GraphQL, como JSON tipado.Obtén una entidad raíz, expande relaciones y proyecta campos anidados, todo en una petición. La misma forma de filtrar, ordenar y limitar en cada nivel. Como GraphQL, sin la ceremonia del esquema.
Modela la realidad, no tablas.Entidades multiclase, arcos bidireccionales y $expand nativo. Tu modelo de datos refleja cómo se relacionan realmente las cosas. Sin tablas intermedias ni malabarismos con claves foráneas.
Filtra a través de relaciones.Consulta por datos conectados, no solo por campos locales. Recorre sesiones, memorias y propietarios sin ensamblar joins en el código de la aplicación.
// Unidades Human y Spanish. Búsqueda y campos calculados. { "$kinds": { "$all": ["Human", "Spanish"] }, "$search": "senior backend rust", "$filter": { "role": { "$in": ["engineer", "designer"] } }, "$fields": [ "name", "salary", "bonus", { "%total": { "$js": "salary + bonus" } }, { "$expand": "projects", "$sort": "-budget", "$limit": 3, "$fields": ["title", "budget", "spent", { "%remaining": { "$js": "budget - spent" } } ] } ] }
// Sesiones recientes con metadatos de arco en memorias relevantes. { "$kinds": "Session", "$filter": { "$createdAt": { "$gte": "<datetime>2026-04-01T00:00:00Z" } }, "$sort": "-$createdAt", "$limit": 5, "$fields": [ "$createdAt", { "$expandArc": "memories", "$kinds": ["Fact", "Idea"], "$search": "user preferences", "$filter": { "relevance": { "$gte": 0.7 } }, "$sort": "-relevance", "$limit": 10, "$fields": ["content", "relevance"] } ] }
Grandes bases de datos.
Aún diseñadas para tablas.
Supabase piensa en columnas, Convex en documentos y Mongo Atlas en colecciones. Esto cambia al pensar en entidades y relaciones.
frente a BlitzGraph
Un Usuario que se vuelve Admin necesita una tabla de roles.¿Nuevo rol? Nueva tabla, nuevo JOIN, nueva migración. Cada cambio de entidad toca el esquema.
Una entidad, múltiples clases.Un Usuario puede ser [User, Admin, Moderator] a la vez. Las clases se componen libremente, sin migraciones.
¿Quién escribió esto? cuesta un JOIN inverso.Las claves foráneas apuntan en una dirección. Las búsquedas inversas necesitan índices, JOINs y una planificación cuidadosa.
Arcos bidireccionales, O(1) en ambos sentidos.Cada relación se almacena en ambas direcciones. "Usuario → Publicaciones" y "Publicación → Autor", mismo coste, mismo índice.
frente a BlitzGraph
No hay relaciones reales entre documentos.Las referencias son simples IDs de texto que gestionas tú mismo. Sin recorridos, cardinalidad ni políticas de cascada.
Las relaciones son elementos de primera clase.Arcos bidireccionales con onDelete cascade/restrict/unlink. $expand recorre el grafo en la misma consulta.
Documentos planos, sin evolución de entidad.Una Tarea que se vuelve Bug necesita un campo de tipo y condicionales por todas partes. Los cambios de esquema se propagan por el código de la aplicación.
Entidades que crecen y se componen.Añade una clase: [Task, Bug]. La entidad gana los campos y relaciones de Bug sin romper las consultas existentes.
frente a BlitzGraph
Una entidad repartida entre tablas.En SQL, un Cliente vive en usuarios, direcciones, información de facturación y roles. Cuatro tablas, cuatro IDs y cuatro JOINs para reconstruir una entidad.
Una unidad, un ID, para siempre.Una unidad tiene un único ID durante todo su ciclo de vida. Todos sus datos y relaciones son accesibles desde esa identidad.
Evolucionar una entidad implica migraciones.¿Una Company que pasa a Prospect, luego a Client y después a Churned? Son 4 campos de estado, 4 consultas condicionales y esperar que nada se rompa.
Las clases se componen y evolucionan.La misma unidad: [Company] → [Company, Prospect] → [Company, Client] → [Company, Churned]. Mismo ID, nuevas capacidades, cero migraciones.
frente a BlitzGraph
Lenguaje de consultas basado en cadenas.Las consultas Cypher son cadenas que tu aplicación genera y tu agente intenta adivinar. Errores de análisis en ejecución y sin validación estructurada.
JSON de entrada y salida.BQL es JSON estructurado. Tu agente compone objetos, no cadenas. Validado contra el esquema en compilación con la macro bql!.
Los nodos pertenecen a una etiqueta cada vez.Las etiquetas de Neo4j son tags planos sin esquema, herencia ni aislamiento de campos. Añadir una etiqueta no añade campos estructurados.
Las unidades pertenecen a varias clases.Una unidad con las clases [User, Admin, Moderator] hereda los campos, validaciones y relaciones de cada clase. El polimorfismo es el modelo central.
Como nos comparamos
BlitzGraph vs las bases de datos que estas considerando. Incluyendo donde ganan ellos — preferimos ser honestos.
| Capacidad | BlitzGraph | Supabase | Convex | Mongo | Firebase |
|---|---|---|---|---|---|
| Solo en BlitzGraph | |||||
| Composicion multi-kind (User + Admin en una entidad) | ✓ | ✕ | ✕ | ✕ | ✕ |
| Arcos bidireccionales con lookup inverso O(1) | ✓ | ✕ | ✕ | ✕ | ✕ |
| Sandboxes para agentes (subespacios aislados) | ✓ | ✕ | ✕ | ✕ | ✕ |
| Modelo de datos | |||||
| Grafo + documento + relacional en un motor | ✓ | ✕ | ✕ | ~ | ✕ |
| Lecturas anidadas de grafo en una query ($expand) | ✓ | ✕ | ✕ | ✕ | ✕ |
| Integridad referencial (onDelete, cardinalidad) | ✓ | ✓ | ✕ | ✕ | ✕ |
| Busqueda full-text nativa (BM25) | ✓ | ~ | ✕ | ~ | ✕ |
| Validacion de tipos (EMAIL, URL, DATE…) | ✓ | ✕ | ✕ | ✕ | ✕ |
| Archivos como valores nativos (no un servicio aparte) | ✓ | ~ | ~ | ~ | ~ |
| Experiencia de desarrollo | |||||
| Queries componibles por agentes (sin SQL strings) | ✓ | ~ | ✕ | ~ | ✕ |
| Logica de negocio en el schema (hooks, validaciones) | ✓ | ~ | ~ | ~ | ~ |
| Transacciones inteligentes (topologicas, atomicas) | ✓ | ~ | ✓ | ~ | ✕ |
| Donde otros ganan hoy | |||||
| Realtime / live queries | ✕ | ✓ | ✓ | ~ | ✓ |
| Anos en produccion | ✕ | ✓ | ~ | ✓ | ✓ |
| Comunidad y ecosistema grandes | ✕ | ✓ | ~ | ✓ | ✓ |