Le P99 de MySQL a atteint 48 secondes sur les sessions IA. PolarDB-X l'a ramené à 1.5 seconde.

Les assistants IA ont changé ce à quoi ressemble une ligne de base de données. Une session d'agent de codage regroupe des conversations multitours, des extraits de code et des résultats d'appels d'outils en des centaines de tours empilés ; un chatbot doit mémoriser le contexte sur plusieurs jours. Un message passe désormais de quelques KB à plusieurs MB, et le volume des sessions, de millions à des centaines de millions. L'équipe PolarDB-X d'Alibaba Cloud appelle cela le problème de stockage auquel MySQL n'a toujours pas de réponse standard.

L'article rappelle la fenêtre de contexte de 4K tokens de l'ère GPT-3, les 128K de GPT-4, et Claude Opus 4 à 1M tokens. Une capture de session pèse quelques MB cette année, écrit l'équipe, peut-être dix MB l'année prochaine.

MySQL était le seul écosystème sans chemin standard

PostgreSQL, MongoDB et Redis disposent tous de solutions éprouvées pour les sessions IA : jsonb est le checkpointer par défaut de LangGraph, MongoDB sert de backend au chat store de LlamaIndex, et Redis fournit un serveur de mémoire d'agent officiel. Le tableau comparatif du blog se distingue par son grand absent : MySQL.

Les deux approches MySQL les plus courantes échangent un problème contre un autre. Stocker le contenu dans une colonne LONGTEXT InnoDB est simple et transactionnel, mais la colonne volumineuse partage le chemin de données avec les champs ordinaires : le binlog gonfle, la réplication s'essouffle, et le buffer pool se trouve comprimé à mesure que l'échelle augmente. Conserver uniquement les métadonnées dans MySQL et les charges utiles sur OSS réduit les coûts, mais reporte sur la couche applicative la cohérence transactionnelle, la gestion du cycle de vie et les opérations impliquant deux systèmes.

La réponse de PolarDB-X est un mot-clé. Ajouter EXTERNALIZE à une colonne LONGTEXT laisse INSERT, SELECT et DELETE inchangés, et l'article insiste sur le fait que les ORM comme MyBatis et JPA, ainsi que les frameworks comme LangChain et LlamaIndex, ne nécessitent aucune adaptation. Le moteur achemine les données en fonction de la taille de la colonne au niveau de la couche de calcul. Les colonnes d'environ 100 KB partent directement vers OSS, seule une adresse de blob entrant dans le binlog ; les fractionnements de pages LOB et les goulots d'étranglement de réplication disparaissent, une écriture OSS en échec effectue toujours un rollback, et un GC en arrière-plan nettoie les orphelins. Les colonnes d'environ 1 KB atterrissent dans une table de staging InnoDB locale, si bien que la latence d'écriture égale celle d'un insert ordinaire, et un flush en arrière-plan les déplace vers OSS par lots. La suppression est elle aussi intégrée au moteur : le GC suit le mécanisme de purge d'InnoDB et la vue globale de transaction active minimale, remplaçant les scripts de réconciliation écrits à la main.

L'écart des benchmarks : de 48.7 secondes à 1.5 seconde

Mesurées sous des schémas identiques avec 256 clients concurrents, les écritures se présentent ainsi :

À 2 MB, la latence de queue P99 d'InnoDB atteint 48.7 secondes tandis que les colonnes externes restent à 1.5 seconde. La conclusion de l'article : une colonne de 1 KB s'écrit aussi vite qu'avec InnoDB directement, une colonne de 100 KB relègue InnoDB un ordre de grandeur derrière en cas de forte concurrence ; les colonnes externes devraient donc être le choix par défaut.

Ce sont des chiffres mesurés par le fournisseur, une réserve à garder à l'esprit, et le blog lui-même liste deux limites honnêtes. Les lectures à froid ont un surcoût : un cache miss entraîne une récupération depuis OSS en 20+ ms. Les colonnes externes ne peuvent pas être indexées : ni index secondaires, ni scans de plage, ni requêtes LIKE. Cela convient à un contenu récupéré intégralement par clé primaire, tandis que les champs interrogeables comme session_id restent indexés. L'indexation plein texte pour les colonnes de texte externes figure sur la feuille de route, selon l'article.

Conçu pour le schéma lecture après écriture

Les sessions IA sont dominées par des lectures juste après les écritures, lorsque l'application reconstitue le contexte pour le tour suivant. Le cache à quatre niveaux sert ce schéma : mémoire locale, SSD local, cache d'un autre nœud via RPC, et OSS comme solution de repli finale. Les lectures à chaud sont présentées comme impossibles à distinguer d'une requête sur colonne ordinaire. Une seule réponse d'assistant peut même être répartie entre des colonnes externalisées distinctes, contenu, pièces jointes, tool_calls et raisonnement, chacune avec sa propre entrée de cache, si bien que la chaîne de pensée que des modèles comme DeepSeek-R1 ou Qwen QwQ émettent intégralement vit sur OSS presque en permanence.

Les bases de connaissances RAG, les journaux d'audit et les fichiers médias correspondent au même schéma. Alibaba Cloud a déjà poussé dans cette direction : ses ingénieurs avaient auparavant documenté le passage de pgvector à l'échelle du milliard de vecteurs sur PolarDB pour PostgreSQL avec des réponses en millisecondes.

La validation indépendante reste la question ouverte. Et la lacune de l'écosystème MySQL était bien assez réelle pour que des équipes construisent leur propre logique de compensation pendant des années. Ce que PolarDB-X propose, c'est un mot-clé qui fait assumer au moteur la complexité que l'application portait auparavant. Savoir si cela tient à l'échelle de quelqu'un d'autre est une question à laquelle seul le trafic de production répondra.