Introduction

Spring Boot can delegate schema management to Hibernate through the spring.jpa.hibernate.ddl-auto property. That setting is convenient during development, but it is easy to misuse because each mode has very different consequences for data safety and deployment discipline.

What ddl-auto Controls

ddl-auto tells Hibernate what to do when the application starts with respect to the database schema derived from your entity mappings.

The common values are:

• 'none or leaving it unset, meaning Hibernate does not manage the schema'
• 'validate, meaning Hibernate checks that the schema matches the entities'
• 'update, meaning Hibernate tries to apply incremental schema changes'
• 'create, meaning Hibernate drops and recreates the schema at startup'
• 'create-drop, meaning Hibernate creates the schema at startup and drops it again on shutdown'

Those modes are not interchangeable. Choosing the wrong one can destroy data or hide migration problems.

Example Configuration

In application.properties, the setting looks like this:

1spring.datasource.url=jdbc:postgresql://localhost:5432/appdb
2spring.datasource.username=app
3spring.datasource.password=secret
4spring.jpa.hibernate.ddl-auto=validate
5spring.jpa.show-sql=true

The YAML version is equivalent.

1spring:
2  datasource:
3    url: jdbc:postgresql://localhost:5432/appdb
4    username: app
5    password: secret
6  jpa:
7    hibernate:
8      ddl-auto: validate

A simple entity might look like this:

1import jakarta.persistence.*;
2
3@Entity
4@Table(name = "users")
5public class User {
6    @Id
7    @GeneratedValue(strategy = GenerationType.IDENTITY)
8    private Long id;
9
10    @Column(nullable = false)
11    private String email;
12
13    protected User() {
14    }
15
16    public User(String email) {
17        this.email = email;
18    }
19}

Hibernate reads metadata such as @Table, @Column, and the identifier strategy when deciding what schema shape it expects.

Which Mode Fits Which Environment

For local prototyping, update can be convenient because it lets entity changes appear in the schema without hand-written SQL every time.

For tests, create-drop is often useful because each run starts from a clean schema and leaves no leftovers behind.

For production, validate is usually the safe default. It lets the application fail fast if the schema and entity mappings drift apart, while keeping actual schema changes under explicit migration control.

That is why many teams pair Spring Boot with Flyway or Liquibase:

• migrations make schema evolution explicit and reviewable
• 'validate confirms the deployed schema still matches the code'

This combination is much safer than trusting automatic updates in environments that hold real data.

Why update Is Convenient but Risky

update sounds appealing because it promises incremental evolution, but it is not a full migration system. It may handle some additions cleanly, yet it does not give you the same control over renames, data backfills, or complex transformations.

If a column rename is interpreted as "drop one column and add another," you can lose data or end up with a schema that no longer matches the intended rollout plan.

So the right mental model is: update is a development convenience, not a production migration strategy.

Common Pitfalls

Using create or create-drop against a database with important data is the most dangerous mistake because those modes rebuild the schema.

Relying on update in production is another common problem. It can mask schema-management gaps until a harder migration appears.

Forgetting that entity annotations influence schema validation also causes confusion. If the entity says nullable = false but the database says otherwise, validate can legitimately fail.

Finally, do not assume Hibernate-generated DDL will always match the exact operational choices you want for indexing, constraints, or naming. Explicit migrations give you more control.

Summary

• 'spring.jpa.hibernate.ddl-auto controls how Hibernate interacts with the database schema at startup'
• 'validate is usually the safest production choice when migrations are managed separately'
• 'update is useful for development but is not a substitute for real migration tooling'
• 'create and create-drop are destructive and belong only in disposable environments'
• Flyway or Liquibase plus validate is a strong default for disciplined schema management