Give Claude Code a Database

You have Claude Code open. It has scaffolded the project, written the handlers, and the data layer is sitting there fully written against a database that does not exist yet. So you stop, open a browser tab, click through a provisioning form, copy a connection string, paste it into .env, and come back.

That interruption is the whole problem. Not a hard one, just a constant one, and it lands at exactly the moment you had momentum. The agent wrote every line of code that talks to Postgres. It just had no way to make Postgres exist.

Here is the version where it does.

Connect once

MCP is the open standard for handing an agent tools it can actually call. Scalix runs a hosted MCP server, so connecting is one command and one API key:

claude mcp add --transport http scalix https://api.scalix.world/v1/mcp \
  --header "Authorization: Bearer $SCALIX_API_KEY"

Add --scope project to check the connection into .mcp.json and share it with your team, or --scope user to have it in every project on your machine. Run /mcp inside a session to confirm it connected.

That is the setup. Nothing to install, nothing to run locally, and the same key that reaches the database also covers deploys.

Then just ask

With the tools connected, the database becomes something you describe rather than something you go and do:

Create a Postgres database for this app, put the connection string in .env as DATABASE_URL, then write and run the initial schema migration for users and sessions.

The agent works through that in order. It creates the database, reads back the connection string, writes it into your .env, generates the migration, applies it, and queries the result to confirm the tables landed.

What comes back is an ordinary DSN:

postgres://<user>@<host>:5432/<database>

Nothing exotic. It goes in .env like any other:

DATABASE_URL=postgres://<user>@<host>:5432/<database>

You can pick the major version when it is created. PostgreSQL 16, 17, and 18 are available, and 16 is the default if you do not say. That choice is fixed for the life of the database, so branches and point in time restores stay on the same major rather than quietly drifting underneath you.

Then the agent writes the schema, which is the part it was always good at:

CREATE TABLE users (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  email text UNIQUE NOT NULL,
  created_at timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE sessions (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id uuid NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  expires_at timestamptz NOT NULL
);

It applies that through the migration tool and then verifies with a query, reading the result back into the conversation. If the migration fails, it sees the error itself and fixes it. That read-back is the difference between an agent that runs commands and an agent that finishes the job.

Worth being clear about what you are connecting to. ScalixNova is a purpose-built storage engine that speaks the Postgres wire protocol, not a managed wrapper around upstream Postgres. We wrote the engine, which is a deliberate choice we explain in built, not assembled. From your side of the socket it does not change your habits: psql connects, your ORM connects, your migration tool connects, all over TLS, all speaking the protocol they already speak. And if you want to know what happens to your data after a write is confirmed, how durability works in ScalixNova walks through it layer by layer.

Branch it before you break it

The prompt nobody types confidently is the destructive one. Dropping a column, rewriting a table, backfilling three million rows. You want the agent to try it, and you do not want it tried against the database your app is using.

So give it somewhere else to try:

Create a branch database, run the column rename and backfill against it, check the row counts, then tell me what happened before we touch the real one.

The agent creates an isolated branch database with its own scoped token, does the work there, reports back, and drops the branch when it is done. Branches also carry a TTL, so a scratch database the agent forgot about expires on its own instead of accumulating.

The useful shift here is psychological more than technical. When trying a bad migration costs one tool call and no risk, you let the agent attempt the awkward one instead of talking yourself into the safe half measure.

Scale to zero and side projects

Agent-created databases multiply. You build a weekend thing, it needs Postgres, the agent makes one, and three weeks later you have forgotten it exists. On most platforms that forgotten database is a line item that shows up every month whether or not anything ever connects to it.

On Scalix a paused database does not bill compute. Nothing is running, so nothing is metered for running. That is not a special tier we bolted onto the database product; scale to zero works the same way across the platform because the same lifecycle layer manages everything on it.

Practically, this is what makes the loop in this post safe to actually use. You can let the agent create a database per experiment without keeping a mental ledger of what you owe for abandoned ones.

What stays human

Handing an agent database tools does not mean handing it everything, and the boundary should be explicit rather than vibes.

Scopes are the real control. Scalix API keys carry separate scopes for querying, branching, and admin operations. A key that can run migrations is a different key from one that can only read. Give the agent the narrowest scope that does the job, and keep production admin on a key that lives somewhere the agent cannot reach.

Destructive SQL asks first. Statements like DROP, TRUNCATE, and bulk DELETE through the query tool return a confirmation requirement rather than executing, and the call has to be repeated with a confirmation token. It is a speed bump on purpose.

Production data access is a policy decision, not a prompt. Whether an agent should read real customer rows at all is a question about your obligations to the people in those rows. Decide it deliberately, write it down, and let branches carry the experimental work.

None of that is friction for its own sake. It is the difference between an agent that can operate your database and an agent that can operate your database at 2am on a Friday.

Wrapping up

The gap was never that Claude Code could not handle databases. It writes better SQL than most of us. The gap was that it had no way to make one exist, so you kept leaving the session at the same point in every project.

Connect the tools once and that step disappears. Describe the database you want, get a DSN back, keep going.

You can start on Scalix Nova; current terms are on the pricing page. Point your agent at the MCP server, ask it for a database, and see how far the session gets before you need another window. If you build something with it, tell us on Discord or X.