Migrations

Liquibase, Flyway or a Visual Schema Compare

For the backend developer who deploys schema changes from a pipeline and is deciding whether the next one ships as a numbered SQL file, a changelog entry, or a generated script.

by Dora Pruteanu · 12-Aug-2026 · Updated 06-Sep-2026

On this page

A change has to reach staging and production this week, and the open question is what you commit for it. DbSchema gives you the third answer and the one to pick: you edit the table on the diagram, DbSchema compares the .dbs model file against the target database, and it writes the migration script from what differs. Liquibase and Flyway take the other two routes, a changelog entry and a numbered SQL file, and both are worth understanding before you choose.

Is Flyway still used?

Flyway is Redgate's migration runner and is still documented and released as one. Its model is a directory of SQL files whose names carry the ordering. A versioned migration has a version, a description and a checksum, and Flyway applies it to a target database in order and exactly once[1].

The first letter of the filename decides how Flyway treats the file.

Prefix	Example filename	When Flyway runs it
V	V001.002__NewTwitterColumn.sql	Once, in version order
U	U001.002__UndoNewTwitterColumn.sql	On the undo command, Teams edition
R	R__SetDefaults.sql	Whenever its checksum changes

Repeatable migrations are the ones without a version. Flyway re-applies them on migrate every time their checksum changes, runs them last in a migration run, and orders them alphabetically by description[2], which is why views and stored procedures usually live there.

The bookkeeping sits in the database itself. The flyway_schema_history table is the audit trail of every change applied to the schema: which migrations ran, when, who ran them, their checksums, and whether they succeeded[3]. Edit a file that has already been applied and its checksum no longer matches the recorded one. Flyway stops the run with an error. Before deployment continues, the repair command has to reset the history[3]. Every versioned migration also needs a unique version[1], and that number is picked by hand, on whichever branch the file is written.

What is the purpose of Liquibase?

Liquibase keeps the same history in a text ledger you write yourself. The changelog sequentially lists all changes made to the database, and Liquibase reads it to work out which ones are still undeployed[4]. You can write it in SQL, XML, YAML or JSON; the XML, YAML and JSON forms use Liquibase change types instead of engine-specific DDL, so the same file targets more than one engine[4].

A single change is a changeset. Its id and author tags, together with the search path location and the name of the changelog file, form the unique identifier Liquibase records, and changesets execute in the order they appear in the changelog file[4].

A changelog can also decide for itself whether a change applies. Preconditions are tags you add to a changelog or to individual changesets to control the execution of an update based on the state of the database, and their onFail attribute takes WARN, HALT, CONTINUE or MARK_RAN[5]. Liquibase states that it works with 60+ databases, including relational, NoSQL and graph databases[6].

The Liquibase and Flyway approach

Both tools treat the schema as a sequence of changes that a runner replays, and both record what they replayed in tables they create inside the target database. Flyway keeps the single schema history table described above. Liquibase creates DATABASECHANGELOG automatically if the table does not exist and identifies each row by the combination of id, author and filename rather than by a primary key[7]. A second table, DATABASECHANGELOGLOCK, keeps a LOCKED column set to 1 while an update runs, so only one Liquibase instance works against the database at a time and any other waits five minutes by default before giving up[8].

What both approaches have in common is the file in the middle. Whichever format you pick, a column you added on a diagram or in a local database has to be re-expressed by hand as a migration file before it deploys anywhere.

Is Flyway better than Liquibase?

The two differ most where you would look first under pressure, which is undoing a change. Liquibase has a rollback command that rolls back sequentially all the deployed changes until it reaches the tag row in DATABASECHANGELOG, and it ships companion commands that roll back a given number of changesets or everything after a date[9]. Flyway's equivalent is a file you write: an undo migration is the U script carrying the same version as the versioned migration it reverses, and its documentation marks it as a Teams edition feature[10]. The step-by-step version of that decision is in rolling back a database schema change.

Detecting a change nobody deployed through the pipeline is the second split. Flyway's check -drift command checks a target environment for drift so that it is still in the expected state for running deployments, and the deployment can be aborted when drift appears; the documentation marks the command as Flyway Enterprise[11].

Neither answer changes the shape of the work: you keep writing and ordering files, and the drift you are checking for is drift against those files. DbSchema starts from the schema instead. It reads the live database over JDBC, compares it against the .dbs design model, and lists the differences object by object, so drift is what you see rather than something a separate command reports.

Is Liquibase free to use?

