El P99 de MySQL llegó a 48 segundos en sesiones de IA. PolarDB-X lo redujo a 1.5

Los asistentes de IA cambiaron el aspecto de una fila de base de datos. Una sesión de agente de codificación acumula chats de varios turnos, fragmentos de código y resultados de llamadas a herramientas en cientos de turnos apilados; un chatbot debe recordar el contexto a lo largo de días. Un mensaje ahora crece de KB a MB, y el volumen de sesiones, de millones a cientos de millones. El equipo de PolarDB-X de Alibaba Cloud llama a esto el problema de almacenamiento para el que MySQL aún no tiene una respuesta estándar.

El artículo recuerda la ventana de contexto de 4K tokens de la era de GPT-3, los 128K de GPT-4 y Claude Opus 4 con 1M de tokens. Una instantánea de sesión ocupa unos pocos MB este año, escribe el equipo, quizá diez MB el año que viene.

MySQL era el único ecosistema sin una ruta estándar

PostgreSQL, MongoDB y Redis tienen soluciones probadas para sesiones de IA: jsonb es el checkpointer predeterminado de LangGraph, MongoDB respalda el chat store de LlamaIndex, y Redis incluye un servidor oficial de memoria para agentes. La tabla comparativa del blog destaca por quién brilla por su ausencia: MySQL.

Las dos rutas convencionales de MySQL intercambian un problema por otro. Almacenar contenido en una columna LONGTEXT de InnoDB es simple y transaccional, pero la columna grande comparte la ruta de datos con los campos ordinarios: el binlog se infla, la replicación se tensa y el buffer pool se comprime a medida que crece la escala. Guardar solo los metadatos en MySQL y los payloads en OSS reduce costos, pero traslada la consistencia transaccional, la gestión del ciclo de vida y las operaciones en dos sistemas a la capa de aplicación.

La respuesta de PolarDB-X es una palabra clave. Agregar EXTERNALIZE a una columna LONGTEXT deja INSERT, SELECT y DELETE sin cambios, y el artículo subraya que ORMs como MyBatis y JPA, además de frameworks como LangChain y LlamaIndex, no requieren adaptación. El motor enruta según el tamaño de la columna en la capa de cómputo. Las columnas de alrededor de 100 KB van directamente a OSS, y solo una dirección de blob entra en el binlog, de modo que las divisiones de páginas LOB y los cuellos de botella de replicación desaparecen; una escritura fallida en OSS aún se revierte, y el GC en segundo plano limpia los huérfanos. Las columnas de alrededor de 1 KB aterrizan en una tabla de staging local de InnoDB, por lo que la latencia de escritura iguala a la de un insert simple, y un flush en segundo plano las mueve a OSS en lotes. La eliminación también se traslada al motor: el GC sigue el mecanismo de purge de InnoDB y la vista global de la transacción activa mínima, reemplazando los scripts de conciliación escritos a mano.

La brecha en los benchmarks: de 48.7 segundos a 1.5

Medido con esquemas idénticos y 256 clientes concurrentes, las escrituras se ven así:

A 2 MB, la latencia de cola P99 de InnoDB llega a los 48.7 segundos mientras que las columnas externas se mantienen en 1.5 segundos. La conclusión del artículo: una columna de 1 KB escribe tan rápido como InnoDB directamente; una columna de 100 KB lo deja un orden de magnitud atrás bajo alta concurrencia, por lo que las columnas externas deberían ser la opción predeterminada.

Son cifras medidas por el proveedor, una salvedad que conviene tener presente, y el propio blog enumera dos límites honestos. Las lecturas en frío pagan un costo extra: un fallo de caché recupera desde OSS en 20+ ms. Las columnas externas no se pueden indexar, por lo que no hay índices secundarios, escaneos por rango ni consultas LIKE. Eso se ajusta a contenido recuperado completo por clave primaria, mientras que campos buscables como session_id permanecen indexados. El índice de texto completo para columnas de texto externas está en el roadmap, según el artículo.

Diseñado para el patrón de lectura tras escritura

Las sesiones de IA están dominadas por lecturas inmediatamente después de las escrituras, cuando la aplicación reensambla el contexto para el siguiente turno. La caché de cuatro niveles sirve a ese patrón: memoria local, SSD local, la caché de otro nodo vía RPC y OSS como último recurso. Las lecturas en caliente se reportan como indistinguibles de una consulta a una columna ordinaria. Una sola respuesta del asistente puede incluso dividirse en columnas externalizadas separadas para contenido, adjuntos, tool_calls y razonamiento, cada una con su propia entrada de caché, de modo que la cadena de pensamiento que modelos como DeepSeek-R1 o Qwen QwQ emiten íntegra vive en OSS casi permanentemente.

Las bases de conocimiento RAG, los registros de auditoría y los archivos multimedia encajan en el mismo patrón. Alibaba Cloud ya había avanzado en esta dirección: sus ingenieros documentaron antes llevar pgvector a una escala de mil millones de vectores en PolarDB para PostgreSQL con respuestas en milisegundos.

La validación independiente sigue siendo la cuestión abierta. Y la brecha del ecosistema MySQL era lo suficientemente real como para que los equipos construyeran su propia lógica de compensación durante años. Lo que PolarDB-X ofrece es una palabra clave que hace que el motor asuma la complejidad que la aplicación solía cargar. Si eso se mantiene a la escala de otro, es una pregunta que solo responderá el tráfico de producción.