Database Migration

If you're persisting data in a database, the chances are pretty high that you need a way to set up new databases for new installations and to migrate existing databases when installing an update. There are several ways to do that. The JPA specification defines a few features for that, and there are specialized tools that implement a mechanism called "version-based database migration".

On this page, you can find all my articles on database migrations. But I recommend you start with the following video. It's a part of a live stream that I did on my YouTube channel, and it provides a great introduction to this topic.

Subscribe to my YouTube channel to not miss any video or live stream.

Schema generation with JPA and Hibernate

Hibernate and JPA provide a few features to generate your database schema or SQL scripts based on entity mappings. I only recommend using this approach during rapid prototyping or setting up test systems. It can also save you some time when you create the first version of your database scripts.

Here are 2 articles that describe JPA's and Hibernate's features and limitations in more details

Version-Based Database Migration

A general best practice to migrate production databases is called "version-based database migration". It follows the simple idea to apply the same versioning approach to your source code and database. For each version update, you provide a script that implements the required migration steps for that specific update. For each system, you then determine the required updates and execute the corresponding scripts.

The easiest way to perform a version-based database migration is to use a specialized tool that handles the execution of the required update steps. Liquibase and Flyway are two popular options for that, and I explained both of them in great detail here on the blog.

Liquibase

Flyway

Integrations in Spring Boot

Zero Downtime Updates

Depending on your deployment scenario, you not only need a tool to perform the update, but you also need a strategy that avoids downtimes. And that's when it gets complicated. You can't shut down your application, perform all required operations, restart the application and hope it works.

During a zero-downtime update, the old and the new version of the application are running in parallel. That requires a complex, multi-step migration process. In my article Update your Database Schema Without Downtime, I explain how such a process works.