This error occurs when Flyway attempts to migrate an existing PostgreSQL database that has tables but no Flyway schema history table. Flyway refuses to proceed to prevent data loss. Enable baselineOnMigrate or manually baseline the schema to resolve this.
Flyway is a database migration tool that tracks all applied migrations in a dedicated schema history table (typically named flyway_schema_history or schema_version). When you run Flyway on an existing database that already contains tables but lacks this tracking table, Flyway cannot determine what migrations have already been applied. To prevent accidentally re-running or skipping migrations and causing data corruption, Flyway fails with this error. This typically happens when: - You have an existing database created before adopting Flyway - You are integrating Flyway into a legacy application - The schema history table was accidentally deleted - You are using the wrong database or schema configuration
The recommended solution is to enable baseline mode, which tells Flyway to initialize the schema history table and treat the current state as the baseline.
For Spring Boot applications, add to application.properties or application.yml:
spring.flyway.baseline-on-migrate=trueOr in YAML:
spring:
flyway:
baseline-on-migrate: trueIf configuring via Java code instead of properties:
Flyway flyway = Flyway.configure()
.dataSource(dataSource)
.baselineOnMigrate(true)
.load();
flyway.migrate();This initializes the schema history table with a baseline version of 1, marking all existing tables as "already applied".
After baselining, Flyway will record version 1 in the schema history table. If you have migration files starting with V1__, they will be rejected.
Rename your first migration file to start from V2__:
# Before
V1__Initial_schema.sql
# After
V2__Initial_schema.sqlAll subsequent migrations should be numbered V3__, V4__, etc.
After configuration and baselining, run your migrations:
./mvnw clean package spring-boot:run
# or
gradlew bootRunFlyway will now:
1. Create the flyway_schema_history table
2. Insert a baseline record (version 1)
3. Apply all subsequent migrations (V2__, V3__, etc.) in order
After successful migration, verify the schema history table exists and has the baseline record:
SELECT * FROM flyway_schema_history;You should see output showing:
- installed_rank: 1
- version: 1 (or your baseline version)
- description: "BaselineDB" or "Baseline"
- type: "BASELINE"
- installed_by: Your user
- installed_on: Current timestamp
- success: true
PostGIS and Other Extensions: When using PostgreSQL extensions like PostGIS, the extensions create system tables in your schema (e.g., spatial_ref_sys). These pre-existing tables trigger the "non-empty schema" error. Baselining is the correct approach here—Flyway will create its history table alongside the extension tables without conflict.
Different Schema Configuration: If you specify a custom schemaSearchPath in your Flyway configuration, ensure it points to the schema where you want the history table created. For PostgreSQL, specify the schema explicitly in the configuration.
Alternative Approach (Not Recommended): You can manually create the schema history table before running Flyway, but this is error-prone and not recommended—let baselineOnMigrate handle it instead.
Migration File Versioning: Remember that after baseline (version 1), your first real migration must be V2 or higher. Version numbering cannot have gaps or out-of-order files. Use semantic versioning (V2__, V3__, V10__) rather than timestamps to avoid ordering issues.
ERROR: syntax error at end of input
Syntax error at end of input in PostgreSQL
Bind message supplies N parameters but prepared statement requires M
Bind message supplies N parameters but prepared statement requires M in PostgreSQL
Multidimensional arrays must have sub-arrays with matching dimensions
Multidimensional arrays must have sub-arrays with matching dimensions
ERROR: value too long for type character varying
Value too long for type character varying
insufficient columns in unique constraint for partition key
How to fix "insufficient columns in unique constraint for partition key" in PostgreSQL