Skip to content

Fix Render Deployment - Database Schema Configuration #8

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Iyedchaabane merged 2 commits into from
Feb 9, 2026
Merged

Fix Render Deployment - Database Schema Configuration #8

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ef4a64c
fix: revert ddl-auto setting to 'update' for initial deployment in ap…
Iyedchaabane Feb 9, 2026
8a961b5
chore: bump version to 1.1.1 in package.json and pom.xml
Iyedchaabane Feb 9, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion book-network-ui/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "book-network-ui",
"version": "1.1.0",
"version": "1.1.1",
"scripts": {
"ng": "ng",
"start": "ng serve",
Expand Down
2 changes: 1 addition & 1 deletion book-network/pom.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@
</parent>
<groupId>com.ichaabane</groupId>
<artifactId>book-network</artifactId>
<version>1.1.0</version>
<version>1.1.1</version>
<name>book-network-api</name>
<description>Book-Social-Network</description>
<properties>
Expand Down
2 changes: 1 addition & 1 deletion book-network/src/main/resources/application-prod.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ spring:
jpa:
database: postgresql
hibernate:
ddl-auto: validate
ddl-auto: update # Use 'update' for initial deployment, change to 'validate' after tables are created

@coderabbitai coderabbitai Bot Feb 9, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

# Locate and inspect the application-prod.yml file
find . -name "application-prod.yml" -type f | head -20

Repository: Iyedchaabane/Book-Social-Network

Length of output: 130

🌐 Web query:

Spring Boot Hibernate ddl-auto production best practices and risks of using update in production environments

💡 Result:

Production best practices (Spring Boot + Hibernate)

  • Don’t use spring.jpa.hibernate.ddl-auto=update in production. Prefer:
    • none (Hibernate performs no schema changes), or
    • validate (fails startup if schema doesn’t match mappings). (docs.spring.vmware.com)
  • Manage schema changes with versioned migrations (e.g., Flyway/Liquibase) so changes are reviewed, repeatable, testable, and tied to app versions. (stackoverflow.com)
  • Ensure environment-specific config so dev conveniences (like update/create/create-drop) can’t leak into prod. (runebook.dev)
  • Be aware of Spring Boot defaults: if it detects an embedded DB and no schema manager (Flyway/Liquibase), it may default ddl-auto to create-drop; otherwise it defaults to none. Always set it explicitly for prod. (docs.spring.vmware.com)

Key risks of ddl-auto=update in production

  • Unreliable/“best effort” diffs: update commonly adds tables/columns but often won’t handle renames, drops, or type changes correctly—leading to orphan columns, wrong column types, lingering constraints, and manual cleanup/migrations anyway. (stackoverflow.com)
  • No versioning / no controlled rollout: schema changes aren’t recorded as migrations, making rollbacks, audits, and multi-environment promotion much harder. (runebook.dev)
  • Platform/driver metadata issues: Hibernate’s SchemaUpdate relies on JDBC metadata that can be inconsistent across drivers, making behavior less predictable. (developer.jboss.org)
  • Missing important DDL (e.g., indexes): SchemaUpdate may not create indexes automatically (and is described as development-only / “no warranties”). (developer.jboss.org)
  • Concurrency/race conditions in clustered startups: multiple app instances can attempt schema changes simultaneously. (runebook.dev)
  • Operational risk acknowledged by Hibernate experts: Hibernate authors/maintainers and guidance commonly discourage automatic production updates (risk of “disaster,” DBA pushback). (stackoverflow.com)

Citations:

🌐 Web query:

Flyway Liquibase database migration alternatives to Hibernate ddl-auto

💡 Result:

Why replace hibernate ddl-auto?

Hibernate’s automatic schema generation (“HBM2DDL”) is great for testing/prototyping, but for production it’s “more flexible to manage the schema using incremental migration scripts.” [1]

Primary alternatives (versioned, repeatable, auditable migrations)

1) Flyway (SQL-first)

  • Put ordered migration scripts like V<VERSION>__<NAME>.sql under classpath:db/migration (configurable via spring.flyway.locations). Spring Boot auto-runs them on startup when flyway-core is on the classpath. [2]
  • Flyway tracks what ran in its schema history table (audit trail, checksums, success/failure). [3]

Use it when: you prefer plain SQL, tight control over vendor-specific features, and a simple migration model.

2) Liquibase (changelogs: YAML/XML/JSON/SQL)

  • Define changes as changesets in a changelog; Liquibase runs them and records execution in DATABASECHANGELOG (created automatically if missing). [4]
  • Supports deployment targeting with contexts (run certain changesets only in certain environments). [5]
  • Supports re-running modified changesets intentionally via runOnChange (checksum-based). [6]

Use it when: you want higher-level, structured change definitions, environment targeting, and richer metadata.

What to set ddl-auto to when using Flyway/Liquibase

  • In production, typically disable schema creation/update and let migrations own the schema (e.g., none), optionally using validate to detect mismatches at startup. (Spring Boot documents the ddl-auto modes like none/validate/update/create/create-drop.) [7]

Other (lighter) alternatives

  • Spring SQL init (schema.sql / data.sql) for simple initialization—but don’t combine it with Hibernate DDL generation. [7]

Sources: Hibernate ORM User Guide on schema generation vs migrations [1]; Spring Boot docs on Flyway conventions/locations and auto-running migrations [2]; Flyway schema history table docs [3]; Liquibase docs on DATABASECHANGELOG [4], contexts [5], and runOnChange [6]; Spring Boot docs on ddl-auto values and initialization constraints [7].

Citations: [1] (docs.jboss.org) [2] (docs.spring.io) [3] (documentation.red-gate.com) [4] (docs.liquibase.com) [5] (docs.liquibase.com) [6] (docs.liquibase.com) [7] (docs.spring.io)

Citations:

🏁 Script executed:

# Read the application-prod.yml file to see the actual configuration
cat -n ./book-network/src/main/resources/application-prod.yml

Repository: Iyedchaabane/Book-Social-Network

Length of output: 2724

Replace ddl-auto: update with environment-gated validation or use versioned migrations.

Production environments should never auto-apply schema changes. Spring Boot and Hibernate documentation explicitly recommend against ddl-auto=update in production due to unreliable schema diffs (renames, drops, type changes often fail), missing DDL generation (indexes), concurrency race conditions in clustered startups, and no versioning/rollback capability.

For initial deployment, use an environment variable override:

ddl-auto: ${HIBERNATE_DDL_AUTO:validate}

setting HIBERNATE_DDL_AUTO=update only during bootstrap. For ongoing deployments, migrate to a proper migration tool (Flyway or Liquibase) to ensure reviewed, versioned, repeatable, auditable schema changes.

🤖 Prompt for AI Agents 
In `@book-network/src/main/resources/application-prod.yml` at line 12, Replace the
hard-coded Hibernate property "ddl-auto: update" with an environment-gated value
and stop auto-applying schema changes in production: change the property to use
an env var like HIBERNATE_DDL_AUTO (defaulting to "validate") so you can set
HIBERNATE_DDL_AUTO=update only for one-time bootstrap, and plan to migrate
schema management to a versioned migration tool (e.g., Flyway or Liquibase) for
ongoing deployments to ensure reviewed, repeatable, and auditable schema
changes.

show-sql: false
open-in-view: false
properties:
Expand Down
Loading