A non-idempotent ALTER TABLE ADD COLUMN migration is executed twice — common when CI/CD pipelines retry failed jobs without checking which DDL statements already succeeded.. A CREATE TABLE statement contains the same column name listed more than once, often caused by copy-paste errors or poorly merged SQL files from parallel feature branches.. ORM or code-generation tools (SQLAlchemy autogenerate, Django makemigrations) produce duplicate column definitions when model changes are created independently on two branches and then merged.. A dbt model uses a SELECT * join across two tables that share a column name, and the result is materialized into a new table — the duplicate column name triggers 1060 during CREATE TABLE AS SELECT.. Manual hotfix scripts are run against production without checking migration state, re-adding a column that was already applied by the regular migration pipeline.

Step 1: Confirm which column is duplicated. Read the full error message — it includes the column name: `ERROR 1060 (42S21): Duplicate column name 'status'`. Note the exact name.. Step 2: Check if the column already exists in the table: `SELECT column_name, data_type, ordinal_position FROM information_schema.columns WHERE table_schema = 'your_db' AND table_name = 'your_table' AND column_name = 'status';`. Step 3: If the column exists and your migration tried to add it, make the migration idempotent. Wrap the ALTER in a stored procedure: `DELIMITER // CREATE PROCEDURE add_col_if_missing() BEGIN IF NOT EXISTS (SELECT 1 FROM information_schema.columns WHERE table_schema='your_db' AND table_name='your_table' AND column_name='status') THEN ALTER TABLE your_table ADD COLUMN status VARCHAR(50); END IF; END // DELIMITER ; CALL add_col_if_missing(); DROP PROCEDURE add_col_if_missing;`. Step 4: If the error comes from a CREATE TABLE with duplicate column names, inspect the DDL: `SHOW CREATE TABLE your_table;` or search your migration file for the duplicated column name. Remove the duplicate definition.. Step 5: If the error originates from a SELECT * join in dbt or a CTAS statement, explicitly list columns instead of using SELECT *. Alias the duplicate: `SELECT a.status AS source_status, b.status AS target_status FROM table_a a JOIN table_b b ON a.id = b.id;`. Step 6: Mark the migration as applied in your migration tool if you confirmed the column already exists. For Flyway: `flyway repair` to fix the schema history table. For Liquibase: insert a row into DATABASECHANGELOG manually.. Step 7: Re-run the pipeline. In ADF: rerun the failed activity from the pipeline monitor. In Airflow: clear the failed task instance. Verify the downstream models complete successfully.

Medium severityschema

MySQL Error:
1060

What does this error mean?

MySQL raises error 1060 when a CREATE TABLE or ALTER TABLE statement attempts to add a column whose name already exists in the target table. In data-pipeline contexts this typically surfaces during schema migrations executed by dbt, Flyway, or raw SQL scripts embedded in ADF or Airflow tasks. The symptom is immediate: the DDL statement fails, the pipeline activity errors out, and any downstream models or transformations that depend on the altered table are skipped or marked failed. Engineers usually encounter this after re-running a migration that was already applied, or when two branches independently add the same column and both get merged. The error is deterministic — retrying the same statement will always fail until the duplicate reference is removed or the migration is made idempotent.

Common causes

1A non-idempotent ALTER TABLE ADD COLUMN migration is executed twice — common when CI/CD pipelines retry failed jobs without checking which DDL statements already succeeded.
2A CREATE TABLE statement contains the same column name listed more than once, often caused by copy-paste errors or poorly merged SQL files from parallel feature branches.
3ORM or code-generation tools (SQLAlchemy autogenerate, Django makemigrations) produce duplicate column definitions when model changes are created independently on two branches and then merged.
4A dbt model uses a SELECT * join across two tables that share a column name, and the result is materialized into a new table — the duplicate column name triggers 1060 during CREATE TABLE AS SELECT.
5Manual hotfix scripts are run against production without checking migration state, re-adding a column that was already applied by the regular migration pipeline.

How to fix it

1Step 1: Confirm which column is duplicated. Read the full error message — it includes the column name: `ERROR 1060 (42S21): Duplicate column name 'status'`. Note the exact name.
2Step 2: Check if the column already exists in the table: `SELECT column_name, data_type, ordinal_position FROM information_schema.columns WHERE table_schema = 'your_db' AND table_name = 'your_table' AND column_name = 'status';`
3Step 3: If the column exists and your migration tried to add it, make the migration idempotent. Wrap the ALTER in a stored procedure: `DELIMITER // CREATE PROCEDURE add_col_if_missing() BEGIN IF NOT EXISTS (SELECT 1 FROM information_schema.columns WHERE table_schema='your_db' AND table_name='your_table' AND column_name='status') THEN ALTER TABLE your_table ADD COLUMN status VARCHAR(50); END IF; END // DELIMITER ; CALL add_col_if_missing(); DROP PROCEDURE add_col_if_missing;`
4Step 4: If the error comes from a CREATE TABLE with duplicate column names, inspect the DDL: `SHOW CREATE TABLE your_table;` or search your migration file for the duplicated column name. Remove the duplicate definition.
5Step 5: If the error originates from a SELECT * join in dbt or a CTAS statement, explicitly list columns instead of using SELECT *. Alias the duplicate: `SELECT a.status AS source_status, b.status AS target_status FROM table_a a JOIN table_b b ON a.id = b.id;`
6Step 6: Mark the migration as applied in your migration tool if you confirmed the column already exists. For Flyway: `flyway repair` to fix the schema history table. For Liquibase: insert a row into DATABASECHANGELOG manually.
7Step 7: Re-run the pipeline. In ADF: rerun the failed activity from the pipeline monitor. In Airflow: clear the failed task instance. Verify the downstream models complete successfully.

Example log output

2026-05-11 08:14:32 ERROR 1060 (42S21) at line 14: Duplicate column name 'last_modified'
mysql> ALTER TABLE pipeline_runs ADD COLUMN last_modified DATETIME DEFAULT CURRENT_TIMESTAMP;
ERROR 1060 (42S21): Duplicate column name 'last_modified'

Frequently asked questions

Does MySQL 8.0 support ALTER TABLE ADD COLUMN IF NOT EXISTS?

No — MySQL does not support IF NOT EXISTS for ADD COLUMN (MariaDB does since 10.0). In MySQL you need a stored procedure that checks information_schema.columns first, or handle the error at the application level with a try/catch that ignores error code 1060.

How can I make schema migrations idempotent in MySQL?

Check information_schema.columns before each ADD COLUMN using a stored procedure wrapper. Use a versioned migration tool like Flyway or Liquibase that records which migrations have been applied. Never run raw migration scripts manually without checking the migration state table first.

Why does my dbt model throw error 1060 on a JOIN?

When dbt materializes a model as a table and your SELECT includes columns with the same name from different tables (e.g., both have an 'id' or 'status' column), the CREATE TABLE AS SELECT fails with 1060. Fix it by explicitly listing columns and aliasing duplicates instead of using SELECT *.

Will retrying the pipeline fix error 1060?

No. Error 1060 is deterministic — the same DDL against the same table state will always fail. Retrying wastes compute and blocks the pipeline. You must either remove the duplicate column reference from the DDL or skip the migration if the column already exists.

Source · dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html