- • Quickstart
- • Documentation
- • Documentation DevOps
- • Next Steps
- › Spring Data
- • Spring Data MongoDB
- • Spring REST
- • Frontend
- • Multi-Module
Last updated: 2022-08-28
Generating the database schema in a Spring Boot application
Did you know that you can save days or weeks of development time when starting new Spring Boot apps? br With Bootify you have the right helper at your side - get a runnable prototype in minutes and focus on your business logic instead. Best practices included.
There are several ways to create the new database schema of a Java application. Three of the most common ways - Hibernate, Liquibase and Flyway - are compared here.
Database generation options in Bootify
With the property
spring.jpa.hibernate.ddl-auto you can set how Hibernate handles automatic schema generation. The possible options are described in detail in the community documentation.
If the option is set to
validate, hibernate validates that the already existing schema is matching the Java entities. That's a useful option if the database is managed externally, but you still want to make sure that the schema is matching your expectations. According to the fail-fast principle, the application will stop during startup if the validation fails. Keep in mind that some mismatches can only be detected during runtime.
Java entity class example
ddl-auto is set to
update, Hibernate will automatically generate the schema according to the provided Java entities. That's the advantage here: no further scripts are necessary, because the Java entities already describe the database schema. For development or testing purposes this is a good option, but Hibernate doesn't recommend its usage in production - changes of the entities cannot be managed reliably by Hibernate. Instead, a schema migration tool should be used for applications going to production.
Liquibase is a tool for describing and executing schema changes. All changes are described in so-called changelogs and are executed when Spring Boot is started. The executed changelogs are stored in a separate table, so that each change is carried out only once.
Example of a Liquibase changelog
This makes Liquibase very suitable for applications with multiple environments (production, other developers, etc.). Changes to the schema (e.g. adding a table) are described by the developer in a changelog and added to the code base. This way the change is automatically executed everywhere.
In the default configuration provided by Bootify, all files in
resources/changelogs will be executed. It's recommended to use the current timestamp as a file name, so these files are executed in the right order. The
ddl-auto option of Hibernate could be set to
validate in this case to check for mismatches.
Flyway is the tool recommended by Spring Boot itself and works on a similar principle. You can add SQL scripts to the source code, which are executed automatically once at application startup. The scripts run directly against the database, i.e. they are written in the respective dialect (e.g.
Example MySQL script for a Flyway migration
This allows developers to work directly with database-specific functions. One-time scripts for schema development should start with
V_, whereas scripts with
R_ are executed at each application start. In this way, for example, a stored procedure can always be updated to the latest version.
All migration scripts generated by Bootify for you custom database schema are contained in
Database initialization with Spring Boot
Hibernate best practices on schema generation