SurrealDB es la base de datos que viene a solucionar el problema de tener muchas bases de datos para problemas especializados con solo una, para ahorrar costes de mantenimiento, y simplificar la estructura, esta base de datos puede funcionar como una base de datos SQL, NoSQL, por grafos, he incluso como Elasticsearch para la búsqueda de texto.
Si no sabes que es una base de datos puedes clicar aquí para saberlo.
Índice
SurrealQL: El lenguaje que lo unifica todo.
Este es el lenguaje que usa esta base de datos, unifica tanto SQL como NoSQL como grafos, llamado SurrealQL. A primera vista resulta muy familiar porque su sintaxis se inspira fuertemente en SQL tradicional, lo que reduce la curva de aprendizaje. Sin embargo, cambia por completo el paradigma al eliminar la necesidad de realizar los costosos y complejos JOIN tradicionales. En el procesamiento de grandes volúmenes de información, típico al diseñar arquitecturas para ciencias de datos, evitar el producto cartesiano y los escaneos de índices múltiples es fundamental para el rendimiento. En su lugar, SurrealDB permite navegar por los datos utilizando punteros directos (Record Links) y relaciones de grafos.
Punteros (Record Links): El reemplazo natural de los JOINs
En bases de datos relacionales estándar, para unir dos tablas necesitas usar claves foráneas y la cláusula JOIN, lo que implica cruzar información en tiempo de consulta. SurrealDB soluciona esto permitiendo que un campo almacene un enlace directo al ID de otro registro. No es una búsqueda en un índice, es una referencia directa en memoria/disco, reduciendo tiempos de latencia drásticamente (por ejemplo, bajando tiempos de respuesta a 1,5 milisegundos en consultas complejas).
-- Creamos un registro independiente
CREATE autor:borges SET nombre = 'Jorge Luis Borges';
-- Creamos un documento y usamos un puntero (Record Link) al autor
CREATE libro:aleph SET
titulo = 'El Aleph',
escritor = autor:borges; -- Esto es un puntero directo, sin tablas intermedias
-- Para hacer el equivalente a un JOIN, simplemente usamos la notación de punto (.)
SELECT titulo, escritor.nombre AS nombre_autor FROM libro:aleph;
Relaciones de Grafos: Navegación semántica
Cuando la estructura de la información es más compleja y la relación en sí misma tiene propiedades (por ejemplo, saber exactamente cuándo un usuario interactuó con un contenido), los punteros simples se quedan cortos. Aquí es donde entran los grafos. En lugar de crear complejas tablas intermedias (tablas pivote), SurrealQL usa relaciones dirigidas mediante flechas que conectan los vértices o nodos.
Aquí tienes un ejemplo de cómo se combinan documentos y grafos en unas pocas líneas:
-- Crear registros (Modelo Documental / NoSQL)
CREATE usuario:ana SET nombre = 'Ana', profesion = 'Data Scientist';
CREATE post:analitica SET titulo = 'Introducción a SurrealDB', tags = ['bd', 'grafos'];
-- Crear una relación directa (Modelo de Grafos) añadiendo propiedades a la relación
RELATE usuario:ana->escribio->post:analitica SET fecha = time::now(), version = 1,2;
-- Consultar usando la relación de grafo sin usar JOINs
-- La sintaxis con flechas navega directamente del usuario al post
SELECT ->escribio->post.titulo AS articulos_publicados FROM usuario:ana;
La gran duda: ¿Cuándo usar Punteros y cuándo usar Grafos?
A la hora de diseñar la arquitectura de los datos, elegir entre un puntero directo o una relación de grafos es una decisión crítica. En el diseño de estructuras para ingeniería de software o analítica avanzada de datos, optimizar este paso te puede llegar a ahorrar un 99,9% de escaneos innecesarios en disco comparado con una base de datos tradicional.
Para no complicarte, la regla de oro se basa en la complejidad de la propia relación:
- Usa Punteros (Record Links) cuando: La relación es simple, directa (1:1 o 1:N) y no tiene atributos propios. Es el equivalente directo a una clave foránea (Foreign Key) clásica.
Ejemplo: Unsensorque pertenece a unaestacion_meteorologica. El hecho de pertenecer a la estación no tiene una fecha de inicio, un estado o un peso estadístico; simplemente es una propiedad estática del sensor. Es la opción más ligera en memoria. - Usa Grafos (Relaciones con flechas
->) cuando: Necesitas modelar relaciones Muchos a Muchos (N:M) o cuando la relación en sí misma contiene información (metadatos). En lugar de ensuciar el diseño creando una tabla intermedia o pivote, creas una arista (edge) entre los vértices.
Ejemplo: Unusuarioquecompraunproducto. Esa acción de «comprar» no pertenece ni al usuario ni al producto; es un evento que tiene una fecha, una cantidad, una pasarela de pago y un importe concreto (ej.precio = 45,50).
En resumen: si solo necesitas «apuntar» de un lado a otro para leer un dato, usa un puntero. Si la conexión entre ambos datos es un evento o tiene propiedades que necesitas analizar después, usa un grafo.
Schemafull vs. Schemaless: Control absoluto vs. Flexibilidad total.
Una de las mayores ventajas arquitectónicas de SurrealDB es que no te obliga a elegir un bando desde el principio. Puedes combinar ambos enfoques dentro de la misma base de datos, dependiendo de la tabla.
- Schemaless (Sin esquema): Es el comportamiento por defecto. Es ideal para las fases iniciales de desarrollo, prototipado rápido o cuando ingestas datos no estructurados donde la morfología de los documentos cambia constantemente.
- Schemafull (Con esquema estricto): Cuando tu aplicación pasa a producción o necesitas asegurar la integridad y calidad de los datos, puedes bloquear la tabla. Esto te permite definir qué campos son obligatorios, sus tipos de datos y validar su contenido (por ejemplo, asegurar que un campo sea un email válido).
Ejemplo de cómo aplicar un esquema estricto:
-- Hacemos que la tabla usuario sea estricta
DEFINE TABLE usuario SCHEMAFULL;
-- Definimos los campos permitidos y sus validaciones
DEFINE FIELD email ON TABLE usuario TYPE string ASSERT string::is::email($value);
DEFINE FIELD edad ON TABLE usuario TYPE number ASSERT $value >= 18;
-- Esto dará error porque falta el email y la edad no cumple la condición:
CREATE usuario:nuevo SET edad = 16;
Arquitectura subyacente: ¿Cómo funciona realmente el motor?
Esta base de datos tiene varios motores, dependiendo de tu caso de uso puedes usar uno u otro, todas son motores clave valor.
Motores de un solo nodo
- SurrealKV: Este es el motor desarrollado por la misma gente de SurrealDB, con la intención de sustituir a RocksDB, ya que viene con muchas funcionalidades que no necesita esta base de datos.
- RocksDB: Este motor fue creado por los de Facebook con un propósito general, con guardado a niveles, ya hablaremos de esta base de datos en otro momento.
Motores para Clústeres Distribuidos
- TiKV: La opción predilecta para escalar horizontalmente. Es un almacén clave-valor transaccional fuertemente consistente. Se utiliza para montar clústeres de SurrealDB con alta disponibilidad y tolerancia a fallos para manejar terabytes de información en producción.
- FoundationDB: Una alternativa distribuida (respaldada por Apple) famosa por ofrecer las garantías transaccionales ACID más estrictas del mercado a escala masiva, gestionando la concurrencia de forma impecable.
Motores de Desarrollo
En este caso solo esta In-memory, este motor es muy parecido al de MariaDB, usando este motor los datos no se guardan en disco nunca si no en memoria, por lo que es ultra rápido (ofreciendo latencias de lectura de apenas 1,5 milisegundos), pero si reinicias el equipo pierdes todos los datos.
Motores para navegador
Para este caso solo existe por ahora IndexedDB, este motor te permite ejecutar la base de datos en navegadores web o entornos de python, es muy interesante en el caso de que quieras trabajar en aplicaciones móviles.
Consultas en vivo:
Esta base de datos te permite hacer una cosa, las consultas en vivo, este tipo de consultas te permiten mantener una consulta abierta para que en el caso de que algo cambie te llegue los cambios, esto esta muy bien para el caso de que queramos hacer cosas que cambien en tiempo real, como dashboards analíticos, chats o sistemas de notificaciones, eliminando la necesidad de configurar infraestructuras complejas con Redis o WebSockets de forma manual.
-- Iniciar una consulta en vivo
LIVE SELECT * FROM sensor_temperatura WHERE valor > 40;
-- El servidor devolverá un UUID de la consulta.
-- A partir de ese momento, cualquier CREATE, UPDATE o DELETE que cumpla la condición
-- será empujado (pushed) directamente al cliente en tiempo real.
Construido en Rust:
A diferencia de motores consolidados en el mercado como PostgreSQL, MariaDB o MongoDB (tradicionalmente anclados en C o C++), el motor de SurrealDB está escrito completamente en Rust.
Esta decisión arquitectónica no es casualidad. Rust garantiza la seguridad de la memoria y erradica las fugas de recursos (memory leaks) por diseño en tiempo de compilación. Pero el verdadero impacto para una base de datos es que logra todo esto sin depender de un recolector de basura (Garbage Collector). El resultado es un motor capaz de manejar una concurrencia masiva con latencias predecibles, evitando los picos de lentitud repentinos que sufren otras tecnologías.
De la teoría a la práctica: Despliegue e Integración
La Jerarquía: Namespaces y Databases
Antes de poder insertar un solo dato en SurrealDB, necesitas entender su jerarquía. A diferencia de otras bases de datos donde simplemente creas una tabla, aquí existe un nivel superior diseñado para aislar entornos (por ejemplo, separar los datos de desarrollo, testing y producción dentro de un mismo clúster o servidor).
- Namespace (NS): Es el contenedor principal. Agrupa varias bases de datos.
- Database (DB): Vive dentro de un Namespace. Es aquí donde finalmente residen tus tablas y grafos.
-- Para empezar a trabajar, primero debes seleccionar el NS y la DB
USE NS mi_proyecto DB entorno_desarrollo;
Despliegue rápido con Docker
La forma más limpia y rápida de probar SurrealDB en tu equipo sin instalar nada a nivel de sistema es utilizando contenedores. Con un solo comando puedes levantar el servidor en memoria (ideal para pruebas, ya que al apagar el contenedor se limpia todo):
docker run --rm --pull always -p 8000:8000 surrealdb/surrealdb:latest start --user root --pass root memory
Integración con Python para la ingesta de datos
Para la manipulación de grandes volúmenes de datos, entrenamientos de modelos o creación de pipelines analíticos, Python es el rey. SurrealDB cuenta con un SDK oficial asíncrono que facilita enormemente la conexión y consulta.
Primero, instalamos la librería (pip install surrealdb) y luego ejecutamos nuestro script:
import asyncio
from surrealdb import Surreal
async def main():
# Conectamos al servidor local que levantamos con Docker
async with Surreal("ws://localhost:8000/rpc") as db:
# Nos autenticamos con las credenciales
await db.signin({"user": "root", "pass": "root"})
# Seleccionamos nuestro Namespace y Database
await db.use("mi_proyecto", "entorno_desarrollo")
# Insertamos un registro estructurado, ideal para dataframes
datos_sensor = {
"temperatura": 24,5,
"humedad": 60,
"ubicacion": "Servidor_Oeste"
}
# SurrealDB creará la tabla 'metrica' automáticamente si somos Schemaless
resultado = await db.create("metrica", datos_sensor)
print(f"Dato insertado correctamente: {resultado}")
# Ejecutamos el bucle asíncrono
if __name__ == "__main__":
asyncio.run(main())
El lado oscuro: Casos donde NO deberías usar SurrealDB.
Aunque promete ser la «herramienta definitiva», la realidad del software es que no existe la bala de plata. Hay escenarios donde apostar por SurrealDB podría ser un error:
- Ecosistema y Madurez: Si tu proyecto requiere una base de datos con décadas de pruebas en batalla, un soporte inmenso de la comunidad, y compatibilidad nativa con absolutamente todos los ORMs (Object-Relational Mappers) y herramientas de BI corporativas, PostgreSQL sigue siendo el rey. SurrealDB es joven y su ecosistema aún está madurando.
- Aplicaciones extremadamente simples: Si estás montando un blog básico o un CRUD sencillo donde una estructura de tablas normalizadas de toda la vida es más que suficiente, SurrealDB añade una capa de complejidad abstracta que no necesitas. SQLite o MySQL cumplirán de sobra.
- Equipos sin tiempo para aprender: SurrealQL es intuitivo, pero el cambio de paradigma mental de usar tablas estrictas a manejar grafos, esquemas dinámicos y eventos en vivo requiere tiempo. Si el equipo necesita entregar algo crítico en dos semanas y solo domina SQL estándar, la curva de aprendizaje inicial será un obstáculo.
Bibliografía y Referencias Técnicas
La información de este artículo se fundamenta en la documentación arquitectónica oficial y el código fuente de SurrealDB. Para profundizar en la ingeniería del motor subyacente o integrar esta base de datos en pipelines de análisis de datos con Python, puedes consultar los siguientes recursos específicos:
- Arquitectura y Motores de Almacenamiento: Detalles técnicos sobre cómo SurrealDB implementa SurrealKV, gestiona la concurrencia y se integra con TiKV o FoundationDB para clústeres distribuidos: Documentación de Arquitectura de SurrealDB.
- SurrealQL y Consultas en Vivo (Live Queries): Especificaciones del lenguaje, sintaxis para recorrer grafos sin JOINs y el funcionamiento interno del streaming de datos en tiempo real: Referencia de LIVE SELECT en SurrealQL.
- Definición de Esquemas (Schemafull vs Schemaless): Guía técnica sobre cómo aplicar aserciones y tipado estricto a las tablas usando la instrucción DEFINE: Instrucción DEFINE TABLE.
- Código Fuente en Rust: El repositorio oficial donde se puede auditar la implementación del motor, la gestión de memoria sin recolector de basura y las contribuciones de la comunidad: GitHub – surrealdb/surrealdb.
- Integración con Python (SDK): Documentación oficial para conectar y manipular la base de datos directamente desde entornos y scripts de Python: SurrealDB Python SDK.
