spring.jpa.hibernate.ddl-auto Values Explained
Fast recall
Quick revision
Core answer
validate is best when you want Hibernate to guard against entity-schema drift, none is best when Flyway or Liquibase fully owns schema management and you want zero runtime schema checks. update is never safe in production because it only adds — never drops columns, never removes tables, accumulates orphans, and races under concurrent deployments. Use create-drop in unit tests and create occasionally in CI where you want a freshly initialized schema.Whether you can list all five values and be opinionated about which are production-safe — not just say 'it depends'
Saying `update` is fine in production because 'it just adds columns'; not mentioning Flyway/Liquibase as the professional alternative
Explain why `update` races under concurrent deploys (two instances ALTER simultaneously), and recommend pairing Flyway with `ddl-auto=validate` for defense in depth
Interview-ready guide
Interview answer
Five values, one production rule
- Production must be
validateornone— neverupdate,create, orcreate-drop
`none` — disable schema management entirely
- Correct when Flyway or Liquibase owns schema changes
- Zero runtime surprises
`validate` — my preferred production setting
- Checks entities match the DB schema at startup; fails app if they don't
- Defense in depth: catches the case where someone added an entity field but forgot the migration
`update` — three concrete reasons it's dangerous
- Never drops — remove a field, column stays forever accumulating orphans
- Can't detect renames — Hibernate adds a new column alongside the old one, silently splitting data
- Race conditions during rolling deploys — two instances
ALTER TABLEconcurrently, one fails, deployment breaks
`create` and `create-drop` — tests only
createdrops and recreates on startupcreate-dropalso drops on shutdown
The professional pattern
- Flyway/Liquibase for versioned, code-reviewed migrations
ddl-auto=validateso Hibernate verifies the result- If anyone skips a migration, the app fails to start in CI — not with
column does not existin production
spring.jpa.hibernate.ddl-auto Values Explained
Direct Answer
Five values: none (do nothing), validate (check schema matches entities on startup, fail otherwise), update (ALTER schema to match entities), create (drop and recreate schema on startup), create-drop (same, plus drop on shutdown). Production must be validate or none — validate is best when you want Hibernate to guard against entity-schema drift, none is best when Flyway or Liquibase fully owns schema management and you want zero runtime schema checks. update is never safe in production because it only adds — never drops columns, never removes tables, accumulates orphans, and races under concurrent deployments. Use create-drop in unit tests and create occasionally in CI where you want a freshly initialized schema.
Common Mistakes & Pitfalls
Saying update is fine in production because 'it just adds columns'; not mentioning Flyway/Liquibase as the professional alternative
Check your understanding
Answer these without looking back at the article.
- How does Flyway's `flyway_schema_history` table prevent concurrent migrations?
- What does `ddl-auto=validate` check exactly — just column existence, or also types and constraints?
- How would you handle a zero-downtime schema migration that renames a column?
- What's the difference between `ddl-auto=create` and running Flyway's clean + migrate?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.