Great question—let’s break down these two properties, why they behave differently in your MariaDB production scenario, and their core origins.

Core Origins & Purpose #

• spring.jpa.hibernate.hbm2ddl.auto: This is a direct pass-through to Hibernate’s native hibernate.hbm2ddl.auto property. The hbm2ddl prefix dates back to Hibernate’s early days, when entity mappings were primarily defined in .hbm.xml files (short for "Hibernate Mapping"). Spring Data JPA doesn’t own this property—it simply forwards it straight to Hibernate’s core engine, as you noted.
• spring.jpa.hibernate.ddl.auto: This is a Spring Boot-specific wrapper added to align with modern Spring configuration conventions. It replaces the older hbm2ddl prefix (which feels outdated now that most projects use annotation-based entity mappings) while serving the same high-level goal: controlling Hibernate’s automatic schema generation behavior.

Why You’re Seeing Different Restart Behaviors #

Your observation about the constraint errors vs. full table recreation makes total sense, and it comes down to subtle differences in how these properties are handled during initialization:

• When using spring.jpa.hibernate.hbm2ddl.auto=create, Hibernate’s native logic takes over immediately on startup: it will drop all existing tables first, then recreate them from scratch. Even if your app didn’t shut down gracefully and old tables linger in MariaDB, this drop-then-create sequence ensures no conflicts—hence no constraint exceptions.
• When using spring.jpa.hibernate.ddl.auto=create, Spring Boot’s wrapper logic may alter the initialization timing or how the property is passed to Hibernate. In your case, it seems Hibernate skips the pre-create drop step (or executes it too late), so when it tries to create tables again, the old tables (and their constraints) still exist—triggering the key constraint errors you’re seeing.

A Critical Note for Your Commercial Project #

Neither property’s create mode is safe for production use (as you’ve experienced, it can wipe data or cause unexpected conflicts). For your MariaDB project, you should:

1. Set both properties to none (the production-safe default).
2. Use a dedicated database migration tool like Flyway or Liquibase to manage schema changes in a controlled, versioned way—this avoids accidental data loss and ensures consistent schema updates across environments.

内容的提问来源于stack exchange，提问作者Przemysław Gęsieniec