MySQL's P99 hit 48 seconds on AI sessions. PolarDB-X cut it to 1.5

AI assistants changed what a database row looks like. A coding-agent session packs multi-turn chats, code snippets, and tool-call results into hundreds of stacked turns, much of which never gets read again: Blast Radius, a preprint on agent context, puts that waste at 17-26%. A chatbot must remember context across days. One message now grows from KB to MB, and session volume from millions to hundreds of millions. Alibaba Cloud's PolarDB-X team calls this the storage problem MySQL still has no standard answer to.

The post recalls the GPT-3 era's 4K-token context window, GPT-4's 128K, and Claude Opus 4 at 1M tokens. A session snapshot runs to a few MB this year, the team writes, perhaps ten MB next year.

MySQL was the only ecosystem without a standard path

PostgreSQL, MongoDB, and Redis all have proven AI-session solutions: jsonb is the LangGraph default checkpointer, MongoDB backs LlamaIndex's chat store, and Redis ships an official agent memory server. The blog's comparison table is notable for who's absent: MySQL.

Both mainstream MySQL routes trade one problem for another. Storing content in an InnoDB LONGTEXT column is simple and transactional, but the large column shares the data path with ordinary fields: the binlog bloats, replication strains, and the buffer pool gets squeezed as scale grows. Keeping only metadata in MySQL and payloads on OSS cuts cost but pushes transaction consistency, lifecycle management, and two-system operations onto the application layer.

PolarDB-X's answer is a keyword. Adding EXTERNALIZE to a LONGTEXT column leaves INSERT, SELECT, and DELETE unchanged, and the post stresses that ORMs like MyBatis and JPA, plus frameworks like LangChain and LlamaIndex, need no adaptation. The engine routes by column size at the compute layer. Columns around 100 KB go straight to OSS, with only a blob address entering the binlog, so LOB page splits and replication bottlenecks vanish; a failed OSS write still rolls back, and background GC cleans up orphans. Columns around 1 KB land in a local InnoDB staging table, so write latency matches a plain insert, and a background flush moves them to OSS in batches. Deletion moves into the engine too: GC follows InnoDB's purge mechanism and the global minimum active transaction view, replacing handwritten reconciliation scripts.

The benchmark gap: 48.7 seconds down to 1.5

Under identical schemas at 256 concurrent clients, writes look like this:

At 2 MB, InnoDB's P99 tail latency reaches 48.7 seconds while external columns stay at 1.5 seconds. The post's conclusion: a 1 KB column writes as fast as InnoDB directly, a 100 KB column leaves it an order of magnitude behind under high concurrency, so external columns should be the default.

These are vendor-measured numbers, a caveat worth keeping, and the blog itself lists two honest boundaries. Cold reads pay a premium: a cache miss fetches from OSS in 20+ ms. External columns cannot be indexed, so no secondary indexes, range scans, or LIKE queries. That fits content fetched whole by primary key, while searchable fields like session_id stay indexed. Full-text indexing for external text columns is on the roadmap, per the post.

Built for the read-after-write pattern

AI sessions are dominated by reads right after writes, when the application reassembles context for the next turn, a pattern agent-memory research warns is fragile: stored turns can go stale, and stale memories are worse than none. The four-level cache serves that pattern: local memory, local SSD, another node's cache over RPC, and OSS as the final fallback. Hot reads are reported as indistinguishable from an ordinary column query. One assistant reply can even split into separate externalized columns for content, attachments, tool_calls, and reasoning, each with its own cache entry, so the chain-of-thought that models like DeepSeek-R1 or Qwen QwQ emit in full lives on OSS almost permanently. Traces only get longer: ThinkRetrieve argues sequential chain-of-thought hits diminishing returns as it grows.

RAG knowledge bases, audit logs, and media files fit the same pattern. Alibaba Cloud has pushed this direction before: its engineers earlier documented taking pgvector to billion-vector scale on PolarDB for PostgreSQL with millisecond responses. There's a business reason for the push: its NielsenIQ survey of 1,000 Asian IT decision makers found 95% raising AI budgets (the Alibaba Cloud study).

Independent validation remains the open question. And the MySQL ecosystem's gap was real enough that teams built their own compensation logic for years. What PolarDB-X offers is a keyword that makes the engine own complexity the application used to carry. Whether that holds at someone else's scale is a question only production traffic will answer.