Spring Boot ddl-auto=create-drop: Why It Destroys Your Production Data

I've seen it happen more times than I care to count. A junior developer copies application.properties from a tutorial, fires up Spring Boot 3.2 in production, and within seconds, months of customer data vanish. The culprit? A single line: spring.jpa.hibernate.ddl-auto=create-drop. This setting, intended for rapid prototyping and testing, tells Hibernate to drop all tables when the application stops. In production, that means every deployment, every rollback, every unexpected shutdown becomes a data apocalypse. Spring Boot's auto-configuration (since version 1.0) makes schema generation dangerously easy. Combined with the 'create-drop' value, it's a recipe for disaster. The default behavior in Spring Boot is actually 'create-drop' for embedded databases (like H2) and 'none' for others, but many developers override this without understanding the consequences. I've debugged incidents where a payment processing system lost transaction records because a CI/CD pipeline triggered a graceful shutdown, and Hibernate obediently dropped every table. The fix? Never use 'create-drop' in production. Use Flyway (6.x+) or Liquibase (4.x+) for schema management. This article will walk you through the exact mechanism, real-world incidents, and how to protect your data.

How ddl-auto Works Under the Hood

When Spring Boot starts, it initializes the Hibernate SessionFactory. If spring.jpa.hibernate.ddl-auto is set (e.g., 'create-drop'), Hibernate's SchemaExport class executes DDL statements. For 'create-drop', it generates DROP TABLE statements for all entities on shutdown via a JPA shutdown hook. On startup, it runs CREATE TABLE statements. In Spring Boot 2.7+, the behavior is controlled by Hibernate's 'hibernate.hbm2ddl.auto' property. The 'create-drop' value is particularly dangerous because the drop happens in the Hibernate SessionFactory's close() method, which is called during ApplicationContext.close(). This can be triggered by: a graceful shutdown (POST /actuator/shutdown), a failed health check that restarts the context, or even a misconfigured CI/CD pipeline that sends SIGTERM. Let's see a minimal example that demonstrates this behavior.

@SpringBootApplication
public class DemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

// application.properties
spring.datasource.url=jdbc:postgresql://localhost:5432/mydb
spring.datasource.username=user
spring.datasource.password=pass
spring.jpa.hibernate.ddl-auto=create-drop
spring.jpa.show-sql=true

// Entity
@Entity
@Table(name = "orders")
public class Order {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private BigDecimal amount;
}

// On startup, Hibernate logs:
// Hibernate: drop table if exists orders cascade
// Hibernate: create table orders (id bigserial not null, amount numeric(19,2), primary key (id))

What the Official Docs Won't Tell You

The official Spring Boot documentation (up to version 3.2) states that 'create-drop' is useful for testing, but it doesn't emphasize the production risks. It doesn't mention that the 'drop' happens on ApplicationContext.close(), which can be triggered by many things beyond a simple stop. For example, Spring Boot Actuator's restart endpoint (POST /actuator/restart) calls close() then createApplicationContext(). If ddl-auto=create-drop is set, your data is gone. Also, the docs don't cover that Hibernate's SchemaExport does not use transactions for DROP statements in some dialects (like PostgreSQL 14+), meaning the drop is immediate and cannot be rolled back. Another hidden detail: if you use Spring Cloud Config and refresh the context (POST /actuator/refresh), the old context closes and a new one starts. That's two drops in quick succession. The official docs also fail to mention that the default value for embedded databases (H2, HSQL) is 'create-drop', so if you switch from H2 to PostgreSQL without changing the property, you'll get the same behavior. Let's see a code snippet that shows how to detect this in a startup check.

@Component
public class DdlAutoValidator implements ApplicationRunner {
    @Value("${spring.jpa.hibernate.ddl-auto:none}")
    private String ddlAuto;

    @Override
    public void run(ApplicationArguments args) {
        if ("create-drop".equals(ddlAuto) || "create".equals(ddlAuto)) {
            String env = System.getProperty("spring.profiles.active", "default");
            if (!"dev".equals(env) && !"test".equals(env)) {
                throw new IllegalStateException(
                    "FATAL: ddl-auto=" + ddlAuto + " is not allowed in profile: " + env
                );
            }
        }
    }
}

