What is Claude Code? It Owns My Production Postgres Now

By Lazar Milicevic · Published July 2, 2026 · 8 min read

Claude Code authored 23 of the last 31 migrations shipped to my production database. The one with 180,000 live invoice rows and paying customers who send invoices every morning. If "AI writes to prod" makes your stomach drop, good — that's exactly where this tool earns its rent, and where every "build a to-do app" demo goes silent.

Claude Code is an operator, not an autocomplete

Claude.ai is the chat window: you paste, it answers, you copy back. Claude Code is a terminal agent that reads your entire codebase, runs shell commands, edits files, executes migrations, and hands control back only when it's done. That distinction stops being academic the moment you give it write access to a production database.

The trust boundary moves. With Copilot, you copy, paste, run, verify — and if something breaks, you own every keystroke in between. Claude Code closes the loop: it executes the safe parts itself and escalates to you at the exact moment a human decision is required. So the interesting question stops being can it write the code and becomes which parts of your infrastructure are you willing to let it touch, and what guardrails go between it and the customers paying your bills.

• Claude.ai: stateless chat, no filesystem, no shell.
• Copilot: in-editor suggestion, human executes every action.
• Claude Code: terminal agent, executes shell/SQL/git, gated by your role setup and confirmation prompts.

The three-role Postgres setup that makes this survivable

The single change that separates "AI in prod" from "AI as a liability" is refusing to hand it one superuser role. My invoicing SaaS runs about 40 tables and 180,000 live invoice rows. Claude Code never sees the app role. It gets two, both narrower than what most teams give a junior engineer.

-- 1. Read-only role: what Claude Code opens every session with
CREATE ROLE claude_ro LOGIN PASSWORD '...';
GRANT CONNECT ON DATABASE app_prod TO claude_ro;
GRANT USAGE ON SCHEMA public TO claude_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO claude_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO claude_ro;

-- 2. Migration role: scoped, no DROP DATABASE, no role management
CREATE ROLE claude_migrate LOGIN PASSWORD '...';
GRANT CONNECT ON DATABASE app_prod TO claude_migrate;
GRANT USAGE, CREATE ON SCHEMA public TO claude_migrate;
GRANT SELECT, INSERT, UPDATE, DELETE,
      REFERENCES, TRIGGER ON ALL TABLES IN SCHEMA public
  TO claude_migrate;
-- Explicitly NOT granted: SUPERUSER, CREATEDB, CREATEROLE, REPLICATION

The read-only role is the session default. Sessions get promoted to claude_migrate only when I approve a migration file. The app role — the one your web tier uses — is never in Claude Code's .env. Ten minutes of Postgres config, and a hallucinated DROP TABLE invoices becomes a permission error instead of a Sunday morning restore.

Grounding: give the agent the live shape of production

Hallucinated column names are the #1 reason people distrust agents on databases. The fix is boring and effective: before Claude Code writes a line of SQL, it dumps the actual schema and row counts of the tables it's about to touch. You're not asking the model to guess — you're feeding it ground truth from the box it will operate on.

My session opens with a CLAUDE.md that mandates this reflex:

## Rules for schema changes
1. Before proposing any migration, run:
   - `\d+ <table>` for every table referenced
   - `SELECT reltuples::bigint FROM pg_class WHERE relname='<table>'`
   - `SELECT indexname, indexdef FROM pg_indexes WHERE tablename='<table>'`
2. Paste the output into your reasoning before writing SQL.
3. If a column or index you assumed does not exist, stop and re-plan.
4. Never write DDL against tables you have not inspected this session.

That's the difference between an agent that invents invoice.total_amount and one that knows the column is invoice.gross_total_cents, that invoice_items has a composite index on (invoice_id, line_number), and that there are 2.4M rows sitting on it. Grounding kills roughly 90% of the SQL mistakes I used to catch in review.

Every change is a migration file, reviewed like a pull request

I never let Claude Code run ad-hoc SQL against prod. Every change becomes a numbered migration file, checked into git, with an up and a down. I read it before it runs anywhere.

A recent example: a slow report query needed a partial index on invoice_items. Claude Code produced this, unedited:

-- migrations/0247_invoice_items_unpaid_partial_idx.up.sql
-- Rationale: report query filters on status='unpaid' AND due_date < now().
-- Full index bloats writes on a 2.4M row table; partial keeps it ~4% the size.
-- CONCURRENTLY avoids locking invoice_items during business hours.
CREATE INDEX CONCURRENTLY IF NOT EXISTS
  idx_invoice_items_unpaid_due
  ON invoice_items (due_date)
  WHERE status = 'unpaid';

