Flyway vs Liquibase: Generating Database Migrations with AI
Database migrations are the unsung heroes of every reliable production system. They're also one of the most tedious, error-prone pieces of DevOps work imaginable — until you hand them to an AI with the right prompt.
Every backend engineer on a team with more than one person needs a migration strategy. Without one, your production database schema and your code will eventually diverge, and the results are never good. Flyway and Liquibase are the two dominant tools for versioned database migrations on the JVM ecosystem, but they work differently, have different file formats, and suit different teams.
In this guide, we'll compare Flyway and Liquibase in practical terms, then provide engineered AI prompts that generate complete, production-ready migration scripts for both tools — so you can stop writing boilerplate SQL and XML by hand.
Flyway vs. Liquibase: The Core Differences
| Feature | Flyway | Liquibase |
|---|---|---|
| Migration Format | Plain SQL files (.sql) | XML, YAML, JSON, or SQL changesets |
| Naming Convention | V1__description.sql | changelog.xml with changeset IDs |
| Rollback Support | Manual (Pro feature for auto) | Built-in (rollback tags & commands) |
| Database Support | 30+ databases | 50+ databases |
| Spring Boot Integration | Native auto-configuration | Requires liquibase-core dependency |
| Best For | Teams who love SQL clarity | Teams needing complex diff/rollback tooling |
Bottom line: If your team is comfortable with SQL and wants simplicity, use Flyway. If you need rollback strategy, complex diff operations, or multi-database support, Liquibase is the more powerful choice.
Why Use AI for Database Migration Generation?
Database migrations follow highly deterministic rules. Given a clear before-and-after schema description, there's essentially one correct migration to write. This makes it one of the safest and most effective use cases for AI code generation — but only with a sufficiently precise prompt.
Vague prompts produce dangerous migrations. "Add a users table" will get you something syntactically correct but missing constraints, indexes, default values, and foreign key cascades you actually need in production. Engineered prompts produce complete, conflict-free migrations that you can commit directly to your repository.
Prompt 1: Flyway — Initial Schema Setup
Use this prompt to generate a Flyway V1 migration file that creates a complete user authentication schema with best-practice constraints:
"Act as a Senior Database Architect specializing in PostgreSQL and Flyway. Generate a complete Flyway SQL migration file named V1__create_user_auth_schema.sql. The migration must create: (1) A 'users' table with: id UUID PRIMARY KEY DEFAULT gen_random_uuid(), email VARCHAR(255) UNIQUE NOT NULL, password_hash VARCHAR(255) NOT NULL, full_name VARCHAR(100), created_at TIMESTAMPTZ DEFAULT NOW(), updated_at TIMESTAMPTZ DEFAULT NOW(), is_active BOOLEAN DEFAULT true, last_login TIMESTAMPTZ. (2) A 'user_sessions' table with: id UUID PRIMARY KEY, user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE, session_token VARCHAR(512) UNIQUE NOT NULL, expires_at TIMESTAMPTZ NOT NULL, created_at TIMESTAMPTZ DEFAULT NOW(). (3) Create B-tree indexes on users.email and user_sessions.session_token. (4) Create a trigger function that automatically updates the updated_at column on any UPDATE to the users table. Include all semicolons and ensure the script is idempotent where possible."Prompt 2: Flyway — Adding Columns Safely
One of the most common migration tasks is adding new columns to existing tables. The tricky part is doing this in a way that's safe for live production databases — especially if you're using zero-downtime deployments:
"Act as a Senior Database Engineer. Write a Flyway migration file V3__add_subscription_fields_to_users.sql for PostgreSQL. This migration adds subscription-related columns to an existing 'users' table in a live production database using a zero-downtime strategy. Requirements: (1) Add 'subscription_tier' VARCHAR(20) DEFAULT 'free' NOT NULL. (2) Add 'subscription_expires_at' TIMESTAMPTZ NULL. (3) Add 'stripe_customer_id' VARCHAR(100) NULL. (4) Add a partial index on users WHERE subscription_tier != 'free' for efficient premium user queries. (5) Use ALTER TABLE ... ADD COLUMN IF NOT EXISTS syntax where the PostgreSQL version supports it for idempotency. (6) Add a comment explaining why each column exists. Structure this as a transactional migration block using BEGIN/COMMIT."Prompt 3: Liquibase — Complete XML Changelog
Liquibase's XML format is more verbose than Flyway's SQL, but it enables the built-in rollback system. This prompt generates a complete, multi-changeset XML changelog file:
"Act as a Liquibase expert. Generate a complete Liquibase XML changelog file (db/changelog/db.changelog-001.xml) that creates a product catalog schema for a SaaS application. The changelog must contain three separate changesets: (1) changeset id='001' creates the 'products' table with id, name, description, price_cents (BIGINT), currency (VARCHAR 3), is_published (BOOLEAN), and timestamps. Include a rollback block using <dropTable>. (2) changeset id='002' creates the 'product_features' table referencing products with a CASCADE delete constraint. Include a rollback block. (3) changeset id='003' creates indexes on product.name and product_features.product_id. Include the correct XML namespace headers for Liquibase 4.x. Auto-commit must be false. Set author to 'naveen-blenra'."Prompt 4: AI-Generated Rollback Strategy
Rollbacks are where most teams get caught out. A great migration story requires equal investment in the rollback story. Use this prompt with Claude 3.5 Sonnet for a particularly detailed output:
"Act as a Principal Database Reliability Engineer. I have an existing Flyway migration V5__add_order_tracking.sql that added three tables to our PostgreSQL database. Write the corresponding V5__add_order_tracking__rollback.sql file. Requirements: (1) Drop tables in correct dependency order to avoid foreign key violations. (2) Drop any indexes and triggers created in V5. (3) Restore any sequences that were dropped. (4) Wrap the entire rollback in a BEGIN/COMMIT transaction. (5) Add comments explaining what each section reverses and why the order matters. (6) Add RAISE NOTICE statements at key checkpoints so the DBA can monitor rollback progress in real-time."Pro Tips: Migration Best Practices
💡 Never Edit an Applied Migration
Both Flyway and Liquibase store a checksum of every migration that's been applied. If you modify an already-applied migration file, the tool will throw a checksum mismatch error on the next run — and in Flyway's strict mode, this will block all future migrations. Always create a new migration file to fix issues.
⚠️ Test Migrations on a Staging Clone First
AI-generated migrations are excellent at correctness but don't know your data distribution. A migration that runs in 50ms on a 10-row development table can take 45 minutes on a 50-million-row production table if it requires a full table scan. Always test on a production data clone before applying to live.
✅ Use Repeatable Migrations for Views & Functions
Flyway supports "repeatable" migrations (named R__view_name.sql) that re-run whenever their checksum changes. This is perfect for database views, stored procedures, and functions that you update frequently — you don't need to version every update.
Frequently Asked Questions
Q: Which is better for Spring Boot projects — Flyway or Liquibase?
A: Both integrate natively with Spring Boot via spring.flyway.* and spring.liquibase.* properties respectively. Spring Boot auto-configures whichever is on the classpath. For new Spring Boot projects, Flyway is often preferred for its simplicity — just drop SQL files in src/main/resources/db/migration and they run automatically. Liquibase is better if you need database-agnostic changesets (e.g., running the same changelog against PostgreSQL in production and H2 in tests).
Q: Can AI generate Liquibase YAML format instead of XML?
A: Yes. Liquibase 4+ supports YAML, JSON, SQL, and XML changesets interchangeably. Just specify "format: YAML" in your prompt and the AI will generate the equivalent YAML changeset structure. Many teams prefer YAML for readability and easier Git reviews.
Q: What happens if two developers commit migrations with the same version number?
A: Flyway will fail with a "Detected resolved migration not applied to database" error. The solution is to use timestamps instead of sequential integers for version numbers (e.g., V20260322123456__create_users.sql). Many teams configure their CI/CD pipeline to check for version conflicts as part of the PR validation process.
Naveen Teja Palle
Cloud & DevOps Engineer
DevOps engineer with production experience managing PostgreSQL migrations across high-traffic SaaS applications. Specializes in AWS infrastructure, CI/CD pipelines, and AI-accelerated engineering workflows.
More Cloud & DevOps Prompts
Browse 500+ AWS, CDK, and database prompts tested for real production environments.
Explore Cloud & DevOps Prompts →