Imaginá que tenés que construir una aplicación moderna desde cero. Necesitás guardar documentos con esquema flexible. Modelar relaciones complejas entre entidades. Hacer búsqueda semántica con embeddings. Tener queries en tiempo real que se actualicen cuando los datos cambian. Y controlar quién puede ver qué, a nivel de fila.
Con el stack tradicional, eso son cinco herramientas diferentes. MongoDB para los documentos. Neo4j para el grafo. Pinecone o Qdrant para los vectores. Elasticsearch para la búsqueda. Redis para el tiempo real. Auth0 o similar para la autenticación. Cinco conexiones, cinco schemas, cinco puntos de falla, cinco facturas, cinco curvas de aprendizaje.
¿Y si todo eso fuera una sola base de datos, con un solo lenguaje de query, deployada en un solo proceso?
Eso es exactamente lo que propone SurrealDB. Y la propuesta es tan ambiciosa que genera escepticismo — hasta que lo usás.
Qué Es SurrealDB (y Qué No Es)
SurrealDB es una base de datos multi-modelo construida en Rust, open-source, fundada en Londres en 2021. Tiene 32.000 estrellas en GitHub y está siendo adoptada aceleradamente por equipos que construyen aplicaciones con IA, sistemas en tiempo real y arquitecturas donde el grafo de relaciones importa tanto como los datos en sí.
Lo que NO es: no es "otro MongoDB con features extras". No es una base de datos NewSQL que escala PostgreSQL. No es un vector store con JSON encima. Es algo genuinamente diferente: un engine que trata a los documentos, los grafos, los vectores y las relaciones como ciudadanos de primera clase del mismo modelo de datos.
En un solo sistema, SurrealDB soporta:
→ Almacenamiento de documentos con esquema flexible o estricto → Relaciones tipo grafo sin JOINs, con traversal nativo → Búsqueda vectorial con HNSW para semantic search → Full-text search con BM25 y ranking → Series de tiempo y datos geoespaciales → Live queries con WebSockets → Autenticación y autorización a nivel de registro → Deployment embebido, en servidor, en el edge o en WASM dentro del browser
SurrealQL: SQL que Aprendió a Volar
El corazón del sistema es SurrealQL — un lenguaje de query que toma la familiaridad de SQL y le agrega capacidades que ningún SQL estándar tiene. Si sabés escribir un SELECT, vas a entender SurrealQL en minutos. Lo que tardás en aprender es lo nuevo: las flechas de grafo, los record links, el vector search.
Crear un registro es directo:
-- Crear registros con ID determinístico
CREATE person:tobi SET
name = 'Tobi',
age = 28,
skills = ['Rust', 'Python', 'SurrealDB'];
-- O con ID autogenerado
INSERT INTO article {
title: 'SurrealDB cambió todo',
body: 'Lorem ipsum...',
tags: ['database', 'ai'],
publishedAt: time::now()
};Pero la parte realmente interesante son los record links. En SurrealDB, una relación no es una foreign key en una tabla de unión — es una referencia directa entre registros. Y las traversals de grafo usan una sintaxis de flechas que es casi prosa:
-- Crear una relación de grafo entre dos registros
RELATE person:tobi -> sigue -> person:maria
SET desde = time::now();
-- Traversal: ¿a quién sigue Tobi?
SELECT ->sigue->person.name AS siguiendo
FROM person:tobi;
-- Traversal de segundo nivel: ¿a quién sigue la gente que sigue Tobi?
SELECT ->sigue->person->sigue->person.name AS amigos_de_amigos
FROM person:tobi;
-- Traversal inverso: ¿quién sigue a Tobi?
SELECT <-sigue<-person.name AS seguidores
FROM person:tobi;Eso que antes requería Neo4j y Cypher, o múltiples JOINs en PostgreSQL con una tabla de relaciones, acá es una línea. Y el mismo query puede incluir campos del documento, relaciones de grafo y búsqueda vectorial — todo en una sola consulta, con una sola conexión.
Vector Search y Full-Text: El Stack de AI en Una Sola Línea
La mayoría de las aplicaciones con AI necesitan hoy dos tipos de búsqueda: semántica (encontrar lo que significa lo mismo aunque use palabras distintas) y léxica (encontrar el término exacto). El estado del arte para pipelines RAG es combinar ambas — técnica llamada Hybrid Search. SurrealDB implementa los dos nativamente, sin servicios externos:
-- Definir índice vectorial (HNSW) en una tabla
DEFINE INDEX doc_embedding ON documents
FIELDS embedding
HNSW DIMENSION 1536 DIST COSINE;
-- Búsqueda semántica por similitud de vector
SELECT title, body,
vector::similarity::cosine(embedding, $query_vec) AS score
FROM documents
WHERE vector::similarity::cosine(embedding, $query_vec) > 0.75
ORDER BY score DESC
LIMIT 10;
-- Full-text search con BM25
DEFINE INDEX doc_search ON documents
FIELDS title, body
SEARCH ANALYZER ascii BM25;
SELECT title, search::score(1) AS relevance
FROM documents
WHERE title @1@ 'surrealdb tutorial'
ORDER BY relevance DESC;Para un pipeline RAG, esto es revolucionario. En el stack tradicional necesitás Pinecone (o Qdrant, o Weaviate) para los vectores más Elasticsearch (o Typesense) para el full-text, más una capa de orquestación que combine los resultados. Con SurrealDB, todo eso es un solo query. Un solo servicio. Una sola fuente de verdad.
Live Queries: Tiempo Real Sin Redis Ni WebSockets Propios
Una de las features más subestimadas de SurrealDB son las Live Queries. Con una sola instrucción, tu cliente se suscribe a cambios en los datos y los recibe en tiempo real por WebSocket — sin implementar polling, sin Redis pub/sub, sin infraestructura adicional:
-- El servidor emite un evento cada vez que cambia esta query
LIVE SELECT * FROM orders WHERE status = 'pending';
-- En el cliente (JavaScript SDK)
const db = new Surreal();
await db.connect('ws://localhost:8000');
const queryUuid = await db.live('orders', (action, result) => {
if (action === 'CREATE') console.log('Nueva orden:', result);
if (action === 'UPDATE') console.log('Orden actualizada:', result);
if (action === 'DELETE') console.log('Orden eliminada:', result.id);
});Para aplicaciones de colaboración en tiempo real, dashboards en vivo, feeds de actividad, o cualquier sistema donde los usuarios necesitan ver cambios al instante — esto colapsa semanas de infraestructura en diez líneas de código.
Autenticación y Permisos Nativos: El Fin del Middleware de Auth
Esto es lo que más sorprende a quienes vienen del mundo relacional: SurrealDB tiene un sistema de autenticación y autorización integrado en el engine. Podés definir reglas de acceso a nivel de tabla y de registro usando SurrealQL. El frontend puede conectarse directamente a la base de datos — con el usuario autenticado — y la base de datos enforcea los permisos automáticamente.
-- Definir acceso por registro: usuarios ven solo sus propias notas
DEFINE TABLE notes SCHEMAFULL
PERMISSIONS
FOR select WHERE owner = $auth.id
FOR create WHERE $auth.id != NONE
FOR update, delete WHERE owner = $auth.id;
DEFINE FIELD owner ON notes TYPE record<user>
DEFAULT $auth.id;
-- Definir scope de autenticación con JWT
DEFINE ACCESS user ON DATABASE TYPE RECORD
SIGNUP (CREATE user SET email = $email, pass = crypto::argon2::generate($pass))
SIGNIN (SELECT * FROM user WHERE email = $email AND crypto::argon2::compare(pass, $pass))
DURATION FOR SESSION 7d;Con esto podés tener un frontend que habla directamente con SurrealDB — sin backend intermediario para las operaciones CRUD básicas. Para aplicaciones donde el cuello de botella es la velocidad de desarrollo, esto es un cambio de juego. Auth0, Supabase Auth, los middleware de verificación de JWT — muchos de esos dejan de ser necesarios.
SurrealDB Como "Context Layer" Para Agentes de AI
El equipo de SurrealDB no está siendo tímido sobre su apuesta principal para 2026: quieren ser la capa de contexto para agentes de AI. Su tesis es concreta: los agentes de AI no fallan por los modelos — fallan por el contexto. Y el contexto necesita ser almacenado, consultado y actualizado en tiempo real.
Un agente moderno necesita: memoria episódica (qué pasó en conversaciones anteriores), memoria semántica (qué sabe sobre el mundo, en vectores), grafos de conocimiento (relaciones entre entidades), y datos estructurados (hechos concretos). El problema con el stack actual es que cada uno de esos tipos de memoria vive en un sistema distinto — y el agente tiene que orquestar consultas a cuatro lugares antes de responder.
Con SurrealDB, un agente puede guardar un hecho estructurado, crear una relación en el grafo de conocimiento, indexar el embedding de una conversación, y hacer un hybrid search sobre todo eso — en el mismo query, contra el mismo sistema. La latencia de contexto — el tiempo que tarda un agente en "recordar" lo relevante — colapsa.
"Los agentes fallan por el contexto, no por los modelos." — SurrealDB team. Y tienen razón: un GPT-4 con mala memoria es menos útil que un modelo más chico con contexto preciso.
Deployment: Desde el Browser Hasta el Cluster Distribuido
Una de las ventajas de estar escrito en Rust es que SurrealDB puede compilarse a múltiples targets sin cambiar nada del código:
Embebido en tu aplicación — sin proceso separado, sin servidor, ideal para apps desktop, herramientas CLI o testing. Servidor standalone — una instancia, perfecta para proyectos pequeños y medianos. Cluster distribuido — con TiKV como storage backend para escalar horizontalmente. WebAssembly en el browser — sí, SurrealDB puede correr completamente en el cliente, sin red, ideal para apps offline-first. Edge Functions — con soporte para Cloudflare Workers y entornos serverless.
El mismo código de queries que usás en development embebido funciona en el cluster de producción sin modificación. El modelo de datos no cambia según el target — solo la infraestructura debajo.
Lo Que Todavía le Falta: Honestidad Antes del Hype
Sería deshonesto no mencionar las limitaciones reales. SurrealDB tiene apenas cuatro años y se nota:
El ecosistema de herramientas de terceros es pequeño — no hay una fracción del tooling que tiene PostgreSQL. Los ORMs maduros, las herramientas de migración, los conectores de BI — todavía son escasos o están en beta.
Los benchmarks de performance a escala masiva son incompletos — para datasets de cientos de millones de registros, PostgreSQL y MongoDB tienen años de battle-testing que SurrealDB no tiene todavía.
La curva de aprendizaje es real — SurrealQL es familiar pero tiene conceptos nuevos (record links, graph traversal, scopes de auth) que toman tiempo en internalizarse.
La promesa multi-modelo tiene un trade-off — cuando necesitás exprimir la performance máxima de una sola dimensión (solo documentos, solo grafos, solo vectores), una herramienta especializada siempre va a ganar. SurrealDB gana en el caso general, no en los extremos.
Cuándo Usar SurrealDB (y Cuándo No)
Tiene mucho sentido cuando estás construyendo algo nuevo con un equipo chico y el tiempo al mercado importa. Cuando necesitás múltiples modelos de datos y no querés mantener cinco servicios. Cuando construís agentes de AI que necesitan memoria persistente y búsqueda semántica. Cuando el grafo de relaciones es central en tu dominio (redes sociales, sistemas de recomendación, knowledge bases). Cuando querés un backend donde el frontend se conecta directamente con auth nativa.
Probablemente no es la elección correcta cuando ya tenés un stack consolidado en producción con years de data y migrar tiene un costo altísimo. Cuando necesitás compliance certificado con regulaciones específicas que SurrealDB todavía no tiene auditorías para. Cuando tu caso de uso es puramente OLAP con queries analíticas complejas sobre petabytes — ahí un warehouse dedicado sigue ganando.
La Pregunta de Fondo: ¿Es el Futuro o Es Hype?
La historia de las bases de datos está llena de proyectos ambiciosos que prometieron unificar todo y terminaron siendo un jack-of-all-trades que no hacía nada bien. El escepticismo es razonable.
Pero hay algo diferente en SurrealDB. Primero, está construido sobre Rust — lo que le da una base de performance y seguridad de memoria que los proyectos anteriores no tenían. Segundo, el timing es perfecto: el mundo necesita desesperadamente una solución para el problema del contexto en agentes de AI, y SurrealDB es el primer sistema que lo ataca de frente con una arquitectura coherente. Tercero, los 32.000 estrellas en GitHub y la adopción creciente no mienten — hay algo genuino acá.
El mundo de las bases de datos estuvo definido durante 50 años por dos paradigmas: relacional y no-relacional. Luego vino la era de los especializados: bases de grafos, vectores, series de tiempo. SurrealDB propone que esa fragmentación fue un accidente histórico, no una necesidad técnica — que con suficiente potencia de cómputo y un diseño cuidadoso, todo puede vivir junto.
La pregunta no es si SurrealDB va a reemplazar a PostgreSQL. La pregunta es si va a hacer irrelevante tener que elegir entre PostgreSQL, MongoDB, Neo4j y Pinecone para cada nuevo proyecto.
Para el tipo de aplicaciones que se están construyendo hoy — agentes de AI, sistemas colaborativos en tiempo real, plataformas donde el grafo de relaciones es el producto — la respuesta está siendo, cada vez más, que sí.
Probalo. La curva de aprendizaje es real, pero el momento en que hacés tu primer traversal de grafo unificado con una búsqueda vectorial en el mismo query — vas a entender por qué la gente que usa SurrealDB no vuelve.