How does JPA's @Enumerated annotation store a Java enum in the database, what is its default, and what is the practical difference between EnumType.ORDINAL and EnumType.STRING?

## What @Enumerated does A Java enum has two natural string/number representations: `name()` (the constant's identifier, e.g. `SHIPPED`) and `ordinal()` (its zero-based position in the declaration, e.g. `2`). JPA's `@Enumerated` picks which one is written to the column. ```java public enum OrderStatus { NEW, PAID, SHIPPED } // ordinals 0, 1, 2 @Entity class Order { @Enumerated(EnumType.STRING) private OrderStatus status; // stores 'NEW' / 'PAID' / 'SHIPPED' } ``` Omitting `@Enumerated` entirely, or writing `@Enumerated(EnumType.ORDINAL)`, stores the integer. **ORDINAL is the specification default**, which is the root of most of the pain — the risky option is the one you get by doing nothing. ## Why ORDINAL is fragile Ordinals are positional, and positions are a property of the *source file*, not of the data. Suppose production holds thousands of rows written with the enum above, and a developer adds a status: ```java public enum OrderStatus { NEW, PENDING_PAYMENT, PAID, SHIPPED } // 0,1,2,3 ``` Every row that stored `1` meant `PAID`; it now reads as `PENDING_PAYMENT`. Every `2` was `SHIPPED` and now reads as `PAID`. Nothing throws. Nothing logs. Reports, state machines and business rules quietly operate on wrong values, and the damage is discovered days later. The same happens on any reorder, including a well-meaning alphabetical sort or an IDE refactor. Deleting a constant is comparatively kind: rows holding the now-out-of-range index fail on read. Mitigations exist — a comment saying "append only, never reorder", an architecture test asserting the ordinal of each constant, an explicit code column — but they all rely on discipline where STRING relies on the data itself. ## Why STRING is the usual default - Stored values are **self-describing**: someone reading `order` in psql sees `SHIPPED`, not `2`. Ad-hoc SQL, dashboards and support queries all get easier. - **Reordering and inserting constants are free.** - Failures are **loud**: reading a name with no matching constant throws rather than silently mapping to another value. Costs, stated honestly: - A wider column (`VARCHAR(20)` vs `SMALLINT`) and a wider index. On a hot, huge table this can matter; on most tables it does not. - **Renaming a constant breaks existing rows.** The refactor is visible in a diff, but it still needs an `UPDATE ... SET status = 'NEW_NAME' WHERE status = 'OLD_NAME'` migration. - Nothing constrains the column to valid values unless you also add a `CHECK` constraint or a lookup table. ## What Hibernate adds Hibernate 6 tightened enum handling: for ORDINAL mappings it prefers a small integer type (`TINYINT`/`SMALLINT`) rather than `INTEGER`, and its schema generation emits a `CHECK` constraint listing the permitted values, so out-of-range data is rejected by the database. Hibernate 6.2 also added `@JdbcTypeCode(SqlTypes.NAMED_ENUM)` (and `NAMED_ORDINAL`), which maps to a **native database enum type** where one exists — for example a PostgreSQL `CREATE TYPE ... AS ENUM` — giving readable values plus database-side validation. That is a Hibernate extension, not portable JPA. If you need full independence from *both* declaration order and constant names, the standard answer is to store an explicit, deliberately assigned code (`"SHP"`, `10`) that lives in the enum as a field and is converted on the way in and out. That decouples the wire format from the Java identifier entirely, at the price of one more moving part. ## Interview framing Say: default is ORDINAL, prefer STRING, explain the reorder failure with a concrete before/after, then acknowledge the storage cost and the rename caveat. That sequence — default, failure mode, tradeoff — is exactly what the question is probing.