How to give Claude read-only access to your database (it isn't always the default)

I assumed the official database MCP servers were read-only out of the box. When we checked five of them, two could write by default, and a third had a read-only guard you can walk straight past.

So yes, giving Claude read-only access to your database is safe, and it's the right baseline. A read-only role means the model can run SELECT queries but can never write, update, or delete. Point it at a read replica and it can't slow production either. You just have to set it up yourself, because the server's default might not do it for you.

Read-only also isn't the whole job. It stops the AI from changing your data. It doesn't decide who sees which tables, handle the credentials, or leave you a trail of what was asked. After the table below comes the checklist for connecting Claude or ChatGPT to a database safely, in the order that matters. Do the first three even for a solo setup. The rest are what a team needs before it can trust the answers.

Which official database MCP servers can write by default?

The database role is your decision. The MCP server's default is the vendor's, and vendors don't agree. We checked the current docs and source for each server we have a setup guide for on September 26, 2026.

Across all five, the server's own guard is a convenience and the database grants are the real control. ClickHouse says as much in its own README, which is why the checklist starts with the role.

1. Read-only, always

The AI should never be able to write, update, drop, or alter. Connect with a database role that only has SELECT. It's the most important line of defense, and it's one command. Don't reuse an app credential that happens to have write access because it was already lying around.

2. Point at a replica, not production

An AI exploring your data will occasionally write an expensive query, like a full scan over a huge table or an accidental cross join. Against production that can slow down real traffic. Against a read replica it can't. If you have a replica, use it. If you don't, at least set a statement timeout so a runaway query gets killed.

3. Enforce read-only at the layer, not just the role

A read-only role is one gate, and gates fail. If someone points the connection at a credential with more access, nothing catches it. The archived Postgres server in the table above is the real-world case: a crafted query got past its read-only guard and could write to the database. A layer that only lets read queries through is a second gate, so a misconfigured role doesn't turn into an incident. You want the read-only credential and the read-only enforcement both. We go deeper in read-only database access is not enough.

4. Scope table access per person

One connection string means one level of access: everyone who can use it can query everything it can reach. Your marketing lead can pull payroll, and your contractor can pull customer PII. For a solo setup that's moot. For a team it's the biggest gap. Each person should see only the tables they're supposed to. You can approximate this with a database role per person, but managing that by hand gets old fast.

5. Individual authentication, no shared secret

If every person configures the same database password in a local config file, the secret is on every laptop. When someone leaves you're rotating it for the whole team and breaking everyone at once. Each person should sign in as themselves against a central place, so offboarding means revoking one account.

6. Log every query

You want a record of who asked what, what SQL ran, and what came back. AI-generated SQL is occasionally wrong in quiet ways, and when a bad number surfaces in a decision you need to trace it back. A raw connection gives you none of this. Once the answers drive decisions, the log has to be built in.

7. Know what reaches the model

Under the commercial terms of both Anthropic and OpenAI (API, Team, and Enterprise plans), your data isn't used to train models. The subtler question is scope: which schema and which rows get sent to the model at all. A governed layer narrows this to the context and results the asking user is allowed to see, instead of exposing the whole database to every prompt. If your team is on consumer plans, check the data settings before connecting anything.

The short version

Solo and technical: a read-only role on a replica with a statement timeout (items 1 through 3) is a safe personal setup. Give Claude the read-only role and go.

For a team, anything sensitive, or answers people act on without reading the SQL, you need 4 through 7 too, and a bare connection can't give you those. That's what we built Contextflo for: one read-only connection for the whole team, with per-user table scoping and a log of every question and the SQL behind it. The longer walkthrough is in safe AI database access and connecting AI to your company data.

FAQ

Is it safe to give Claude read-only access to your database?

Yes. A read-only database role lets Claude query but never write, update, or delete, and pointing it at a read replica keeps analytical queries off production. That's a safe baseline for one person. For a team you also want scoped table access, individual sign-in, and a query log.

Can Claude delete or change my data with read-only access?

No. A read-only role has no write permission, so the model physically can't change anything. Enforcing read-only at the connecting layer too gives you a second gate in case the database role is ever misconfigured.

Does read-only access make the connection fully secure?

It's necessary but not sufficient. Read-only stops writes, but it doesn't scope who sees which tables, doesn't handle credentials, and doesn't log queries. For a team you need those too.

Can Claude delete data in BigQuery or Databricks?

It can if the MCP server and the identity behind it allow writes. Google's BigQuery MCP server exposes execute_sql, which isn't read-only, and the Databricks SQL MCP server permits writes by default until you set disallow_writes in system.ai.dbsql_policy. Connect with a read-only identity and use the read-only tool or policy.

Do Claude or ChatGPT train on data they query?

Not under the commercial terms of Anthropic or OpenAI on API, Team, and Enterprise plans. On consumer plans, review the data settings. A governed layer also limits what reaches the model to only what the asking user is allowed to see.

Here is a more in-depth look at Contextflo and how it works.