Key Features

What does it do?

Morf provides:

1. A reliable way to migrate/upgrade a database schema in conjunction with changes to an application.
2. That upgrade functionality in a consistent way across multiple database platforms.
3. An general SQL abstraction layer that allows applications to be written independent of the database.
4. Tooling to support testing your application, in particular its interactions with the database.

In order to achieve this, Morf is opinionated about how construct your database schema: It doesn't allow the use of all column types, for example; it only allows those that are supported across multiple platforms. It also doesn't allow the use of stored procedures, since these are not portable.

Differences from other migration tools

Morf has been built to support Alfa Systems - a large enterprise application which is deployed onto multiple database platforms and developed by hundreds of engineers in parallel. To support this, it features a number of features which are not shared by other tools.

Compared to two commonly available alternatives, Liquibase and FlyWay, some key differences are:

1. While they both support many different database platforms, both Liquibase and FlyWay are primarily aimed at applications that deploy to a single database type. They tend to encounter difficulties if the same application must be deployed on many different database platforms. Liquibase has a set of Changes which provides some degree of abstraction, but it is impossible to execute complex SQL via this model. Morf allows engineers to define an upgrade step once and be confident it will work on all platforms.
2. Morf features forward and reverse schema verification of upgrade steps, preventing them from being run at all if the upgrade step does not achieve a known-good target schema. This makes it safer to use in large development projects with many developers and many database instances, where a broken upgrade step can cause chaos.
3. It also allows engineers to write a test for an upgrade step, providing xml-format "start positions" and "end positions" that can be executed in JUnit.
4. This same test capability can be used to initialise database start positions for integration tests, automatically upgrading the start position on the fly.
5. Morf uses an "all Java" API - no XML, YAML etc, just compiled code.

When to use Morf

• You are writing a new application, are happy to work within Morf's limitations and like the way it works.
• You have an application which you want to be able to run over multiple database platforms.
• You have a large product and team and can't risk "bad" upgrades propagating.
• You need complex upgrade steps, requiring custom SQL.
• You want to be able to test your upgrades.

When not to use Morf

Because it is opinionated, you may find Morf limits you in some situations. Consider carefully whether Morf suits your requirements if any of the following apply to you:

• You have a specific, tuned existing schema (it's unlikely that Morf supports all the column types and features you use, although more can, of course, be added, and if you want to contribute those changes we would be extremely grateful).
• You only ever deploy (and only ever intend to deploy) to one database platform. Other tools may give you more options.
• You need stored procedures, triggers and other advanced features (Morf does not support them)