Servidores

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 euclidean y cosine. No hay dot product, L1 ni Hamming. Si tu modelo fue entrenado para trabajar con inner 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 de text-embedding-3-small 1536 a text-embedding-3-large 3072), 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 es ALTER 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/Aria y foreign keys combinando índice (MDEV-37022). Usa InnoDB por defecto para evitarlo.
  • El optimizador NO usa el índice si filtras por umbral sin LIMIT (WHERE VEC_DISTANCE(...) < X sin ORDER 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

Alfonso Moreno | Sysadmin Senior

Soy Alfonso, sysadmin senior con RHCE y más de 10 años administrando sistemas Linux para empresas y proyectos personales. Me especializo en infraestructura, redes, virtualización, monitoring, automation y self-hosting. Sobre SoyLinux.com SoyLinux.com es un blog técnico en español sobre Linux, software libre y self-hosting. Lo mantengo en mi tiempo libre. Áreas de expertise - Linux server administration: RHEL, CentOS, Rocky, Alma, Fedora, Debian, Ubuntu - Network services: Postfix, BIND, Samba, NFS, Squid - Virtualización y containers: KVM, Proxmox, Docker, Podman - Monitoring: Prometheus, Grafana, Zabbix - Automation: Ansible, Bash scripting - Self-hosting: Vaultwarden, Nextcloud, Jellyfin, Immich, Homelab Contacto - Email: [email protected]

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *