SQL ALTER TABLE Generator
Instead of writing ALTER TABLE statements by hand, paste the table as it is and as it should be. The generator compares the two definitions and writes the migration in your database’s syntax: new columns in the right position, type and NULL changes, defaults, renamed columns, primary keys, unique constraints, indexes and foreign keys, with warnings for changes that can fail or lose data. For SQLite it writes the full table rebuild that SQLite requires.
- Runs in your browser
- No sign-up
- Free to use
How to use SQL ALTER TABLE Generator
- Choose the database.
- Paste the current CREATE TABLE in the first box.
- Paste the desired CREATE TABLE in the second box.
- Review the warnings and copy the migration.
SQL ALTER TABLE Generator features
Schema diff
Columns, types, nullability, defaults, keys, indexes and foreign keys.
Rename detection
One dropped and one added column of the same type become a RENAME.
Dialect syntax
MODIFY, ALTER COLUMN … TYPE … USING, sp_rename and more.
SQLite rebuild
New table, data copy, drop and rename, as SQLite requires.
Risk warnings
Shrinking types, new NOT NULL columns and dropped data.
Several tables
New and removed tables are handled too.
When to use SQL ALTER TABLE Generator
- Writing a migration after editing a schema file.
- Bringing a production table in line with a development schema.
- Learning ALTER TABLE syntax for a database.
- Reviewing what a schema change will actually do.
SQL ALTER TABLE Generator FAQ
How are renames recognised?
When exactly one column disappears and one of the same type and nullability appears, the change is written as RENAME COLUMN so the data is kept. Untick the option if it is really a new column.
Why does SQLite get a whole new table?
SQLite’s ALTER TABLE can only add, rename and drop columns. Changing a type, a constraint or a key requires creating a new table, copying the rows and renaming it, exactly as the SQLite documentation describes.
Why are some statements followed by warnings?
Some changes can fail on existing data, such as adding NOT NULL to a column that contains NULLs or shrinking a VARCHAR. The warnings suggest how to prepare the data first.
What about constraint names?
Dropping an index or foreign key needs its name. When the current definition does not name it, a generated name is used and a note asks you to check the real one.
Is a transaction safe in MySQL?
MySQL commits each ALTER TABLE immediately, so the transaction does not make the migration atomic. Test migrations on a copy of the data first.
Is anything executed?
No. The definitions are only parsed and compared in your browser.
From schema change to migration
Schemas evolve: columns are added, renamed and resized, keys change and indexes come and go. Writing the ALTER TABLE statements by hand is error-prone, because the syntax differs between databases and some changes need preparation. Comparing two complete definitions and deriving the statements is more reliable, and it is how many migration tools work.
The generator parses both CREATE TABLE statements into the same model and compares them column by column. New columns become ADD COLUMN, in MySQL positioned with AFTER so the column order matches the new definition. Changed columns become MODIFY COLUMN in MySQL, separate TYPE, SET/DROP NOT NULL and SET/DROP DEFAULT clauses in PostgreSQL, and ALTER COLUMN in SQL Server.
A column that disappears while another of the same type appears is often a rename. Dropping and adding would lose the data, so the generator writes RENAME COLUMN, or sp_rename in SQL Server, and asks you to confirm. Changes to the primary key, unique constraints, indexes and foreign keys are compared by their columns and written as the matching ADD and DROP statements.
SQLite is a special case. Its ALTER TABLE supports only adding, renaming and dropping columns, so any other change is written as the documented rebuild: switch off foreign keys, create the new table, copy the rows, drop the old table, rename the new one, recreate the indexes and check foreign keys before committing.
Every risky step gets a note: adding a NOT NULL column without a default fails on a table with rows, shrinking a type can fail or truncate values, and dropping columns or tables loses their data. Run the migration on a copy first and keep a backup.