Schema Migration Tools Compared

Key takeaways

• DbSchema compares an offline model against a live database and generates the migration DDL from the difference, so nobody hand-writes the ALTER statements.
• DbSchema Pro is a one-time perpetual licence from €254.39, including the first year of upgrades; Community Edition is free with no time limit.
• Liquibase Starter covers up to 5 applications and 1 database type, and all its commercial tiers are quote-only.
• Redgate discontinued the Flyway Teams tier for new customers in May 2025, leaving Community and Enterprise.
• Schema migration changes structure; data migration moves records. They are different problems with different tools.

Which tool is best for data migration?

Pick by how your team works. DbSchema is the strongest fit when you want to design the schema visually, diff the model against a live database and have the migration script generated for you. Liquibase suits database-agnostic changelogs applied from a CLI across heterogeneous engines[1]. Flyway suits teams who would rather write plain SQL files and have them applied in version order[2].

Software engineering teams frequently encounter term confusion between data migration and database schema migration. Data migration moves data from one system to another, whether between old and new databases, different formats, or different storage environments. Database schema migration, by contrast, changes a database's structure, and the underlying data does not necessarily move. Selecting the right tool requires evaluating whether your primary bottleneck involves bulk data streaming or structural schema evolution.

Key Evaluation Criteria for Database Tools

• DevOps CI/CD Integration: Automated pipeline execution via CLI or build plugins.
• Visual Modeling Capabilities: Interactive ER diagrams for inspecting table relationships.
• Offline Model Isolation: Local file-based schema editing prior to database deployment.
• Schema Differentiation: Automated comparison between design files and live target databases.

Evaluating these operational criteria alongside database design tools ensures that engineering teams select a framework aligned with their infrastructure requirements and developer workflows.

Is Liquibase a database migration tool?

Liquibase is a database schema change and version control tool: teams list every change to a database sequentially in a text-based changelog that can be stored and versioned in any source control tool[3]. Schema migration itself sits at the centre of the software development life cycle, bridging the gap between data integrity and software innovation[4]. In practice, Liquibase captures schema modifications inside changelog files written in SQL, XML, YAML, or JSON[1], then applies them with the update command from the CLI.

Liquibase covers 65+ databases across relational, NoSQL and graph engines, which is what lets one pipeline configuration govern a mixed estate[5]. The platform tracks executed updates using a dedicated database tracking table (DATABASECHANGELOG), which records change set identifiers, execution timestamps, and checksums to prevent accidental duplicate executions or unauthorized file modifications.

Liquibase Core Features and Licensing Model

Liquibase pairs a free Community edition with four paid tiers, Starter, Growth, Business, and Enterprise, scaled by the number of applications and database types a team needs to govern[6].

• Liquibase Community: Free edition released under the Functional Source License (FSL) adopted in Liquibase 5.0, supporting core changelog execution[7].
• Starter Tier: Supports up to 5 applications and 1 database type, with standard business-hours support[6].
• Growth Tier: Supports up to 10 applications and up to 3 database types for teams standardizing change across multiple apps[6].
• Business Tier: Supports up to 25 mission-critical applications and up to 4 database types, with audit-ready change tracking and premium support[6].
• Enterprise Tier: Unlimited applications and databases with advanced security, custom compliance coverage, and 24/7 support[6].

What are the three data migration tools available?

The three tools split along one line: where the change is authored. DbSchema starts from a visual model, compares it against the live database and generates the DDL from the difference. Liquibase and Flyway start from a file you write yourself and push it through a pipeline, Liquibase via database-agnostic changelogs in SQL, XML, YAML or JSON[1], Flyway via SQL migration files applied in version order[2].

Licensing has shifted underneath this category. Redgate discontinued the Flyway Teams tier for new customers in May 2025, leaving Community and Enterprise[7], and drift detection via check -drift is documented as an Enterprise feature[8]. DbSchema ships visual design and synchronization for every supported SQL and NoSQL engine with no cloud dependency.

Evaluating these tools based on engine compatibility, deployment mode, and license cost ensures long-term alignment with backend software engineering standards.

What is the best tool for data migration?

Determining the best tool requires matching tool architecture to team workflow priorities. Flyway's model is deliberately simple: developers write SQL migration files, and Flyway scans the filesystem or classpath and applies the pending ones in order based on their version number, recording each in a schema history table[2]. This approach appeals to developers who prefer writing raw SQL files directly inside their code repositories.

DbSchema takes the other route. You design tables, edit data types and draw foreign keys in an offline model file (.dbs) with no live connection open. When the change is ready you connect, DbSchema introspects the remote schema, and you review the differences visually before any script is generated.

Where DbSchema fits, and where it does not

DbSchema Pro is a one-time perpetual licence (€254.39, about $294) or a monthly subscription, with the first year of upgrades and support included either way.

