Getting started Getting started

Migration frameworks: the SQL your ORM wrote

available
bolvrk check and bolvrk/bolvrk@v1 · every plan

Prisma, Drizzle, Supabase, Flyway, Liquibase, dbmate, golang-migrate, sqlx, Atlas, Sqitch and Hasura are detected from the repository; the CLI and the Action check the SQL the tool generated, which is the SQL that runs.

Most migrations are not written by hand any more. A developer, or an agent, changes a schema file and the framework writes the SQL: an @@index line in a Prisma schema becomes a plain CREATE INDEX, which holds a SHARE lock on the table for the whole build. Nothing in the schema file says so, and the reviewer approves the schema file. The safe form exists in every framework and every framework defaults away from it, because CONCURRENTLY cannot run inside the transaction they wrap migrations in.

So the check runs where the truth is: on the generated SQL, in the directory the framework keeps it. With no files named and no globs in bolvrk.json, bolvrk check looks for a recognised layout and checks it; the Action does the same when its migrations input is empty. Prisma and Drizzle also say which database they target in their own config, so a SQLite project gets the SQLite corpus without a flag.

$ npx bolvrk check
Prisma: checking 3 migration files under prisma/migrations/*/migration.sql (postgres).

# pick one, or turn detection off
npx bolvrk check --framework=drizzle
npx bolvrk check --framework=none migrations/*.sql

What is recognised

Prisma (prisma/migrations/*/migration.sql), Drizzle (drizzle/*.sql), Supabase (supabase/migrations/*.sql), Flyway (V*__*.sql under sql/, db/migration/ or src/main/resources/db/migration/), Liquibase formatted SQL changelogs, dbmate (db/migrations/*.sql, the migrate:up section only), golang-migrate (*.up.sql), sqlx, Atlas, Sqitch (deploy/*.sql) and Hasura (migrations/**/up.sql). A bare migrations/ folder only counts when a matching file exists, so an unrelated directory of that name claims nothing.

The framework's own format is never parsed and no DSL is interpreted: an adapter is a directory layout, the globs for the forward direction, and at most a slice of the file. Frameworks whose migrations are code rather than SQL (Rails, Django, Knex, TypeORM) are not detected; the SQL they run only exists when they run, and checking that is the next surface.

Try it on your next migration

The CLI is open source and needs no account: npx bolvrk check migration.sql

Also in Getting started