-- migrations/0247_invoice_items_unpaid_partial_idx.down.sql
DROP INDEX CONCURRENTLY IF EXISTS idx_invoice_items_unpaid_due;

Forty lines total with the comments. CONCURRENTLY on both sides. A predicate that matches the actual query planner's needs. A rollback that doesn't lock. I read it in 90 seconds, understood it, approved it. That's the workflow — the agent drafts, I own the merge.

Staging replay against a nightly production restore

The migration runs against a nightly restore of production before it runs against production. Same data volume, same schema, same Postgres version, same extensions. If a CREATE INDEX CONCURRENTLY takes 11 minutes on staging, I know within ±30 seconds what it takes on prod. If it errors on staging, prod never sees it.

Claude Code executes the staging run itself and reports back:

$ claude run migrate:staging --file 0247_invoice_items_unpaid_partial_idx.up.sql

[claude] connecting as claude_migrate@staging-restore
[claude] target: invoice_items (2,412,883 rows, 1.8 GB)
[claude] executing: CREATE INDEX CONCURRENTLY ...
[claude] elapsed: 10m 47s
[claude] verifying: SELECT indexname FROM pg_indexes WHERE ...
[claude] verified: idx_invoice_items_unpaid_due present, size 74 MB
[claude] no lock contention detected (pg_locks sampled every 5s)
[claude] OK — ready for prod

That last block is what lets me sleep. If staging times out, if pg_locks shows contention, if the verification query fails, the whole thing halts and I read the log in the morning instead of getting paged.

Production: the loop that keeps humans in charge

When Claude Code runs the prod migration, it is not autonomous. It prints the exact command, waits for my confirmation, executes, then immediately runs a verification query to prove the change landed. That confirmation prompt is not a formality — it's the seam where I audit intent against effect.

[claude] READY TO EXECUTE ON PRODUCTION:
[claude]   psql -U claude_migrate -d app_prod -f 0247_...up.sql
[claude]
[claude] staging elapsed: 10m 47s
[claude] expected prod row count: 2,398,441 (delta -14k vs staging)
[claude] expected duration: ~11 min
[claude]
[claude] Confirm? (type YES to proceed)
>

Numbers from the last four months on this stack:

Four staging catches in four months is the honest part. Without the nightly-restore step, at least two of those would have been prod incidents — one was a missing IF NOT EXISTS that would have failed a rolling deploy, one was a CONCURRENTLY omitted on a large table that would have locked writes for eight minutes at 2pm.

Where this workflow breaks (be honest about it)

Three failure modes I've hit, so you don't learn them the expensive way:

• Long-running data backfills. Claude Code will happily draft a single-statement UPDATE across 2M rows. That's a bad idea regardless of who writes it. I force it to chunk any DML touching >50k rows into batched jobs with progress logging.
• Extensions and roles outside its grant. It'll suggest CREATE EXTENSION pg_trgm and hit a permission error. That's the guardrail working, but expect to intervene manually for anything that needs superuser.
• Cross-service migrations. If a schema change requires a coordinated deploy of the app tier (rename a column, backfill, drop old column), the agent can plan the sequence but you have to actually orchestrate the deploy windows. It won't do that for you, and pretending otherwise is how you break prod.

The Postgres docs on concurrent index builds are worth a second read before you turn any agent loose on a large table — the failure modes there are subtle, and the agent knows the syntax but not your traffic pattern.

Where bizflowai.io fits in

This is the same pattern we deploy for clients at bizflowai.io when an agent needs write access to something that matters — a production database, a billing system, a CRM with real customer records. Scoped roles, forced grounding on live schema, migrations-as-files with human approval, staging replay against real data volumes, and a confirmation prompt at the production seam. It's not glamorous, but it's the reason nobody's woken up at 2am because the AI got creative.

The real answer to "what is Claude Code?"

It's the first developer tool where the interesting question is not can it write the code but which parts of your infrastructure are you willing to let it touch. The terminal isn't the point. The write access is the point. Once you accept that, you stop asking it to build toy apps and you start letting it operate the boring, dangerous, high-leverage parts of your business — under guardrails you designed on purpose.

For more on the surrounding stack: the Claude Code intake layer that kills 60% of bad leads and how a Sentry error report hijacked Claude Code — both are worth reading before you give any agent production credentials.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.