I increasingly hear or read the advice to solve problems by querying MCP servers on production databases.

Meanwhile, I’m reading output from an AI agent that tried to use an MCP server of some sort. And the output is full of things that are obviously wrong/false/dangerous.

It’s expensive and dangerous to trust an AI Agent to query production freely, even with read-only access. You have MUCH safer options which will give you better results, both for human employees and AI Agents.

The pganalyze team wrote about how to do this and why

Whether you’re working with SQL Server, PostgreSQL, Oracle, or Whatever Relational Database, the model that currently makes sense for using AI to soothe your database pains is described on the public preview page for the pganalyze MCP.

As they mention, “there is no direct connection to your database involved.”

Here is the architecture in diagram form:

They do a great job of explaining why this makes sense on that page, so I’m going to take a different approach.

I asked Claude to give me its five strongest arguments (no straw men) of why MCP access to prod databases is good, actually. Let’s walk through those and see how they don’t hold up.

1. “Read-only MCP access is low-risk and high-value.”

Claude says:

An agent with SELECT-only permissions on a replica can answer operational questions without write exposure — the “stupid” label overclaims by ignoring this configuration.

Amusingly, I didn’t say anything about replicas in my prompt at all– the AI just injected that to try to lower the risk level. You know what you pay a lot of money for? Both Claude code and replicas.

Factors to think through:

• One can easily tank performance with only read-only access to a production database.
• When performance is bad, it often tends to become difficult to query the production database, because it’s having a hard time responding, which escalates as things get worse.
• AIs currently perform much better when they are given clear boundaries and rules to follow with rich, reliable context that is succinctly summarized.

We don’t want to be running a bunch of exploratory queries when things go bad. And we don’t even need to. Instead, we can set humans and agents up for success by using AI to build tools to pre-collect and pre-compute the information we need to solve problems. These are all things that can be collected and baselined by normal old predictable code:

• Clear, reliable historical metrics on performance of most frequent queries ( query explain / execution plans and runtime metrics )
• Established baselines of wait statistics and workload bottlenecks
• Indications of when changes deployed/lit up with clear documentation of what they were
• Strong, regular boring monitoring of standard/known error conditions
• Regular snapshots of fresh, active production activity and wait statistics that can be compared against the baselines

An agent with access to this information can much more reliably answer 95% of operational questions with NO direct production access, no expense of replicas, and can even link to you actual data in your monitoring system that substantiates its claims.

2. “Human operators already cause production incidents.”

Claude continues:

The comparison class isn’t “agents vs. perfection,” it’s “agents vs. humans running ad-hoc queries” — and humans fat-finger DELETE without WHERE too.

Let’s sit with this a second.

We could use AI to make it so that the number of ad-hoc queries and opportunities to screw up a DELETE are dramatically reduced. The fact is, mature OLTP databases are VERY observable– particularly SQL Server is ridiculously so. It’s very well documented how to extract all the information you need to diagnose and troubleshoot what is slowing down or crashing your SQL Server using standard, repeatable, automated methods.

Erik Darling has even given us an MIT Licensed version of this for SQL Server.

We should not extend the bad pattern we already have to AI agents. We should minimize the need for the bad pattern.

3. “MCP servers can actually improve auditability over the status quo.”

A well-designed MCP layer creates a single, structured, logged interface — potentially more traceable than the current reality of engineers, scripts, ORMs, and internal tools all connecting directly with varying levels of logging.

I’ve heard of well-designed databases, too.

I’ve seen thousands of actual databases in hundreds of production environments so far, and one day I’m hoping to find one of those well designed ones.

Humans have been in love with ideals since before Plato named them — and equally good at forgetting that what we actually build and operate exists in the realm of appearances, not Forms.

4. “The alternative has its own risks.”

If agents can’t query production directly, engineers copy data to less-secure environments, export CSVs, or paste results into chat tools — all of which create worse data exposure.

I sometimes wonder if we should start calling database monitoring systems “Agentic Context” now.

Will this rebrand remind us, and the agents, that the majority of troubleshooting is understanding what “normal” looks like and what has changed from “normal”? And monitoring systems are simply a way of collecting/ analyzing/ summarizing descriptions of “normal”, so one can reason about what is different?

5. “The “production database” framing does too much work”

Whew, we’re in the home stretch. For this last point, Claude elaborates:

Modern architectures have read replicas, analytics replicas, streaming copies, and data warehouses that are logically production data but architecturally separated. Blanket opposition to “production MCP” conflates genuinely different risk profiles.

There’s another thing that modern architectures also have, which can be far cheaper than replicas or warehouses, which are more efficient by being built for this purpose, and which now have a lot of MIT licensed options….

Monitoring systems. And those pre-compute a huge amount of the information needed to actually solve problems.