MariaDB Vector y los LLMs: por qué tu coding assistant no lo sugiere
TL;DR — Lo que vas a tener al final
- Tiempo de setup: 2-3 horas para el primer LLM funcionando.
- Requisitos: GPU NVIDIA con 12+ GB VRAM (RTX 3060 mínimo).
- Resultado: LLM local con API OpenAI-compatible, integrable con n8n/Open WebUI.
- Troubleshooting: nvidia-smi, ollama ps, OOM con modelos grandes.
El problema: tu LLM no sabe que MariaDB tiene vector search
El 24 de septiembre de 2026, en la conferencia Percona Live, el chairman ejecutivo de la MariaDB Foundation, Kaj Arnö, soltó una queja que resume un punto ciego del vibecoding: los asistentes de código — Claude Code, GitHub Copilot, Cursor, Gemini Code Assist — siguen recomendando PostgreSQL con pgvector, Pinecone, Qdrant o Chroma cuando les preguntas qué base de datos usar para búsqueda por similitud. Casi nunca mencionan MariaDB, aunque MariaDB tiene búsqueda vectorial nativa desde la versión 11.7 (preview) y como GA desde 11.8 LTS, publicada en mayo de 2025.
La queja no es solo de marketing. Arnö lo dice así: si haces vibecoding y simplemente presionas Enter cuando Claude Code sugiere algo, no vas a terminar usando MariaDB para tu vector search, y eso es lo que tenemos que cambiar. Para el sysadmin Linux que mantiene stacks relacionales clásicos y quiere añadir capacidades RAG, retrieval o búsqueda semántica, esto significa que está eligiendo stack por inercia de LLM, no por ajuste técnico.
Qué es MariaDB Vector y qué lo diferencia
MariaDB Vector es búsqueda por similitud nativa dentro del servidor MariaDB. No requiere extensión, plugin ni servidor adicional. El tipo de dato VECTOR(N) almacena embeddings como floats IEEE 754 de 32 bits, hasta 16.383 dimensiones. Los índices usan una variante modificada de HNSW (Hierarchical Navigable Small Worlds), con quantización int16 — 15 bits por valor, frente a los 10 bits de float16 que usa pgvector — lo que da índices más compactos para la misma precisión aproximada.
Las funciones de distancia soportadas son VEC_DISTANCE_EUCLIDEAN (L2, por defecto) y VEC_DISTANCE_COSINE. La inserción se hace con VEC_FromText('[...]') que toma un array JSON de floats; la lectura usa VEC_ToText(). Hay aceleración SIMD nativa en x86_64 (AVX2/AVX512), aarch64 NEON y Power10 VSX, así que el rendimiento no depende solo del algoritmo sino del hardware donde corre.
Por qué los LLMs no lo sugieren (y por qué les compete a los sysadmins)
Arnö apunta a un problema de entrenamiento y de documentación. Los LLMs que están sugiriendo stacks hoy fueron entrenados, en parte significativa, antes de que MariaDB Vector estuviera disponible en LTS. Además, la documentación y los ejemplos que se ven en frameworks como LangChain, LlamaIndex y Spring AI seguían favoreciendo alternativas más antiguas. El resultado: cuando le preguntas a un LLM “¿qué base de datos uso para vectors?”, si no mencionas MariaDB explícitamente, casi nunca lo trae como opción. Hay un millón de lugares donde necesitamos actualizar cosas para que los frameworks, los datos de entrenamiento de los LLMs y todo eso sepa de la existencia de MariaDB vectors, dice Arnö.
Para el sysadmin Linux esto tiene un ángulo práctico. Si tu stack ya corre MariaDB (muchas distros lo incluyen por defecto — Debian, Ubuntu, Fedora, RHEL, AlmaLinux), añadir búsqueda vectorial no significa desplegar Postgres con pgvector, ni mantener un Qdrant separado, ni pagar Pinecone. Significa CREATE TABLE ... VECTOR(N) en la misma base de datos donde ya viven tus datos transaccionales. Una sola transacción ACID, una sola réplica, un solo backup.
Cómo se usa en la práctica
La sintaxis es SQL estándar extendido. Empezás creando la columna vectorial con su índice HNSW, insertás embeddings que vienen de tu modelo (OpenAI, sentence-transformers, Cohere, el que uses) y ejecutas el nearest-neighbor con la función de distancia correspondiente. Lo crítico: el optimizador solo usa el índice vectorial cuando el ORDER BY es la llamada literal a VEC_DISTANCE_*(columna, vector) y hay un LIMIT. Si envolvés la distancia en una expresión (por ejemplo, para devolver un score 1 - cosine) o filtrás por umbral sin LIMIT, el índice no se usa y caés a full table scan.
-- 1. Crear tabla con columna vectorial + índice HNSW
CREATE TABLE documents (
id BIGINT UNSIGNED PRIMARY KEY,
owner_id BIGINT,
content TEXT,
embedding VECTOR(1536) NOT NULL, -- ajustar dimensión a tu modelo
VECTOR INDEX (embedding) M=8 DISTANCE=cosine
) ENGINE=InnoDB;
-- 2. Insertar embedding (VEC_FromText toma JSON array de floats)
INSERT INTO documents (id, owner_id, content, embedding)
VALUES (1, 42, 'documento de prueba', VEC_FromText('[...]'));
-- 3. Buscar los 10 más cercanos filtrando por owner_id
SELECT id, content
FROM documents
WHERE owner_id = 42
ORDER BY VEC_DISTANCE(embedding, VEC_FromText('[...]'))
LIMIT 10;
El parámetro M controla la conectividad del grafo HNSW. Valores válidos: 3 a 200. Más alto = SELECT y INSERT más lentos, índice más grande, más memoria, pero resultados más precisos. Para prototipos M=8 o M=16 es razonable; para producción ajustá con tu carga real.
MariaDB vs pgvector: cuándo elegir cada uno
| Criterio | MariaDB Vector (11.8+) | Postgres + pgvector |
|---|---|---|
| Tipo de instalación | Nativo, sin extensión | Requiere extensión pgvector |
| Algoritmo de índice | HNSW modificado, int16 | HNSW (float16/quantized) e IVF |
| Distancias soportadas | Euclidean, Cosine | Euclidean, Cosine, Inner Product, L1, Hamming |
| Dimensiones máximas | 16.383 | 64.000 (limitado por configuración) |
| ACID con datos relacionales | Sí, una sola transacción | Sí, una sola transacción |
| Ecosistema LLM / framework | Creciendo (LangChain, LlamaIndex, Spring AI, MCP server) | Amplio, más maduro en ejemplos públicos |
| Madurez en producción | Funcional, aún joven (GA mayo 2025) | Más tiempo en producción, comunidad grande |
| Backups y replicación | Mariabackup / binlog estándar | pg_dump / WAL estándar |
La regla operativa para sysadmins Linux: si tu aplicación corre en MySQL/MariaDB y quieres añadir búsqueda semántica sin desplegar un segundo motor de base de datos, MariaDB Vector te ahorra una pieza de infraestructura. Si ya estás en Postgres y solo vas a usar vectorial, pgvector tiene más ejemplos públicos, más métricas de distancia y una comunidad más grande. Si vas a hacer búsqueda vectorial a escala masiva con cardinalidad muy alta, las bases vectoriales especializadas (Qdrant, Weaviate, Milvus) siguen siendo la opción para casos de uso serios, según evaluación.
Limitaciones reales que conviene conocer
MariaDB Vector es funcional pero aún joven comparada con pgvector. Las limitaciones concretas que la documentación oficial y la comunidad reportan:
- Solo soporta distancias
euclideanycosine. No haydot product,L1niHamming. Si tu modelo fue entrenado para trabajar coninner product, tienes que adaptarlo. - La dimensión
VECTOR(d)se fija al crear la tabla. Si tu embedding model cambia de dimensionalidad (por ejemplo, pasas detext-embedding-3-small1536 atext-embedding-3-large3072), necesitas migración de tabla. No hay “reshape automático” - Los índices se actualizan eager durante
INSERT. En cargas de carga masiva (bulk loads), el patrón recomendado esALTER TABLE ... DISABLE KEYS, hacer bulk insert, y volver a habilitar. Sin esto, insertar millones de filas puede ser muy lento. - Solo se permite un índice vectorial por tabla, y la columna indexada debe ser
NOT NULL. - En versiones anteriores a 11.8.3 había un bug con
MyISAM/Ariay foreign keys combinando índice (MDEV-37022). UsaInnoDBpor defecto para evitarlo. - El optimizador NO usa el índice si filtras por umbral sin
LIMIT(WHERE VEC_DISTANCE(...) < XsinORDER BY ... LIMIT). Esto es por diseño — el índice solo sirve para k-nearest-neighbor.
Cómo lo ven los frameworks
LangChain tiene langchain-mariadb en PyPI. LangChain.js incluye MariaDB vector store built-in. LangChain4j (Java) y Spring AI también lo soportan built-in. LlamaIndex tiene MariaDB vector store. Para Python, el driver oficial es pip install mariadb. Si vas a alimentar el LLM con resultados, puedes usar VEC_FromText() directamente desde json.dumps().
MariaDB Corporation publicó un servidor MCP (Model Context Protocol) en github.com/mariadb/mcp, que permite que los coding assistants expongan operaciones de MariaDB como tools. Esto apunta directamente a la queja de Arnö: cuando un LLM tiene acceso vía MCP a una base MariaDB Vector, deja de “no saber” que existe.
Verificación práctica: ¿mi MariaDB tiene vector search?
Antes de planear una migración, confirmá que tu servidor soporta vector search. La versión mínima es MariaDB Community Server 11.7 (rolling release) o 11.8 LTS (GA, mayo 2025) para tenerlo GA completo. MariaDB Enterprise lo tiene backported a 11.4.5-3 en adelante.
# Confirmar versión
mysql --version
# MariaDB Community Server 11.8.x o superior
# Confirmar que el tipo VECTOR existe
mysql -u root -p -e "SHOW CREATE TABLE testG" 2>/dev/null
# Si el server es 11.7/+, prueba crear una tabla mínima:
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS vec_test;
USE vec_test;
CREATE TABLE v (id INT PRIMARY KEY, e VECTOR(3) NOT NULL, VECTOR INDEX(e));
INSERT INTO v VALUES (1, VEC_FromText('[0.1, 0.2, 0.3]'));
SELECT id, VEC_ToText(e) FROM v;
DROP DATABASE vec_test;"
Si la creación de la tabla pasa sin error y el SELECT VEC_ToText devuelve el array JSON, tu MariaDB tiene vector search nativo. Si falla con error de sintaxis cerca de VECTOR o VEC_FromText, estás en una versión anterior a 11.7 o un MySQL (MySQL no tiene vector search built-in, solo Oracle HeatWave lo soporta como add-on comercial).
Resumen
Si eres sysadmin y tienes MariaDB en producción, MariaDB Vector te da búsqueda semántica sin desplegar infraestructura adicional: misma base, mismo backup, misma réplica, transacciones ACID unificadas. Si ya estás en Postgres, pgvector sigue siendo la opción más documentada y con más métricas. Si estás eligiendo stack desde cero para un proyecto AI-native, vale la pena mirar MariaDB Vector como opción además de las especializadas — sobre todo si quieres mantener tu stack SQL estándar sin sumar piezas vectoriales dedicadas. Y cuando le pidas a tu coding assistant que te arme un RAG, menciona explícitamente MariaDB en el prompt — los LLMs, hoy, no lo sugieren solos.
Preguntas frecuentes
¿Por qué MariaDB Vector y los LLMs: por qué tu coding assistant no lo sugiere es relevante para sysadmins Linux?
Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.
¿Qué necesito para empezar con MariaDB Vector y los LLMs:?
Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.
¿Cuáles son los errores más comunes con MariaDB Vector y los LLMs:?
Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.
¿Cuándo usar MariaDB Vector y los LLMs: y cuándo una alternativa?
Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.
¿Cómo migro desde una configuración previa a MariaDB Vector y los LLMs:?
Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.
Lee también
- Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
- Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
- Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
- Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
- Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux
