How to connect Claude to a database
There are three different questions hiding in this one, with three different answers. If you want Claude to query a database you already have, connect it over MCP: Claude talks to a database MCP server and can read, and if you allow it, write. If you want an artifact Claude built to store data, artifacts do have persistent storage, but it is 20 MB, text only, and works only once published. If you want an app with a database behind it that other people log into, an artifact cannot do that at all and you need somewhere to host it.
Last checked against Anthropic's documentation on . Claude changes often. If something here no longer matches the help centre, the help centre is right.
Which of the three questions are you asking
Getting this wrong is why the search results for this are so unsatisfying: the three intents get answered interchangeably. Find your row first.
| What you want | The answer | Where it runs |
|---|---|---|
| Claude should query my existing database | An MCP server for that database | On your machine or your network, alongside Claude |
| The artifact Claude built should remember things | Artifact persistent storage | Inside the published artifact, 20 MB, text only |
| I need an app with a database that people log into | A hosted app platform | On a host, at its own URL, with accounts |
A fourth thing sits across the first two and is worth knowing before you read either: an artifact can call your MCP connectors while somebody is looking at it, so it can display live data from a system you have already connected to Claude even though it cannot hold a database connection itself. What that is genuinely good for, and the two conditions attached to it, are in what an artifact can reach below.
Option 1: let Claude query your own database over MCP
The Model Context Protocol is the standard way to give a model access to a system it does not otherwise know about, and databases were one of the first things people wired up with it. In practice you run a small MCP server that holds the connection, and Claude calls it.
- Pick a server for your database. There are MCP servers for PostgreSQL, MySQL, SQLite, SQL Server and most managed database products, plus first-party ones from several database vendors.
- Give it a connection string. The server holds the credential. Claude never sees it, it only sees the tools the server exposes.
- Register it with your client. In Claude Code that is a single mcp add command; in a desktop client it is an entry in the MCP servers configuration.
- Ask in plain language. Claude lists tables, inspects schemas, and writes the SQL. You review what it proposes before anything runs, if the server is configured to ask.
What this gives you is a very good analyst and a very fast way to answer a question about data you already have. What it does not give you is anything the people you work with can use: the connection lives on your machine, in your client, under your credentials. Nobody else can open it.
The security part almost every guide skips
Connecting a model to a database means an agent will compose statements against it. That is fine, and it needs the same care you would apply to any other automated account.
- Make a dedicated role. Not your own login, and certainly not the superuser. One role, one purpose, revocable in one command.
- Start read-only. Grant SELECT and nothing else until you have a specific reason to widen it. Most of what people actually want from this is questions, not changes.
- Scope it to a schema. A model exploring the database will read whatever it can see, including columns you forgot were sensitive. Restrict the grant rather than relying on the prompt.
- Do not point it at production first. A replica or a restored dump answers the same questions with none of the risk.
- Keep the credential out of the conversation. Put it in the MCP server's own configuration or environment, never pasted into a chat message, which becomes part of the transcript.
- Assume any write can be wrong. If you do grant writes, take a backup you have actually tested restoring, and prefer a role that cannot DROP or TRUNCATE.
Option 2: storage inside the artifact Claude built
If what you meant was that the little app in the chat should remember things, artifacts do have persistent storage. The limits are documented and they matter more than they sound:
Persistent storage for artifacts is available on Pro, Max, Team, and Enterprise plans on Claude web and desktop.
Persistent storage for artifacts, Claude Help Center
Persistent storage is only available for published artifacts. During development and testing, storage operations will not succeed until the artifact is published.
Persistent storage for artifacts, Claude Help Center
- A 20 MB storage limit per artifact.
- Text only: no images, files, or binary data.
- It is a key-value style store, not a relational database. No SQL, no joins, no queries.
- The page cannot open a connection of its own. A strict content policy blocks its outbound calls, with one documented exception covered in the next section.
- It has no notion of who is using it, so a shared pool is genuinely shared with everyone.
The CSP blocks scripts, stylesheets, fonts, and images loaded from any other host, along with fetch, XHR, and WebSocket calls.
Share session output as artifacts, Claude Code documentation
So an artifact cannot hold a connection string and talk to your database. Nothing in the page opens the socket, and that is by design rather than an oversight. What the page can do is hand a call to claude.ai and let it make the request instead, which is a real hole in the rule and is the next section. Full detail on the storage side is in can Claude Artifacts store data.
What an artifact can reach: your MCP connectors
The rule above is about the page's own network access, and left on its own it is too strong. Anthropic's developer documentation records an exception, and it matters more here than anywhere else in these guides, because this is the page about reaching a database.
Connector calls are the exception: the page hands them to claude.ai, which makes the network call itself.
Share session output as artifacts, Claude Code documentation
So an artifact can show live data after all. If a database you already have sits behind an MCP connector, an artifact can display what that connector returns, refreshed each time somebody opens the page rather than frozen at the moment it was built. That is genuinely useful and preferring our own product does not make it less true.
Two documented conditions decide what it is good for, and together they are why this is not option 3 below in disguise.
calls go through the viewing account's connected tools, so two people opening the same dashboard can see different data depending on what their accounts can access
Share session output as artifacts, Claude Code documentation
An artifact that calls connectors can't be shared to a public link on any plan.
Share session output as artifacts, Claude Code documentation
- The data belongs to whoever is looking. The call runs through the viewer's own connections rather than yours, so each person sees their own data, and somebody who has not connected that tool sees nothing.
- It cannot be a public link. An artifact that calls connectors is not publicly shareable on any plan, so the audience is you and the people you can hand it to inside Claude.
- It is still not shared state. Nothing a viewer does gets written anywhere the next viewer can see it, because the artifact has no store of its own beyond the two pools above.
The practical reading: a connector-backed artifact is an excellent personal dashboard over data you already have access to, and it is not an app with a database behind it that other people log into. If the dashboard is what you wanted, this is the cheapest way to get one and you can stop reading here.
Option 3: an app with a database that other people use
This is the intent behind most of the questions, once you scratch at them. Somebody wants a small internal tool: an intake form, a stock list, a booking sheet, a request tracker. They want Claude to build it, they want it to keep its data, and they want their colleagues to open it.
Homespun is where the same agent that built the thing can host it. People sign in with their email, so the app can tell who is who and every row remembers who created it; permissions are set per collection, so some people can approve and others can only submit; and the agent keeps read and write access to the collections it is allowed, so it can keep working on the data instead of handing you a page and walking away. It is free today, and there is no paid plan to buy.
| MCP database server | Artifact storage | Hosted app | |
|---|---|---|---|
| Uses a database you already have | Yes | No | No, it gets its own |
| Other people can use it | No, it is your client only | Yes, anonymously | Yes, signed in |
| Knows who each person is | Not applicable | No | Yes, once they sign in |
| Query language | Yes, your own SQL | No, key and value only | Filtered queries over collections, no SQL |
| Files and images | Whatever your database holds | No, text only | Yes, images, PDFs, audio and video |
| Survives you closing your laptop | No | Yes | Yes |
| Agent can keep working on the data | Yes, while you are there | No | Yes, on its own |
| Best for | Answering questions about existing data | A small self-contained tool | A tool a group uses every week |
These are not competitors, and neither is the connector route above. A perfectly reasonable setup is all of them: an MCP server so Claude can read your warehouse, a connector-backed artifact as your own live dashboard over it, and a hosted app for the thing your team fills in every Monday.
Questions people ask next
Can Claude connect directly to a SQL database?
Not by itself. Claude connects through an MCP server that holds the database connection and exposes tools Claude can call. The credential lives in that server's configuration, and Claude sees only the tools, never the connection string.
Can a Claude Artifact connect to my database?
Not directly. The page cannot open a connection of its own, because a strict content policy blocks its fetch, XHR and WebSocket calls, so there is nothing for a connection string to do. It can hand a call to claude.ai, which calls your MCP connectors for it, so an artifact can display data from a database you have already connected to Claude. That call runs through the viewing account's own connections, and an artifact that calls connectors cannot be shared to a public link on any plan.
Is it safe to give Claude access to a production database?
Only with care. Create a dedicated role rather than reusing your own, grant read-only access to start, scope it to the schema it needs, and prefer a replica or a restored dump over production. Keep the credential in the MCP server's configuration, never in a chat message.
What database does Claude use for artifacts?
Artifacts do not use a database in the usual sense. They have a key-value persistent storage feature with a 20 MB per-artifact limit that accepts text only, available on paid plans, and only once the artifact is published.
How do I build an app with a database that my team can log into?
You need somewhere to host it, because an artifact cannot authenticate anyone. An agent-hosted app platform lets the agent deploy the app, provision the data behind it, and give each colleague their own sign-in, then keep reading and writing that data afterwards.
Can Claude write to a database, not just read from it?
Yes, if the MCP server it is connected to exposes write tools and the database role has permission. Start read-only and widen deliberately, because a model composing statements against live data can be wrong in ways that are expensive to undo.
Primary sources
Every claim about Claude on this page comes from Anthropic's own documentation, quoted rather than summarised so you can check it yourself.