Give Claude Code a database

The most common first use of briq: your project has Prisma, Drizzle or plain SQL migrations, and you want the agent to verify them against a real database instead of reasoning about them.

Setup

Connect the MCP server once (Getting started):

claude mcp add briq --transport http https://api.briq.run/mcp \
  --header "Authorization: Bearer $BRIQ_API_KEY"

Optionally tell the agent how you want it used, in CLAUDE.md:

## Databases
Use the briq MCP server for any Postgres you need. Prefer the `postgres` recipe
with `wait: true`, run migrations with `pnpm prisma migrate deploy`, and destroy
the briq when you are done.

That is the right job for a markdown file: it describes preferences. briq provides the machine.

Ask

Run the migrations against a fresh Postgres 17 with pgvector and check that prisma db seed works on an empty database.

What the agent does:

briq_run({ recipe: "postgres", params: { version: "17", extensions: ["pgvector"] }, wait: true })
→ running bq_7kq2m9x1p4ab · pgvector/pgvector:pg17 · small · cost so far €0.01 · stops at 18:42
  DATABASE_URL=postgres://postgres:••••••••@db.s1.internal:5432/app

$ DATABASE_URL=… pnpm prisma migrate deploy
$ DATABASE_URL=… pnpm prisma db seed

briq_exec({ briq: "bq_7kq2m9x1p4ab", cmd: ["psql", "-U", "postgres", "-d", "app", "-c", "\\dt"] })
briq_destroy({ briq: "bq_7kq2m9x1p4ab" })

Tips

• Keep the database around while iterating. briq_stop keeps the disk at storage price; briq_start brings it back with its data. Destroy at the end of the session.
• Seed once, snapshot later. Snapshots (v1.1) will let you fork a seeded database per test run. Until then, briq_files_put a SQL dump and psql -f it.
• Name the stack. stack: "acme-dev" makes briq_list readable when the agent runs more than one service.
• Cap the key. Give the agent a sub-key with dailySpendCapCents: 200 and maxConcurrentBriqs: 2. A runaway loop then costs two euros, not a weekend.