b2KIT

SQL Migration Generator

Generate migration scripts (up/down) for schema changes with ALTER TABLE, ADD COLUMN, and rollback.

Tested tool guide Tested browser tools Checked August 16, 2026

What SQL Migration Generator does, with a checked example

Describe a schema change - typically adding a column to an existing table - and this tool writes the pair of scripts a migration needs: an up script that applies the change and a down script that reverses it. The output is SQL you review, then drop into your migration file or runner. What surprises people is that the down script is structural only: rollback of an added column is DROP COLUMN, and every value in that column goes with it. A migration rollback restores the schema, never the data.

Worked example

A concrete input and expected output from the current implementation.

Input

Add a column "email" of type varchar(255) to table "users"

Expected output

-- up
ALTER TABLE users ADD COLUMN email VARCHAR(255);

-- down
ALTER TABLE users DROP COLUMN email;

The up script applies the requested change, and the down script is its exact inverse, which is what makes the pair a reversible migration. Running up and then down returns the users table to its original shape.

How the result is produced

1

Mirrored up and down scripts

The output is a pair of SQL scripts. The up script holds the ALTER TABLE statement that applies the change; the down script holds the statement that reverses it - ADD COLUMN is inverted by DROP COLUMN, and dropping a column is inverted by re-adding it with the definition you supplied. Run up to apply the change, run down afterward to return the table to its previous shape.

2

Structure only, data untouched

The scripts act on the table's structure only - nothing in the output copies, moves, or backs up row data. If the down script drops a column, the values in that column are gone once the script runs, so the pair is a structural undo, not a data recovery path. Plan a real backup before applying anything if the column's content matters.

Good uses

  • Adding a column to a table that already exists in production, when you need the ALTER TABLE statement and its rollback written as a consistent pair instead of by hand.
  • Drafting a pull request that introduces a schema change, so reviewers see the up and down scripts together and the change can be reverted if the deploy goes wrong.
  • Writing the missing down migration for a change that shipped earlier, when your migration folder holds the up script but no rollback.

Limits and checks

  • Engine spelling differs. The statement shape is portable, but details are not: SQL Server writes ADD without the COLUMN keyword, and adding a NOT NULL column to a table that already has rows fails without a DEFAULT in most engines. Compare the output against your database's ALTER TABLE syntax and your table's data before running it.
  • Rollback discards data. The down script reverses the schema, not the content. Once users have written to a column, rolling back deletes those values permanently, so treat the pair as a structural undo only - take a real backup first if the data matters.
  • Inverting a type change needs the old definition. If the change alters an existing column instead of adding one, the down script must restore the original type and any default or constraint. Provide the before and after definitions, then check the generated down script really restores the old one.

Common questions

Does the down script bring back my data?

No. It restores the schema: a column added by the up script is removed with DROP COLUMN, and the data in it goes with it. Migration rollbacks are structural by design. If you may need the values back, back up the table before running the up script and keep that backup past the rollback window.

Can I run the generated scripts directly against my database?

The scripts are ordinary SQL, so they run in a query tool when the syntax matches your engine. In a real project they belong in the folder your migration runner executes in order, and most runners record which migrations have already run. Executing the ALTER TABLE outside that flow leaves that record out of step, so place the pair where your runner expects it and let the runner apply it.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools

JSON Formatter & Validator

Format, validate, and beautify JSON with syntax highlighting and error detection.

Base64 Encoder / Decoder

Encode text or files to Base64 and decode Base64 strings back to their original form.

SQL Formatter & Beautifier

Format and indent SQL queries for better readability across all major dialects.

HTML to Markdown Converter

Convert HTML markup into clean Markdown syntax with support for tables and lists.

Markdown to HTML Live Preview

Write Markdown and see the rendered HTML output in real time with live preview.

Diff / Patch Viewer

Visualize unified diffs and patch files with color-coded additions and deletions.