Spring Profiles to the Rescue

The safest way to manage ddl-auto across environments is using Spring Profiles. Create separate application properties files for each environment. For development, you might use 'create-drop' for quick testing. For staging and production, use 'validate' or 'none'. Spring Boot loads application-{profile}.properties after the main application.properties, so you can override the setting. However, a common mistake is forgetting to set the active profile, which defaults to 'default'. If you only set ddl-auto in application-dev.properties and not in application.properties, running without a profile will use the default (which might be 'create-drop' for embedded databases). Always set a safe default in application.properties. Here's how to configure it properly.

# Base configuration - safe defaults
spring.jpa.hibernate.ddl-auto=validate
spring.jpa.show-sql=false

# application-dev.properties
spring.jpa.hibernate.ddl-auto=create-drop
spring.jpa.show-sql=true
spring.datasource.url=jdbc:h2:mem:testdb

# application-prod.properties
spring.jpa.hibernate.ddl-auto=none
spring.datasource.url=jdbc:postgresql://prod-db:5432/mydb
spring.datasource.username=${DB_USER}
spring.datasource.password=${DB_PASS}

# application-staging.properties
spring.jpa.hibernate.ddl-auto=validate
spring.datasource.url=jdbc:postgresql://staging-db:5432/mydb

Migration to Flyway: The Production-Grade Solution

Instead of relying on Hibernate's schema generation, use Flyway or Liquibase for database migrations. Flyway (version 9.x+) integrates seamlessly with Spring Boot. You set ddl-auto to 'none' or 'validate' and let Flyway manage schema changes. This gives you versioned, repeatable migrations that can be rolled back. The key advantage: no data loss on restart. Flyway only applies new migrations, never drops tables unless you explicitly write a migration for it. Spring Boot auto-configures Flyway if it finds the dependency on the classpath. Here's how to set it up.

<dependency>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-core</artifactId>
    <version>9.22.3</version>
</dependency>

// application.properties
spring.jpa.hibernate.ddl-auto=validate
spring.flyway.enabled=true
spring.flyway.locations=classpath:db/migration

// src/main/resources/db/migration/V1__create_orders_table.sql
CREATE TABLE orders (
    id BIGSERIAL PRIMARY KEY,
    amount DECIMAL(19,2) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

// V2__add_customer_id.sql
ALTER TABLE orders ADD COLUMN customer_id BIGINT NOT NULL;

// On startup, Flyway applies pending migrations:
// Flyway: Successfully applied 2 migrations to schema "public" (execution time 00:00.023s)

Testing with create-drop Safely

There are valid use cases for create-drop: integration tests, local development, and CI/CD pipelines that build from scratch. The key is to isolate this setting to test scopes. Use @TestPropertySource or @DataJpaTest with auto-configured test databases. Spring Boot's @DataJpaTest automatically uses an embedded database with ddl-auto=create-drop by default, which is safe because the database is in-memory and temporary. For integration tests that use a real database, you can override the property in the test class. Never let this leak to production. Here's a pattern for safe testing.

@SpringBootTest
@TestPropertySource(properties = {
    "spring.jpa.hibernate.ddl-auto=create-drop",
    "spring.datasource.url=jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1"
})
@ActiveProfiles("test")
class OrderRepositoryTest {
    @Autowired
    private OrderRepository orderRepository;

    @Test
    void shouldSaveOrder() {
        Order order = new Order();
        order.setAmount(new BigDecimal("99.99"));
        Order saved = orderRepository.save(order);
        assertThat(saved.getId()).isNotNull();
    }
}

// application-test.properties
spring.jpa.hibernate.ddl-auto=create-drop
spring.datasource.url=jdbc:h2:mem:testdb
spring.flyway.enabled=false

The Hibernate 6.x Changes You Need to Know

Hibernate 6.x (shipped with Spring Boot 3.x) introduced changes to schema generation. The 'hibernate.hbm2ddl.auto' property now has a new value: 'drop-and-create' which is an alias for 'create-drop'. More importantly, Hibernate 6.3+ changed the default for non-embedded databases to 'none'. However, the 'create-drop' behavior is still present and just as dangerous. Additionally, Hibernate 6.x uses a new SchemaManager API that can execute DDL in batches. The drop behavior is now more aggressive: it uses CASCADE to drop tables with foreign key constraints, which can silently remove related tables. Also, Hibernate 6.x introduced 'hibernate.schema_management.drop_strategy' which can be configured, but the default is still to drop all tables. Let's see how to inspect the actual Hibernate configuration.

@Component
public class HibernateConfigInspector implements ApplicationListener<ApplicationStartedEvent> {
    @Autowired
    private EntityManagerFactory emf;

    @Override
    public void onApplicationEvent(ApplicationStartedEvent event) {
        SessionFactory sf = emf.unwrap(SessionFactory.class);
        Properties props = sf.getProperties();
        String hbm2ddl = props.getProperty("hibernate.hbm2ddl.auto");
        String dialect = props.getProperty("hibernate.dialect");
        System.out.println("Hibernate ddl-auto: " + hbm2ddl);
        System.out.println("Dialect: " + dialect);
        if ("create-drop".equals(hbm2ddl) || "create".equals(hbm2ddl)) {
            System.err.println("WARNING: ddl-auto is set to " + hbm2ddl + "! This is dangerous in production.");
        }
    }
}

Advanced: Custom SchemaExport for Controlled Drops

If you absolutely must use Hibernate's schema generation in production (which I don't recommend), you can customize the SchemaExport behavior. Hibernate 6.x allows you to implement a custom SchemaExportDelegate that can intercept DROP statements. You could, for example, log the DROP statements instead of executing them, or require an explicit flag to allow drops. This is an advanced technique for teams that have legacy systems tied to Hibernate's schema generation. However, it's a band-aid. The real solution is Flyway. Here's how to implement a custom schema exporter that prevents drops.

