DDL to JPA entity
Paste CREATE TABLE statements and get annotated JPA entity classes for Hibernate and Spring Data.
From a database schema to JPA entities
You have an existing database and need Java classes for it, or a DDL script from a DBA and a Spring Data repository to write. Typing out an entity for every table, with the right annotations, column lengths, types and relationships, is repetitive and easy to get subtly wrong, such as a Double for money or a missing nullable = false.
Paste one or more CREATE TABLE statements and choose the options: package name, Jakarta or javax, Lombok or plain getters and setters, and whether foreign keys become @ManyToOne relationships. The generator reads PostgreSQL, MySQL, Oracle and SQL Server style DDL (identity columns, composite and inline primary keys, foreign keys, defaults, quoted and schema-qualified names) and writes one class per table. Column types are mapped to the sensible Java type: NUMERIC(12,2) to BigDecimal, TIMESTAMP to LocalDateTime, TIMESTAMPTZ to OffsetDateTime, UUID to UUID, text columns to String with @Lob where it fits.
What to review
- Composite primary keys become an
@EmbeddedIdwith an embeddable record; check the field order and names. - The inverse side of relationships (
@OneToMany) is not generated, because bidirectional mappings are a design decision. - JSON columns are mapped as strings, with a note on using Hibernate's JSON support.
- Run Hibernate's schema validation (
spring.jpa.hibernate.ddl-auto=validate) against your database to confirm the mapping.
Parsing happens in your browser, so a schema stays private. The result is a starting point to edit rather than a finished domain model.
Frequently asked questions
Jakarta or javax?
Spring Boot 3, Hibernate 6 and Jakarta EE 9 or later use the jakarta.persistence package. Older Spring Boot 2 applications use javax.persistence. Pick the one that matches your dependencies.
Why are relationships LAZY?
@ManyToOne is eager by default, which loads the related row with every query and causes the N+1 select problem. The generator marks it LAZY so you opt in to loading related data deliberately.
Why not use a Java record for an entity?
JPA needs a no-argument constructor and mutable fields so Hibernate can create proxies and set values. Records are immutable, so they work for projections and embeddable ids but not for entities.
What about Optional columns and wrapper types?
Nullable columns map to wrapper types (Integer, Long, Boolean) so null is representable. Primitive types would silently turn NULL into 0 or false.