Hibernate hbm2ddl.auto Values Explained: validate, update, create, create-drop, and schema strategies

By the end of this page, you will understand what hibernate.hbm2ddl.auto does, what each common value means, when update is convenient, and why production systems usually use migration tools instead. You will also see how different database changes—such as adding columns, removing tables, or changing data types—should be handled safely.

hibernate.hbm2ddl.auto is a Hibernate configuration setting that controls how Hibernate interacts with your database schema when the application starts.

In simple terms, it answers this question:

Should Hibernate only check the schema, try to modify it, recreate it, or do nothing?

Common values include:

• validate
• update
• create
• create-drop
• none or leaving it unset, depending on setup

Older documentation and discussions may also mention export. In practice, developers usually talk about the actions above, while schema generation may also be handled through JPA schema-generation settings or external migration tools.

Why this matters

Your Java entity classes and your database schema must stay in sync.

For example, if your entity has:

@Column(nullable = false)
private String email;

but the database table does not have an email column, your application may fail or behave incorrectly.

Hibernate can help with this mismatch, but how much help it gives depends on the hbm2ddl.auto value.

Think of your database schema as a building, and your entity classes as the blueprint.

• validate = an inspector checks whether the building matches the blueprint
• update = a handyman tries to make small adjustments to the building
• create = the building is demolished and rebuilt from scratch
• create-drop = the building is built for a short event and torn down afterward
• migration tools = a licensed construction team follows a written renovation plan, step by step

This analogy helps explain why update is risky for serious changes.

A handyman can add a shelf or install a door, but if you need to remove load-bearing walls or change plumbing, you want a detailed plan. Database migrations work the same way.

The property is usually configured in application.properties, application.yml, persistence.xml, or Hibernate configuration.

Example in Spring Boot properties

spring.jpa.hibernate.ddl-auto=validate

Common values:

spring.jpa.hibernate.ddl-auto=none
spring.jpa.hibernate.ddl-auto=validate
spring.jpa.hibernate.ddl-auto=update
spring.jpa.hibernate.ddl-auto=create
spring.jpa.hibernate.ddl-auto=create-drop

Example in Hibernate configuration

hibernate.hbm2ddl.auto=update

Example entity

import jakarta.persistence.Column;
import jakarta.persistence.Entity;
import jakarta.persistence.Id;

@Entity
public class UserAccount {
    @Id
    private Long id;

    @Column(nullable = false)
    private String username;

    private String email;
}

If the database is missing the UserAccount table:

Consider this entity:

@Entity
public class Product {
    @Id
    private Long id;

    private String name;
}

Assume the database currently has no Product table.

What happens with update

Startup flow:

1. Hibernate reads the entity mappings.
2. Hibernate inspects the current database schema.
3. It notices that the Product table is missing.
4. It generates SQL to create the missing table.
5. The application starts.

A simplified idea of the SQL might be:

create table product (
  id bigint not null,
  name varchar(255),
  primary key (id)
);

What happens with validate

Startup flow:

1. Hibernate reads the entity mappings.
2. Hibernate inspects the current database schema.
3. It notices that the Product table is missing.

1. Local development

A developer adds a new entity field while building a feature.

private String phoneNumber;

Using update can quickly add the new column in a local database so development can continue.

2. Automated integration tests

A test suite needs a fresh schema on every run.

Use create-drop with an in-memory database like H2 so each test run starts clean.

3. Production deployment

A team needs to add a non-null column to a large customer table without breaking running systems.

They should use a migration script tool such as Flyway or Liquibase, not update.

4. Startup safety checks

A production app should fail fast if the schema is wrong.

Use validate so deployment fails early when database and entity mappings are out of sync.

5. Prototype or demo apps

A throwaway app can use create or update for speed, because preserving data is not important.

In real projects, teams rarely rely on update in production.

Common production pattern

• Hibernate setting: validate or none
• Schema changes: Flyway or Liquibase
• Deployment pipeline: migration runs before app startup

Why teams do this

Migration tools provide:

• versioned SQL scripts
• reviewable schema changes
• repeatable deployments
• rollback planning
• data transformation support
• team visibility into what changed

Common patterns in codebases

Guarding startup with validate

Developers use validate to ensure mappings still match the database.

Explicit migrations for risky changes

Examples:

• renaming columns
• splitting one column into two
• converting varchar to int
• dropping tables
• backfilling data

These changes need hand-written SQL or controlled migration scripts.

Environment-specific configuration

A common setup is:

Mistake 1: Using update in production and assuming it is safe

update is convenient, but it is not a complete migration solution.

It may handle simple additions, but it is not ideal for destructive or complex changes.

Better approach

• use Flyway or Liquibase for schema changes
• use validate in production

Mistake 2: Expecting update to remove old columns or tables

Beginners often assume Hibernate will fully synchronize the database with entities.

Broken expectation:

// Column removed from entity
// Beginner expects DB column to disappear automatically

In practice, Hibernate usually avoids dangerous destructive changes automatically.

Better approach

Write an explicit migration:

alter table users drop column old_field;

Mistake 3: Using create on a database with important data

spring.jpa.hibernate.ddl-auto=create

# Common Hibernate / Spring Boot schema options
spring.jpa.hibernate.ddl-auto=none
spring.jpa.hibernate.ddl-auto=validate
spring.jpa.hibernate.ddl-auto=update
spring.jpa.hibernate.ddl-auto=create
spring.jpa.hibernate.ddl-auto=create-drop

Quick meanings

• none: do nothing
• validate: check schema only
• update: try to add/fix simple schema differences
• create: drop and recreate schema on startup
• create-drop: create on startup, drop on shutdown

Safe defaults

• Development: update
• Testing: create-drop
• Production: validate or none

When not to use update

Avoid update for:

• dropping columns
• dropping tables
• renaming columns
• changing data types
• changing existing data values
• complex constraint changes

Better alternative

Use a migration tool:

What is hibernate.hbm2ddl.auto used for?

It controls whether Hibernate validates, updates, creates, or drops the database schema based on your entity mappings.

Is hibernate.hbm2ddl.auto=update safe in production?

Usually no. It can be acceptable for small internal apps, but most production systems should use migration tools and keep Hibernate on validate or none.

What is the difference between validate and update?

validate only checks whether the schema matches. update tries to modify the schema to match the entities.

Will update delete unused columns or tables?

Usually you should not rely on it for that. Destructive changes should be done with explicit migration scripts.

Should I use create or create-drop in production?

No. They are intended for disposable databases, tests, and temporary environments because they can destroy data.

How should I change column data types safely?

Use a migration script. Data type changes can require data conversion, validation, and rollback planning.

How do I update values already stored in a column?

• JPA entity mapping — hbm2ddl.auto works from your entity annotations and mappings.
• Flyway — a common tool for versioned SQL database migrations.
• Liquibase — another popular migration tool for controlled schema evolution.
• Database schema migration — the broader concept of changing database structure safely over time.
• DDL vs DML — useful for understanding schema changes versus data changes.
• Spring Boot JPA configuration — many projects configure Hibernate schema behavior through Spring Boot properties.
• Database constraints — adding or changing nullability, uniqueness, and foreign keys often requires careful migrations.
• Integration testing with in-memory databases — create-drop is commonly used in test environments.