One of the most powerful but sometimes underappreciated settings in Spring Boot for JPA/Hibernate is the spring.jpa.hibernate.ddl-auto (or spring.jpa.generate-ddl) configuration. This single line can define how your database schema is managed — whether it’s created, updated, validated, or left alone. Let’s unpack what each option does and when it’s appropriate to use them.
❌ none
- Behavior: No schema management is performed at all.
- Use case: You manage your own schema via SQL or migration tools.
- Ideal for: Production environments where you want full control and don’t want Hibernate making changes to the schema.
✅ validate
- Behavior: At startup, Hibernate checks that the database schema matches your entity mappings.
If there’s a mismatch, the application fails to start. - Use case: Ensures consistency between code and database.
- Ideal for: Production environments to catch mapping/schema mismatches early.
🔄 update
- Behavior: Hibernate will apply incremental changes — adding tables, columns, etc., to match your entity model. It won’t drop or remove existing columns.
- Use case: Useful in development or staging when you’re evolving the schema incrementally and want Hibernate to keep it in sync.
- Caution: In production, unexpected schema changes can occur silently, potentially causing performance or data issues.
🆕 create
- Behavior: Drops existing schema on startup, then recreates it based on your entities. All previous data is lost.
- Use case: Great for tests or development when you want a clean start.
- Not for: Production — it will wipe your data completely. health.alaska.gov
🗑️ create-drop
- Behavior: Same as
create, but additionally drops the schema when the SessionFactory orEntityManagerFactorycloses (typically at shutdown). - Use case: Perfect for automated tests or temporary demonstration environments.
- Not for: Long-running environments or anything with permanent data.
🚦 Quick Reference Table
ddl-auto Option | What It Does | When to Use |
|---|---|---|
| none | No action | Production, manual schema control |
| validate | Check only | Production, to ensure mappings match |
| update | Apply diffs | Development/Staging, small schema changes |
| create | Drop & create | Dev/Test, clean restart |
| create-drop | Drop/create + drop at shutdown | Automated tests, demos |
🧭 Best Practices & Real-World Advice
- Production: Stick with
noneorvalidate. Use tools like Flyway or Liquibase for version-controlled migrations. - Development:
createorupdatesimplify your life when experimenting with entity changes. - Testing:
create-dropensures each test runs on a fresh schema, avoiding state leaks between tests.
By clearly knowing what each option does — from “do nothing” to “wipe it all” — you can avoid accidental data loss or configuration mistakes and confidently manage your schema lifecycle.
🎯 Final Thoughts
The ddl-auto setting is simple to tweak but can drastically impact your application: helping during development, protecting data in production, and keeping tests clean. Just set the right option for the right environment — and always, always consider a proper migration strategy when moving code to production.
Feel free to let me know if you’d like a deep dive into Flyway/Liquibase integration or a real-world walkthrough of managing migrations across dev, staging, and prod!
