El backend de aplicación donde una funcionalidad se define una sola vez.
BlitzGraph modela equipos, roles y contenido como un único grafo con una sola API JSON tipada. Las lecturas, las escrituras, la búsqueda y las consultas que compone tu agente parten de una única definición, no de un esquema, una capa de políticas, funciones de servidor, tipos generados y pantallas que guardan cada una su copia de la regla.
// La pantalla del equipo: miembros + proyectos activos, anidados { "$kinds": "Team", "$filter": { "name": "Acme" }, "$fields": [ "name", { "$expand": "members", "$fields": ["name", "email"], "$limit": 20 }, { "$expand": "projects", "$filter": { "active": true }, "$sort": "-$created_at", "$limit": 10, "$fields": ["title", "status"] } ] }
El impuesto de la sincronización
Una regla de producto. Cinco sitios donde vive.
En un stack basado en tablas, una funcionalidad es una migración, una política, una función de servidor, un tipo generado y una pantalla: artefactos que solo funcionan mientras coinciden entre sí. BlitzGraph los colapsa en un esquema que la base de datos hace cumplir.
Lanzar una funcionalidad de equipos
En un stack de tablas
Usuarios, equipos, membresías, invitaciones: cuatro tablas, claves foráneas en ambos sentidos, un join por cada lectura y una forma de API que montas a mano.
En BlitzGraph
Team, User y Membership son clases. Cada relación se consulta desde ambos lados, y la base de datos aplica la cardinalidad y el comportamiento al borrar.
Pintar la pantalla del espacio de trabajo
En un stack de tablas
Tres idas y vueltas o un join afinado a mano con trampas N+1, y luego código de cliente para volver a coser miembros, proyectos y propietarios.
En BlitzGraph
Una petición. $expand devuelve el equipo con sus miembros y proyectos activos anidados, filtrados, ordenados y paginados en cada nivel.
Añadir búsqueda
En un stack de tablas
Enchufar Algolia o afinar tsvector, mantenerlo sincronizado en cada escritura y luego volver a pedir el contexto de cada resultado antes de poder pintarlo.
En BlitzGraph
$search se ejecuta en el motor: relevancia BM25, pesos por campo, tolerancia a erratas. Los resultados son unidades, así que expandes sus relaciones en la misma consulta.
Dejar que un agente toque el backend
En un stack de tablas
El agente escribe SQL, políticas y funciones de servidor por todo el repositorio: código de forma libre que quien revisa verifica a mano, y una política que falta se convierte en una fuga de datos.
En BlitzGraph
Los agentes leen el esquema por MCP y envían operaciones JSON tipadas. Las formas mal construidas se rechazan, y los experimentos corren en un subspace aislado.
Qué incluye
Un backend, no un kit de piezas.
Las plataformas de propósito general te dan primitivas excelentes y te dejan a ti el montaje. Estas seis tareas vienen ya montadas.
Relaciones con reglas
Los roles son tipados y bidireccionales, y el motor aplica la cardinalidad y el comportamiento al borrar: cascade, restrict, unlink. Sin registros huérfanos ni triggers de limpieza.
Una consulta por pantalla
$expand recorre el grafo y devuelve resultados anidados, filtrados y ordenados en cada nivel. La forma de la respuesta es la forma de la pantalla.
Lógica que viaja con los datos
Los campos calculados, las validaciones y los hooks viven en el esquema, así que total = precio * cantidad se cumple en todas las rutas de escritura, incluidas las que añada un agente más adelante.
Entidades que llevan varios sombreros
Una unidad puede ser User, Admin y Author a la vez. Composición en lugar de columnas bandera, tipos enum o apaños de herencia en una sola tabla.
Búsqueda incluida
Búsqueda de texto completo BM25 con pesos por campo y tolerancia a erratas, indexada a medida que escribes. Sin un servicio aparte que desplegar y mantener sincronizado.
Sandboxes para experimentar
Los subspaces son áreas aisladas del mismo backend. Deja que una importación o un agente hagan lo que quieran en uno; los datos de producción ni se enteran.
Escrituras
Mutaciones con forma de funcionalidad, no de filas.
Un flujo de alta que crea el perfil del usuario, el equipo y el primer proyecto es un único lote atómico. Las referencias se resuelven dentro, la cardinalidad se valida sobre el estado final y los hooks del esquema se ejecutan antes del commit: las mismas garantías tanto si la petición viene de tu código como de tu agente.
// Usuario + equipo + primer proyecto, una petición [ { "$setKinds": ["User"], "$var": "_:ana", "name": "Ana", "email": "ana@acme.dev" }, { "$setKinds": ["Team"], "name": "Acme", "members": "_:ana", "projects": [ { "$setKinds": ["Task"], "title": "Launch" } ] } ]
// comparación honesta
Dónde gana cada uno.
Supabase, Convex y Firebase son plataformas excelentes; la comparación está aquí porque es la decisión que estás tomando de verdad. Esta es la versión honesta, con las derrotas incluidas.
Supabase · Convex · Firebase
BaaS de propósito general
Base de datos gestionada, auth, almacenamiento y funciones. Un tiempo imbatible hasta el primer CRUD y ecosistemas maduros; las reglas de relación se reparten entre la base de datos, la autorización y la aplicación a medida que el producto crece.
Su terreno: auth madura, almacenamiento y años de rodaje en producción ponen en marcha una aplicación estándar muy rápido.
Los roles y los datos anidados implican tablas intermedias, políticas, funciones de servidor y tipos de cliente que solo funcionan mientras coinciden entre sí.
Los agentes generan cadenas SQL, políticas o funciones de servidor: código de forma libre que hay que verificar a mano en la revisión.
Backend de grafo nativo para agentes
BlitzGraph
La capa de relaciones es la base de datos: roles tipados, lecturas anidadas, búsqueda y lógica en un solo esquema, detrás de una API que los agentes componen correctamente.
BlitzGraph incluye inicio de sesión nativo para usuarios finales en los Portales, separado de la autenticación del panel y de los agentes. Configura la autenticación del portal y el acceso a la aplicación para tus usuarios; las sesiones de portal están confinadas a la superficie de su aplicación.
Un solo esquema define la funcionalidad: se consulta en ambas direcciones, la integridad está garantizada y las pantallas se leen en una sola petición.
Los agentes leen el esquema y envían JSON tipado que el motor valida, preparado en un subspace que producción nunca ve.
Contrapartidas
Cuándo siguen siendo la elección correcta.
Elige Supabase, Convex o Firebase cuando
- Tus usuarios finales inician sesión desde una aplicación que alojas tú, fuera de los Portales
- Necesitas suscripciones en tiempo real desde el primer día
- El código abierto o el autoalojamiento son un requisito
- Quieres una década de respuestas en Stack Overflow
Elige BlitzGraph cuando
- El producto son equipos, roles y contenido: un grafo disfrazado de tablas
- Quieres una única definición en lugar de cinco capas sincronizadas
- Los agentes escriben una parte importante de tu backend
- La búsqueda y la integridad deberían ser tarea de la base de datos
Beta pública, plan gratis, sin tarjeta. Tu grafo se exporta a JSON cuando lo pidas.
Empieza por una funcionalidad
Migra la pantalla con más pegamento.
Coge la que necesita tres consultas y un diagrama para explicarse. Modélala en el playground: si no se colapsa en un esquema y una consulta, déjalo.