How MCP Changes Database Workloads

You have probably spent years thinking carefully about which queries reach your database and where they come from. Connection limits, permission scopes, slow query logs, query review in code review. All of it rests on a quiet assumption: that a human designed, reviewed, or approved the system generating those queries.

When AI connects to your database via MCP, that assumption breaks down, creating new opportunities and new operational challenges.

Model Context Protocol (MCP) lets AI assistants connect directly to databases and other external systems. With database access available, an AI can inspect schema metadata and run queries to complete a task. Those queries may come from a model working toward a goal, outside the usual code review and ORM path, but still show up in your logs like any other database query. The result is a workload that can behave differently from the application traffic you're used to seeing:

• Query patterns become less predictable. Human-written queries follow access patterns someone designed. AI may follow whatever path gets it to the answer, which can result in broad table scans, repeated execution of expensive queries, or joins that were never anticipated by the application.
• Nobody reviewed the exact query. An ORM generates predictable SQL from a defined model and application logic. An AI may generate SQL from a prompt and schema at runtime.
• Load does not always follow application patterns. An AI agent can generate database activity dynamically as it works toward a goal. Unlike most application traffic, its activity is driven by goals rather than predefined request paths, which can create unexpected bursts of database load.
• A bad pattern executes at scale before anyone notices. Once AI discovers a query pattern that helps it accomplish a task, it may repeat that pattern hundreds or thousands of times before it shows up in monitoring.

How should an engineer handle this well? MCP and AI tools are powerful additions to the database toolkit, but they require continuous query visibility. Knowing which queries are running, how often, and at what cost, updated in real time as patterns change, becomes the thing that lets you catch a problem before it becomes an incident.

Readyset RDST connects directly to your Postgres or MySQL database and surfaces that visibility in a few commands. If AI tools are starting to hit your database and you want to understand what they are generating, that is a practical place to start.

🔍 What We're Watching in the Database Ecosystem

MySQL 9.7.0 PGO Benchmark Analysis

Percona benchmarked MySQL 9.7's new Profile-Guided Optimization build against a non-PGO build and measured a 6.5% average throughput gain, climbing past 14% on the largest buffer pool at low concurrency. The interesting part is where the wins come from: not I/O or caching, but tighter CPU execution of hot code paths through better branch prediction and instruction cache use. The gains shrink on smaller buffer pools and can tip into a slight regression at very high thread counts, so it's a real improvement, just an uneven one.

NSA Cybersecurity Information Sheet: Model Context Protocol Security

The NSA published formal guidance on MCP security this week, which is the first time a government cybersecurity body has addressed the protocol directly. It covers prompt injection risks, tool poisoning, unverified task propagation, and access control gaps in MCP deployments.

In Case You Missed It

We had a great time at Percona Live in Mountain View last week, where Vinicius presented "Beyond Manual Caching: How Readyset Offloads MySQL and Postgres Workloads," and it was great to catch up with so many people from the MySQL and Postgres community.

Know a database aficionado who'd appreciate this? Forward it their way.