The database was already dropped by a previous run of the same teardown script, and the script does not use IF EXISTS.. A typo in the database name — e.g., analytics_stg vs analytics_staging — causes the DROP to target a name that was never created.. The MySQL connection string points to a different server or instance than intended (common when dev/staging/prod share similar hostnames).. An earlier migration step that was supposed to CREATE the database failed silently, so the database never existed in the first place.. dbt's run-operation or on-run-end hook issues DROP DATABASE against a schema that was already cleaned up by a parallel job or a cron-based cleanup process.. Replication lag: a DROP DATABASE was executed on the primary but the script immediately re-runs on a replica where the DROP has not yet propagated.

Step 1: Switch to the idempotent form: `DROP DATABASE IF EXISTS your_db;` — this returns a warning (Note 1008) instead of a fatal error.. Step 2: Confirm which databases exist on the target server: `SHOW DATABASES;` or `SELECT SCHEMA_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'your_db';`. Step 3: Verify you are connected to the correct host: `SELECT @@hostname, @@port;` and compare with your connection string.. Step 4: Check if a previous step failed and never created the database: review the pipeline run log for earlier CREATE DATABASE failures or skipped steps.. Step 5: For dbt projects, wrap teardown macros in an existence check: `{% if adapter.check_schema_exists(database, schema) %} ... {% endif %}`.. Step 6: If the database name is dynamic (e.g., branch-based CI databases), log the resolved name before the DROP to catch typos: `SELECT CONCAT('Dropping: ', 'your_db') AS info; DROP DATABASE IF EXISTS your_db;`. Step 7: After fixing, run `SHOW WARNINGS;` immediately after the DROP IF EXISTS to confirm the 1008 note is returned cleanly — this validates idempotency without masking other issues.

Low severityschema

MySQL Error:
1008, Database Doesn't Exist

Impact

When error 1008 blocks a CI/CD teardown step, every subsequent pipeline stage (schema recreation, data load, test run) is skipped. Downstream tables go stale, scheduled refreshes report failure, and SLA timers start ticking on data that is not being updated.

Error 1008 is a hard failure — the DROP statement stops execution, and any subsequent SQL in the same script or activity does not run. In CI/CD pipelines this means the database is never recreated, test data is never loaded, and integration tests are skipped or fail with unrelated errors. In scheduled ETL jobs the effect cascades: downstream tables that depend on the staging database are not refreshed, dashboards show stale data, and freshness SLA alerts fire. The fix is quick (add IF EXISTS), but the blast radius grows the longer the pipeline stays broken.

What does this error mean?

MySQL raises error 1008 (ER_DB_DROP_EXISTS) when a DROP DATABASE statement targets a database name that does not exist on the server. The server checks the data directory for a matching subdirectory and, if absent, returns ERROR 1008 (HY000): Can't drop database 'db_name'; database doesn't exist. In data pipelines this typically surfaces during environment teardown steps, CI/CD cleanup jobs, or dbt run-operation calls that drop staging schemas between runs. The symptom in orchestrators like ADF or Airflow is a failed Script or Stored Procedure activity with exit code 1 and the 1008 error in stderr. The statement is non-transactional — any objects already removed before the failure stay removed.

Common causes

1The database was already dropped by a previous run of the same teardown script, and the script does not use IF EXISTS.
2A typo in the database name — e.g., analytics_stg vs analytics_staging — causes the DROP to target a name that was never created.
3The MySQL connection string points to a different server or instance than intended (common when dev/staging/prod share similar hostnames).
4An earlier migration step that was supposed to CREATE the database failed silently, so the database never existed in the first place.
5dbt's run-operation or on-run-end hook issues DROP DATABASE against a schema that was already cleaned up by a parallel job or a cron-based cleanup process.
6Replication lag: a DROP DATABASE was executed on the primary but the script immediately re-runs on a replica where the DROP has not yet propagated.

How to fix it

1Step 1: Switch to the idempotent form: `DROP DATABASE IF EXISTS your_db;` — this returns a warning (Note 1008) instead of a fatal error.
2Step 2: Confirm which databases exist on the target server: `SHOW DATABASES;` or `SELECT SCHEMA_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'your_db';`
3Step 3: Verify you are connected to the correct host: `SELECT @@hostname, @@port;` and compare with your connection string.
4Step 4: Check if a previous step failed and never created the database: review the pipeline run log for earlier CREATE DATABASE failures or skipped steps.
5Step 5: For dbt projects, wrap teardown macros in an existence check: `{% if adapter.check_schema_exists(database, schema) %} ... {% endif %}`.
6Step 6: If the database name is dynamic (e.g., branch-based CI databases), log the resolved name before the DROP to catch typos: `SELECT CONCAT('Dropping: ', 'your_db') AS info; DROP DATABASE IF EXISTS your_db;`
7Step 7: After fixing, run `SHOW WARNINGS;` immediately after the DROP IF EXISTS to confirm the 1008 note is returned cleanly — this validates idempotency without masking other issues.

Example log output

ERROR 1008 (HY000) at line 3: Can't drop database 'analytics_staging'; database doesn't exist

Frequently asked questions

How do I make DROP DATABASE idempotent in MySQL?

Use `DROP DATABASE IF EXISTS your_db;` — MySQL returns a warning (Note 1008) instead of a fatal error. You can verify with `SHOW WARNINGS;` immediately after. This is the standard pattern for teardown scripts and CI/CD cleanup jobs.

What happens to active connections when I drop a database in MySQL?

MySQL drops the database immediately and removes the data directory. Active connections whose default database was the dropped one will get ERROR 1046 (No database selected) on their next query. There is no graceful disconnect or warning — the connections stay open but are effectively orphaned.

Can MySQL error 1008 appear in ADF or Airflow pipelines?

Yes, but only in activities that execute DDL — Script activities, Stored Procedure activities, or Airflow MySqlOperator tasks that run teardown SQL. Standard ADF Copy activities and Lookup activities do not issue DROP DATABASE and will never trigger 1008.

Does DROP DATABASE IF EXISTS still fail if I lack permissions?

Yes. IF EXISTS only suppresses the 'database doesn't exist' error. If your MySQL user lacks the DROP privilege on the target database, you get ERROR 1044 (Access denied) regardless of IF EXISTS. Check grants with `SHOW GRANTS FOR CURRENT_USER();`.

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