First time owning a database rather than inheriting one. The docs show both a push command that syncs the schema straight to the database and a generate/migrate flow that produces .sql files. They are presented as equal options. A colleague at a previous job said push is for toys. Is that the consensus or is it fine for a small app with one developer?
The line is "does anyone lose data if this is wrong". Prototype nobody depends on: push all day, it is faster and you will change the schema eleven times before lunch. Anything with a paying user or a support obligation: migrations, reviewed, applied by the deploy.
Add one step beyond committing them: run the pending migrations in CI against a scratch database restored from a recent prod dump. That catches the migration that is syntactically fine and takes a four minute exclusive lock on your largest table, which the empty-database version never shows you.
And put SET lock_timeout = '3s'; at the top of migrations. If a lock queue builds up, you want the migration to fail fast rather than quietly stall every write in the app behind it.
Treat the folder as append-only once a migration has been applied anywhere but your laptop. Editing an applied file is where every "checksum mismatch, the migration has been modified" support thread comes from.
It is normal to be confused, for what it is worth. The tools present both flows with equal prominence and only one of them has a real story for production, which is a documentation problem rather than yours.
That is reassuring. Going with generate/migrate and keeping push for the local database I recreate weekly.
@dockerfile_yuki · 4w ago
Commit the SQL. It is the only durable record of what actually ran against your data, in order, and it is the thing you read at 3am when a column is unexpectedly empty.
Push compares your schema file to a live database and decides on the changes itself, with no artefact to review and no history. That is genuinely fine for the dev loop where the database is disposable. The moment somebody would be upset if a table were dropped, you want a file in git with your name on the commit.
Reply
Report