• Visual ER diagram editing and relational data exploration across 100+ engines.
• Schema synchronization that compares the local model against a live database and generates the exact DDL.
• Model files stay local and commit straight into Git, with no cloud dependency.
• Not a headless CLI orchestrator. In a fully code-first pipeline where nobody opens a diagram, Liquibase and Flyway are the better fit, and Liquibase's changelog format and Flyway's version-ordered SQL files are both stronger at unattended execution.

How to generate a migration file?

Generating a migration file involves capturing structural schema differences and converting them into executable DDL statements. In code-first workflows, developers author the change themselves, writing versioned SQL migration files for Flyway[10] or changelog entries for Liquibase[3] before running the CLI. However, manual script creation introduces risks of syntax errors, missed constraints, or unhandled foreign key dependencies.

DbSchema replaces the drafting step with a comparison. You change the offline model, then connect to the target database; DbSchema reads its current structure over JDBC and diffs it against the model, identifying missing tables, altered columns, changed data types and index differences.

Step-by-Step Migration File Generation Workflow

1. Open the .dbs model file and make the schema change visually on the ER diagram.
2. Connect over JDBC to the target development, staging or production database.
3. Run Schema > Synchronize to compare the model against the live structure.
4. Review the diff per object, choosing which changes to commit, merge or ignore.
5. Generate the SQL migration script, read the DDL, and commit the file to Git alongside the model.

Every incremental change ends up as a reviewable, version-controlled artifact rather than an opaque snapshot. DbSchema can export database documentation from the same model, so the docs move with the migration.

What is a migration script?

A migration script is an ordered set of SQL DDL commands or structured configuration definitions that alters a database schema from one version state to another. Migration scripts serve as version-controlled code artifacts, allowing engineering teams to apply structural updates deterministically across all environment instances[4].

Every database schema consists of structured architectural components that define how data is stored, categorized, and protected[4]. A comprehensive migration script precisely targets and modifies these foundational elements during schema evolution.

The Four Core Components Modified by Migration Scripts

• Tables: Structures that store records defined by specific attributes and storage parameters[4].
• Columns: Attribute definitions that establish field names, data types, nullability rules, and default values[4].
• Relationships: Inter-table connections established through foreign keys that enforce relational mapping and referential integrity[4].
• Constraints: Rules enforced on tables and columns, including primary keys, unique indexes, check constraints, and default constraints[4].

By explicitly managing these four components through incremental migration scripts, engineering teams replace risky, state-based database snapshots with traceable, version-controlled database releases[4].

How to run a migration script?

Executing a migration script requires a structured environment progression strategy to safeguard data integrity and preserve database performance across the entire software development lifecycle[4]. Running migration scripts without verification risks locking critical production tables, breaking existing application queries, or corrupting stored data.

A resilient database migration strategy mandates promoting schema changes sequentially across isolated environments. Developers first apply and validate migration scripts within local development databases, proceed to staging and test environments for automated integration tests, and finally execute the verified scripts against production targets during scheduled deployment windows.

Best Practices for Safe Migration Script Execution

1. Commit all design models and generated migration scripts into a shared Git repository to maintain a historical change record.
2. Verify complete target database backups prior to running DDL execution scripts in staging or production environments[4].
3. Test migration execution against realistic data volumes in staging to measure execution time and lock impact.
4. Execute the migration script against the target database, reviewing step-by-step execution logs for errors or warnings.
5. Validate post-migration database structure and application connectivity before concluding the deployment window.

We build offline-first database tooling because we think the developer should control every stage of schema evolution. Download DbSchema, reverse-engineer your own database into a model, change one table, and read the migration script it generates before anything touches the server.

FAQ

What is the difference between data migration and schema migration?

Data migration moves records between systems, whereas database schema migration changes the structural framework (such as tables and columns) without necessarily moving the underlying data.

What databases does Flyway support?

Redgate lists foundational support across a published set of engines, covering info, migrate, repair, validate and baseline, with advanced capabilities such as drift detection limited to the Enterprise tier.

What are the components of a database schema?

The 4 key components of a database schema include tables, columns, relationships, and constraints. These structures govern how data is organized and maintain relational integrity.

How much does Liquibase Starter cost?

Liquibase requires a custom quote for its commercial tiers. Starter is available to companies under $1B in annual revenue and supports up to 5 applications and 1 database type.

What happened to the Flyway Teams edition?

Redgate discontinued the Flyway Teams tier for new customers in May 2025, leaving a choice between the free Community edition and the fully featured Enterprise tier.

Can I generate database migration scripts without writing SQL?

Yes. DbSchema compares an offline model against the live database and generates the DDL for the difference, which you review before running it.

Sources

1. liquibase.com
2. documentation.red-gate.com
3. docs.liquibase.com
4. liquibase.com
5. docs.liquibase.com
6. liquibase.com
7. bytebase.com
8. documentation.red-gate.com
9. red-gate.com
10. documentation.red-gate.com