When building real-world applications, database schema changes are unavoidable.
Manual DDL changes or relying on Hibernate’s auto schema generation (hbm2ddl.auto) is risky for production.
✅ Solution: Use Database Migration Tools like Flyway or Liquibase in Micronaut.
Micronaut fully supports two of the most popular tools:
- Flyway
- Liquibase
Both tools:
- Version your database schema.
- Apply migrations automatically.
- Work across all supported databases (H2, PostgreSQL, MySQL, etc).
- Integrate beautifully with Micronaut.

🔧 Why Use Migration Tools?
| Problem | Solution |
|---|---|
| Manual SQL scripts | Version-controlled migrations |
| Deployment errors | Auto-run migrations |
| Inconsistent schemas | Single source of truth |
| Difficult rollback | Versioned rollbacks |
🚀 Option 1: Flyway Integration
🔨 Adding Flyway Dependency
For Maven:
io.micronaut.flyway
micronaut-flyway
✅ Micronaut will auto-discover Flyway and run migrations at startup.
🔨 Flyway Configuration
Add to application.yml:
flyway:
datasources:
default:
enabled: true
You can configure multiple datasources if needed.
🔨 Create Migration Files
By default, Flyway expects migration files inside:
src/main/resources/db/migration/
Sample Migration: V1__create_students.sql
CREATE TABLE students (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(255) NOT NULL,
date_of_birth DATE,
email VARCHAR(255)
);
✅ The filename format V<version>__<description>.sql is important!
🔨 Flyway Run Flow
When Micronaut starts:
- Flyway scans existing migrations.
- Runs any pending migrations.
- Ensures schema is up-to-date.
🔨 Verify Flyway Execution
You’ll see logs like:
Successfully validated 1 migration (execution time 00:00.012s)
Current version of schema: 1
Schema version 1 is up to date. No migration necessary.
✅ Flyway maintains a flyway_schema_history table to track applied migrations.
🚀 Option 2: Liquibase Integration
🔨 Adding Liquibase Dependency
For Maven:
io.micronaut.liquibase
micronaut-liquibase
✅ Like Flyway, Micronaut automatically configures Liquibase at startup.
🔨 Liquibase Configuration
Add to application.yml:
liquibase:
datasources:
default:
enabled: true
🔨 Create changelog XML
By default, Liquibase expects changelogs in:
src/main/resources/db/liquibase/
Sample Master Changelog: db-changelog.xml
🔨 Liquibase Run Flow
- Liquibase reads the changelog XML.
- Applies changes not yet applied.
- Tracks changes in
DATABASECHANGELOGtable.
✅ Like Flyway, it’s fully versioned.
⚖ Flyway vs Liquibase
| Feature | Flyway | Liquibase |
|---|---|---|
| Language | Pure SQL (or Java) | XML, YAML, JSON, SQL |
| Learning Curve | Easier | Slightly steeper |
| Complex Refactoring | Limited | More powerful |
| Community | Very active | Very active |
| Micronaut Support | Native | Native |
✅ Both are excellent; pick based on your team’s comfort level.
🐞 Common Migration Errors
| Error | Cause | Solution |
|---|---|---|
| Migration fails | Invalid SQL | Review syntax carefully |
| Migration skipped | Incorrect version number | Use consistent versioning |
| Duplicate execution | Changing existing migration files | Never change files already applied |
🔐 Best Practices for Production
✅ Always run migrations before app starts (CI/CD).
✅ Use version control for migration files.
✅ Never modify applied migrations — create new versions for changes.
✅ Test migrations on staging before production.
🌐 External References
✅ Summary
- ✅ Flyway and Liquibase manage your DB schema versions.
- ✅ Micronaut integrates with both seamlessly.
- ✅ Pick Flyway for simplicity, Liquibase for complex migrations.
- ✅ Never rely on
hbm2ddl.autofor production.