Liquibase Community is released and licensed under the FSL, and Liquibase Secure is released under a commercial EULA and runs only when a license key is provided[12]. The line between them runs through the object types you can capture: generate-changelog builds a changelog from an existing database, and check constraints, functions, stored procedures, triggers, packages and composite types require Liquibase Secure[13]. Flyway draws its line in the same place, around undo migrations and drift checking.

Tool	Free edition covers	The paid edition adds
DbSchema	Diagrams, reverse-engineering, SQL editor	Pro: model file, schema synchronization
Liquibase	Community, under the FSL	Secure: triggers, functions, procedures in generate-changelog
Flyway	Community	Teams: undo migrations. Enterprise: check -drift

DbSchema Community is free for any use and covers all databases, reverse-engineering, interactive diagrams, creating tables and columns, and the SQL editor. Saving the design to a .dbs file, the documentation exports and schema synchronization are Pro. Pro is one payment plus taxes, with the first year of upgrades included and an optional renewal a year later, and the licence is per developer rather than per application or per engine. The pricing page carries the figure, in your own currency and on separate tabs for Business, Personal and Universities & Students.

What is the alternative to Liquibase?

The alternative is to commit the schema rather than the steps that produce it. DbSchema keeps the whole design in a .dbs project file: tables, columns, indexes, foreign keys, diagram layout and comments, in plain XML. The file holds structure and no rows, so it goes into the application repository next to the code that queries it, and a pull request shows the added column as added lines.

Editing the diagram writes to that file and to nothing else. In offline mode, DbSchema sends no statements to the database at all, so a design can move well ahead of production before anything runs[14]. Inside DbSchema, Model → Git — Collaborative Design opens the Git dialog, where you stage the changed file, commit it with a message, and push it to the remote the rest of the team pulls from.

The live database changes at one point, and you can see the statement before it does. Open Schema → Synchronize Model with Database, choose the target schema, and the Sync Dialog generates the SQL that brings the database in line with the model; you can edit those statements in place and then click Execute[15]. Nothing reaches the database until that click.

The situation a visual schema compare solves

A staging database that took a hotfix by hand no longer matches what the repository says it should be, and the next deployment is usually the moment you find out. Take a single change: one column and the index that supports the lookup.

ALTER TABLE users ADD COLUMN last_login timestamp;
CREATE INDEX idx_users_last_login ON users (last_login);

You add last_login to the users table on the DbSchema diagram and save the model, which so far has changed the .dbs file only. Then you connect to staging and run the synchronization: DbSchema reads the live catalog, lists the column and the index as present in the model and missing in the database, and shows the statements that close the gap. A table nobody touched produces no statements, so the script stays as small as the change.

The same window works in the other direction. Where the hotfix is the change you want to keep, you apply the difference to the model instead, and the .dbs file is what gets updated. A replayed changelog has no equivalent of that choice, because it knows only the changes somebody wrote down.

The fastest way to judge the three is to point DbSchema at the database your pipeline already deploys to and let it reverse-engineer the schema into a diagram and a .dbs model file. Download it at https://dbschema.com/download.html. Reverse-engineering, the diagrams and the SQL editor are in the free Community Edition; saving the model to a file and schema synchronization are Pro, and the download runs as a 15-day Pro trial, which is long enough to generate the first migration script.

FAQ

What is the difference between Flyway and Liquibase?

Flyway orders work by filename, applying pending versioned migrations in version order. Liquibase orders work by position: changesets run in the order they appear in the changelog file, and each is identified by its id, its author and the changelog filename rather than by a number.

Are Liquibase and Flyway free to use?

Both ship a free edition, and each draws its line at a different feature. The editions table above shows where that line falls for Liquibase, for Flyway and for DbSchema.

How does Liquibase rollback a change?

The rollback command reverts deployed changes one at a time until it reaches the tag row you name in DATABASECHANGELOG. Liquibase also ships rollback-sql, which prints the statements it would run instead of running them, so you can read the rollback before it touches the database.

What is a visual schema compare?

In DbSchema you open Schema → Compare Model with Database, and the diff view lists the added, removed and modified tables, columns, indexes and foreign keys[15]. Each difference carries three choices: update the model, push the change to the database, or skip it.

Does a visual schema compare generate migration scripts?

DbSchema writes the statements in the dialect of the connected engine. The same synchronization also runs without the desktop screens, scripted with Groovy automation scripts or the DbSchemaCLI, so a CI job can generate the script the same way[15].

How do you version a database schema without Flyway?

The schema history becomes the commit history of the .dbs file that holds the design. One repository can carry several of those files, one per database or project component, and DbSchema clones the repository into an empty local folder from its Git dialog.