Claude Code for database work: what to verify and what to write yourself

Database mistakes are hard to undo. A dropped column, a migration that runs without a rollback path, a query that table-scans on a large table — these have consequences that a code review doesn't catch until it's too late. Claude Code can help with database work, but the stakes are higher here than anywhere else.

What Claude is reliable for

Writing standard queries against a schema you show it. If you paste the schema and describe what you want, Claude produces correct SQL for straightforward operations — selects with joins, inserts with returning, updates with conditions. These are easy to verify by reading them.

Migration files for additive changes. Adding a new table, adding a nullable column, adding an index — Claude writes the up migration reliably. Review it before running.

What requires more care

Any migration that changes existing data. Claude will write the SQL, but it won't know about the actual data distribution, the size of the table, or whether a backfill will take 30 seconds or 3 hours on your production data. You need to check this yourself.

Destructive operations. DROP TABLE, DROP COLUMN, TRUNCATE. Claude will write these if you ask. It will include them in migrations if it thinks they follow from the task. Add "do not write any destructive SQL unless I explicitly ask for it" to your prompt whenever you're asking Claude to help with database changes.

Rollback migrations. Claude writes up migrations. It sometimes writes down migrations, and they're sometimes wrong — either incomplete or destructive when they shouldn't be. Write rollback migrations yourself, or verify them very carefully.

The query review checklist

For any query Claude writes:

• Does it have a WHERE clause? If selecting from a large table without a filter, does that make sense?
• Are the joins correct — is it INNER when it should be LEFT, or vice versa?
• If it's an UPDATE or DELETE, is the WHERE clause restrictive enough?
• Are the indexed columns being used, or is the query going to table-scan?

Migrations in production

Before any migration runs in production: check if it locks the table and for how long. Claude doesn't know your database size or your traffic patterns. An index creation that locks a table is fine on a 10k row table and a disaster on a 50M row one. You have to know which you have.

For anything that might lock: ask Claude about concurrent index creation, background migrations, and whether your database version supports the operation you need without a lock.