public class SafeSchemaExport extends SchemaExport {
    private final boolean allowDrop;

    public SafeSchemaExport(Metadata metadata, boolean allowDrop) {
        super(metadata);
        this.allowDrop = allowDrop;
    }

    @Override
    public void drop(EnumSet<TargetType> targetTypes, ExecutionOptions options) {
        if (!allowDrop) {
            System.err.println("DROP operation blocked by SafeSchemaExport. Set allowDrop=true to enable.");
            return;
        }
        super.drop(targetTypes, options);
    }
}

// Register via Spring Boot's HibernatePropertiesCustomizer
@Component
public class SafeSchemaExportCustomizer implements HibernatePropertiesCustomizer {
    @Override
    public void customize(Map<String, Object> hibernateProperties) {
        hibernateProperties.put("hibernate.schema_management.tool", SafeSchemaExport.class.getName());
        hibernateProperties.put("hibernate.schema_management.allow_drop", false);
    }
}

Production Checklist: Protecting Your Data

Here's a battle-tested checklist for preventing ddl-auto disasters. First, never set ddl-auto to 'create-drop' or 'create' in any file under src/main/resources. Second, add a startup guard (like the one in Section 2) that crashes the application if these values are used in non-dev profiles. Third, use environment variables for the active profile, not hardcoded values. Fourth, implement a CI/CD pipeline check that scans for forbidden property values. Fifth, use Flyway or Liquibase for all schema changes. Sixth, enable Spring Boot's 'spring.jpa.hibernate.ddl-auto=validate' to catch entity-schema mismatches early. Seventh, monitor your database for unexpected DROP statements using database audit logs. Eighth, have a backup strategy that includes point-in-time recovery. Let's see a complete configuration for production.

# Production-safe configuration
spring.jpa.hibernate.ddl-auto=validate
spring.jpa.show-sql=false
spring.jpa.properties.hibernate.format_sql=false

# Flyway configuration
spring.flyway.enabled=true
spring.flyway.locations=classpath:db/migration
spring.flyway.baseline-on-migrate=true

# Database connection
spring.datasource.url=jdbc:postgresql://${DB_HOST}:${DB_PORT}/${DB_NAME}
spring.datasource.username=${DB_USER}
spring.datasource.password=${DB_PASS}
spring.datasource.hikari.maximum-pool-size=10

# Actuator security (prevent accidental restarts)
management.endpoint.restart.enabled=false
management.endpoint.shutdown.enabled=false