DriftQL

About

DriftQL reads your schema, diffs it against production, and writes the migration for you. Every generated migration comes with a rollback path and a plain-language summary of what will change, so review takes seconds instead of an afternoon.

The problem it actually solves

Schema migrations are the part of the job where a small mistake is expensive and slow to undo. Most teams write them by hand, review them quickly because they are hard to read, and then find out what they did on deploy night. DriftQL was built by people who had that night more than once.

Instead of asking you to describe the change twice, once in the schema and once in the migration, it reads both sides. It connects to the database you are about to change, diffs it against the schema in your repository, and produces the migration that closes the gap. What you review is the plan, not the plumbing.

Reviews that a human can actually do

Every generated migration ships with a plain-language summary at the top. Not a restatement of the SQL, but a description of the consequence: which columns become nullable, which index will be rebuilt, roughly how long the lock is expected to hold, and which of those steps cannot be undone.

This turns out to matter more than the generation itself. A reviewer who can read the summary in ten seconds will actually read it. A reviewer facing four hundred lines of DDL will approve it and hope. The team behind DriftQL has been fairly direct that the summary is the product and the SQL generation is the feature that makes it possible.

Rollbacks are written up front

Every migration comes with its reverse. Where a reverse is genuinely impossible, dropping a column with data in it, for instance, DriftQL says so explicitly rather than generating something that looks reversible and is not.

That honesty shows up in the workflow. Destructive steps are separated from safe ones so you can ship the safe half immediately and schedule the rest. On a large table, that difference is the gap between a deploy and an outage.

Where it fits, and where it does not

Postgres support is the most complete, which is unsurprising given where it started. MySQL works well for ordinary column and index changes but has rougher edges around enum changes, something the maintainers acknowledge in the open issues. SQLite is supported mainly so local development matches production tooling.

It is not an ORM and does not want to be. If you already use Prisma, Drizzle or plain SQL files, DriftQL sits alongside them and takes over only the migration step. That narrow scope is the reason it is worth adding to a stack that already has opinions.

What it does

• Schema diffing against live databases
• Automatic rollback generation
• Plain-language migration summaries
• Works with Postgres, MySQL and SQLite

• Mara Ellis @maraellis · 2d

  Been using this on a 40-table schema all week. The rollback generation alone saved me twice. One request: a dry-run flag that prints the SQL without touching anything.

• Devin Roy @droy · 3d

  The plain-language summaries are the killer feature. My non-technical PM can review migrations now, which I did not expect to ever type.

• Sana Qureshi @sanaq · 4d

  Works well with Postgres. MySQL support felt a bit behind, the enum diffing missed a case for me. Filed an issue and got a response the same day.