Keyboard shortcuts

jk
move through the list
↵
open the selected item
a
ask a question
nucw
tabs: new, unanswered, active, top
⌘↵
post the answer you are writing
/or⌘K
search
t
switch theme
?
this list
AskVibe
AskSign in
…
Sign in
Question

Should I let Cursor write my database migrations?

Solved · 244 viewsasked by ines_data
cursordatabasepostgres

Cursor happily generates migration files. Twice it generated one that dropped a column with data. I caught it, but barely.

What I’ve tried

Now I read every migration line by line. Slow.

Comment

3 answers

Marked as helpful by the asker
olu_backend

Let it write them, never let it run them unattended. Three guardrails that cost nothing:

  1. DROP and ALTER ... TYPE require a comment explaining why, enforced by a tiny CI grep.
  2. Every migration runs against a copy of production first (pg_dump → local → migrate → smoke test).
  3. Ask Cursor for the down migration too. If it cannot write the down, the up is destructive.

Reading migrations is the one place where slow is correct.

Comment
mira_dev

And separate 'expand' from 'contract': add the new column in one deploy, drop the old one a week later. Then a wrong drop is never same-day.

Comment
abby_ops

Guardrail 1 exists as a tool: squawk lints Postgres migration files and flags dropped columns, type changes and index creation without concurrently. Run it in CI on every new file in supabase/migrations/. It catches the dangerous ones and you can spend your reading time on the logic.

Comment
Running it on my old migrations flagged two I'd approved. Humbling. It's in CI now. ines_data

Related

How do I make my own backup of my Supabase database?solved
Postgres full-text search returns nothing for partial wordssolved
Postgres: should I use a JSONB column for user settings?solved
Postgres: uuid or bigint ids for a small app?solved
Cursor ran a migration through the Supabase MCP on my live project, how do I see what it changed?0 ans.

Your answer

Sign in to write an answer