Adding a database to a Claude Code app
This question means two different things and they have different answers. If you want Claude Code to read and write a database you already have, connect a database MCP server: Anthropic documents MCP as the way to give it access to your tools, databases and APIs. If you want the app you are building to have a database, that is a hosting decision instead, and the local SQLite file the agent reaches for first will not survive deployment. The second case is the one that causes real damage, because it works perfectly until the moment it is in front of other people.
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 question are you asking
Both are reasonable, they sound identical, and the answers share nothing.
| The agent needs database access | The app needs a database | |
|---|---|---|
| What you want | Claude Code to query, inspect or migrate an existing database | The app you are building to store its own data |
| The answer | A database MCP server | A hosted database, chosen before you deploy |
| When it is set up | Once, on your machine | As part of the app's architecture |
| Who uses it | You, through the agent | Everyone who uses the app |
| Typical failure | Permissions, or the agent running a destructive statement | Data quietly disappearing after deployment |
Giving Claude Code access to a database
This is documented and supported, and MCP is the mechanism:
Claude Code can connect to hundreds of external tools and data sources through the Model Context Protocol (MCP), an open source standard for AI-tool integrations.
Connect Claude Code to tools via MCP, Claude Code documentation
MCP servers give Claude Code access to your tools, databases, and APIs.
Connect Claude Code to tools via MCP, Claude Code documentation
The behaviour that makes it worth doing rather than pasting query output into the chat:
Once connected, Claude can read and act on that system directly instead of working from what you paste.
Connect Claude Code to tools via MCP, Claude Code documentation
Two safety points that are worth more than any speed gained. Give the connection a read-only role unless you specifically need writes: an agent that can only read cannot drop anything. And never point it at a production database you cannot restore, for the same reason you would not hand a production console to anything that acts on its own. A copy is nearly always enough for what you actually wanted.
Giving the app a database, and the trap in it
Left to itself, an agent building a small app will very often reach for a local SQLite file or a JSON file on disk. It is the right call for a local tool and the wrong one for anything deployed, and the reason it causes trouble is that nothing at all goes wrong until you deploy. It works on your machine, it works in review, and it silently resets in production.
- Most hosts have an ephemeral filesystem. Writes survive until the container restarts, which happens on every deploy and often in between.
- More than one instance means more than one copy. Two instances behind a load balancer each get their own file, so users see different data depending on where they land.
- There is no backup. A file inside a container is not backed up by anything, and the first time you find out is the time you needed it.
So the question to ask the agent, early and explicitly, is where does this data live and what happens to it when the process restarts. The answer to that decides whether you need a managed database before the first deploy or after the first data loss.
The real options, compared
All four work. They cost different amounts of setup and buy different things.
| Local SQLite file | Managed Postgres | Backend as a service | Homespun | |
|---|---|---|---|---|
| Survives deployment | No | Yes | Yes | Yes |
| Setup effort | None | Real: provision, connect, migrate | Moderate | None, the agent creates it |
| Schema is yours to design | Yes | Yes | Yes | Collections, simpler and less flexible |
| User accounts included | No | No | Yes | Yes |
| Per-row ownership and permissions | You build it | You build it | Rules you write | Per collection, built in |
| Agent can act on live data later | Only your copy | With an MCP server | With an MCP server | Yes, on allowed collections |
| Cost | None | A monthly bill | Free tier, then real money | Free today, no paid plan to buy |
| Good for | Local tools, prototypes | Anything you intend to own | Apps needing a custom schema | A small multi-user app, fast |
The second column is the right answer more often than we would like it to be. If the app is going to grow, or you want to own it, take the setup cost of a managed database and be free of platform decisions. 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.
What to ask the agent before you deploy
Four questions. Each one takes a sentence to ask and catches a failure that is expensive to find later.
- "Where does this app store its data, and does that survive a restart?" The single highest-value question on this page.
- "Does every record know who created it?" Retrofitting ownership means touching every query, so find out now rather than after people have used it.
- "What happens if two people write at the same time?" A file-backed store usually has no answer, and the answer arrives as corrupted data.
- "How would I get the data out?" If there is no export path, you are choosing a place your data cannot leave.
Questions people ask next
Can Claude Code connect to a database?
Yes, through an MCP server. Anthropic documents that Claude Code can connect to hundreds of external tools and data sources through the Model Context Protocol, and that MCP servers give it access to your tools, databases and APIs. Once connected it can query and act on the database directly rather than working from output you paste in.
What database should a Claude Code app use?
For anything deployed, a managed database rather than a local file. Local SQLite or a JSON file is fine for a tool that only ever runs on your own machine, but on most hosts the filesystem is ephemeral, so those writes disappear on the next restart or deploy.
Why does my Claude Code app lose its data after deploying?
Almost certainly because it writes to a local file. Most hosting platforms give each instance an ephemeral filesystem, so anything saved there is discarded when the container restarts, which happens on every deploy. If more than one instance is running, each also has its own separate copy.
Is it safe to give Claude Code access to my production database?
Treat it the way you would treat any tool that acts on its own. Use a read-only role unless writes are genuinely needed, prefer a copy or a staging database over production, and never connect something you could not restore. Read-only access covers most of what people actually wanted from the connection.
Can I add a database to a Claude Code app without setting one up myself?
Yes, by using a platform that supplies one. A backend-as-a-service or an app platform gives you storage, and usually accounts alongside it, without provisioning anything. The trade is a schema model and a runtime that are the platform's rather than yours, so it suits a small app more than something you intend to own long term.
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.