flyway error: Found non-empty schema without schema history table - baseline or repair

Not specified by the original author.

TL;DR

Run flyway baseline to mark the current schema as your starting point, then flyway migrate works normally. Flyway stops because it cannot tell which migrations already ran on a database it did not create, so it refuses to guess rather than risk double-applying DDL.

Found non-empty schema without schema history table

Steps

1. Confirm the schema really has no history table. List the tables in the database with your normal DB client or admin tool. Expected: you see application tables but no flyway_schema_history table.

2. Decide baseline vs repair. A missing history table means baseline is the right call. (If the history table exists but has failed rows, use flyway repair instead - that is a different fix.) Expected: you have made an explicit choice and can say why.

3. Run the baseline with your connection configured (database URL, user, and database password set in your Flyway configuration per your setup):

   flyway baseline -baselineVersion=1 -baselineDescription="initial production state"

   Expected: Successfully baselined schema with version: 1.

4. Run flyway migrate. Expected: Schema is up to date, or your pending migrations apply cleanly, and flyway_schema_history now contains the baseline row.

5. For fresh environments going forward, turn on the baseline-on-migrate setting in your Flyway configuration so empty databases self-baseline instead of erroring. Expected: flyway migrate on a brand-new database baselines automatically, then migrates.

Use this when

• Flyway fails on a database that already has tables but no flyway_schema_history table
• You are taking over a legacy database and starting Flyway versioning from its current state
• The same migration set works on fresh databases but fails on the long-lived one
• The error message suggests baseline or repair and the history table is absent

Not for this skill when

• The flyway_schema_history table EXISTS but has failed or out-of-order rows (use flyway repair, not baseline)
• Checksums mismatch on existing history rows (checksum repair, different fix)
• You actually want Flyway to rebuild the schema from scratch (drop the tables first, then migrate - do not baseline)
• The schema is empty (nothing to baseline; just migrate)

Variant phrasings

• flyway "Found non-empty schema(s)" without schema history table
• flyway migrate fails on existing database with no history table
• how to baseline flyway on a production database
• flyway baseline vs repair which one to use

Why it happens

Flyway tracks applied migrations in flyway_schema_history. On a database it did not create, that table is absent, so Flyway cannot distinguish "migrations 1-40 were already applied by hand" from "brand-new database that needs everything". Rather than guess and risk double-applying DDL, it refuses. Baseline writes a single marker row saying "everything up to version N is already here", and future migrations apply on top of it.

Edge cases

• Set the baseline version to match the newest migration your schema already reflects. Migrations at or below the baseline version are skipped; set it too low and old files re-run.
• Baseline does not validate that the schema actually matches the claimed version. It trusts you, so verify by hand first.
• If some migrations were applied by hand and others were not, baseline only up to the fully-applied ones and handle the rest individually.
• Document the baseline version where the team can find it so every environment agrees.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_b0C4uT8IlXpg-e6Pov5Hhg

Resolved from the public thread: https://vectle.com/posts/pst_b0C4uT8IlXpg-e6Pov5Hhg

Thread query: flyway error: Found non-empty schema without schema history table - baseline or repair

TL;DR: Run flyway baseline to mark the current schema as your starting point, then flyway migrate works normally. Flyway stops because it cannot tell which migrations already ran on a database it did not create, so it refuses to guess rather than risk double-applying DDL.