Java.DBMigrationTools.How can Liquibase be integrated with Spring Boot?

Liquibase integration in Spring Boot is pretty straightforward: Boot auto-configures it and runs migrations on startup (before your app starts serving traffic), as long as Liquibase is on the classpath and you point it to a changelog.

1) Add the dependency

Maven

<dependency>
  <groupId>org.liquibase</groupId>
  <artifactId>liquibase-core</artifactId>
</dependency>

Gradle

implementation "org.liquibase:liquibase-core"

2) Create a changelog file

Typical location:

src/main/resources/db/changelog/db.changelog-master.yaml
(or .xml / .json)

Example YAML skeleton:

databaseChangeLog:
  - changeSet:
      id: 001-create-users
      author: stanley
      changes:
        - createTable:
            tableName: users
            columns:
              - column: { name: id, type: bigint, autoIncrement: true, constraints: { primaryKey: true } }
              - column: { name: email, type: varchar(255), constraints: { nullable: false, unique: true } }

3) Configure Spring Boot (application.yml)

spring:
  liquibase:
    enabled: true
    change-log: classpath:db/changelog/db.changelog-master.yaml

That’s enough for the default setup.

4) Common real-world settings

a) Different environments (contexts / labels)

spring:
  liquibase:
    contexts: dev,test

Then in changesets you can scope changes:

run only in dev/test, etc.

b) Baseline an existing DB

If you’re introducing Liquibase into an already-live schema:

spring:
  liquibase:
    enabled: true
    change-log: classpath:db/changelog/db.changelog-master.yaml
    # Often paired with generating an initial changelog or marking existing state

c) Disable Liquibase for certain runs

spring:
  liquibase:
    enabled: false

5) Multiple datasources (important in enterprise apps)

Spring Boot’s default auto-config targets the primary datasource. If you have more than one DB, define a SpringLiquibase bean for each one:

@Bean
public SpringLiquibase liquibase(@Qualifier("ordersDataSource") DataSource ds) {
    SpringLiquibase lb = new SpringLiquibase();
    lb.setDataSource(ds);
    lb.setChangeLog("classpath:db/changelog/orders-master.yaml");
    lb.setContexts("prod");
    return lb;
}

6) Ordering with JPA/Hibernate

In sane setups:

Liquibase updates schema
Then Hibernate starts using it

Avoid relying on Hibernate to create/update schema in prod:

spring:
  jpa:
    hibernate:
      ddl-auto: validate  # (or none)

So Hibernate verifies schema rather than mutating it.

7) Testing migrations automatically

Typical pattern:

Testcontainers DB
Boot app context starts
Liquibase runs
You assert schema/data expectations

Or run Liquibase directly in an integration test.

What I’d say in an interview (tight answer)

“In Spring Boot, you add liquibase-core, create a changelog under resources, and configure spring.liquibase.change-log. Boot auto-runs Liquibase on startup against the app datasource; for multiple datasources you define SpringLiquibase beans explicitly, and in production you keep Hibernate ddl-auto on validate so schema changes only come from migrations.”