In JPA, what is the difference between putting @MappedSuperclass on a shared base class and making that base class an @Entity with @Inheritance, and how do you decide which one a shared base belongs in?

## Two very different mechanisms Both put common state in a shared Java base class, and that surface similarity is why the question is asked. Underneath they are unrelated. ### @MappedSuperclass — a mapping template ```java @MappedSuperclass public abstract class Auditable { @Id @GeneratedValue private Long id; @Column(nullable = false, updatable = false) private Instant createdAt; private String createdBy; @Version private long version; } @Entity class Invoice extends Auditable { private String number; } @Entity class Customer extends Auditable { private String name; } ``` Hibernate treats `Auditable` as a set of instructions applied to every subclass. Schema produced: ``` invoice (id, created_at, created_by, version, number) customer(id, created_at, created_by, version, name) ``` Each concrete table simply carries its own copy of the inherited columns. There is no `auditable` table, no discriminator, no join, and — crucially — **no persistent type called `Auditable`**. Consequences: - `SELECT a FROM Auditable a` is invalid; `Auditable` is not in the JPQL type system. - `@ManyToOne private Auditable owner;` is illegal — you cannot associate with it. - `em.find(Auditable.class, 1L)` is meaningless. - Subclasses may override inherited mappings with `@AttributeOverride` / `@AssociationOverride`. - Lifecycle callbacks (`@PrePersist`, `@PreUpdate`) declared on it **do** apply to subclasses — this is why it is the standard home for auditing fields. - It costs nothing at query time: each entity is a plain single-table entity. ### Entity inheritance — a real polymorphic type ```java @Entity @Inheritance(strategy = InheritanceType.SINGLE_TABLE) public abstract class Payment { @Id @GeneratedValue private Long id; private BigDecimal amount; } @Entity class CardPayment extends Payment { private String cardNumber; } @Entity class BankTransfer extends Payment { private String iban; } ``` Now `Payment` is a queryable, referenceable type: - `SELECT p FROM Payment p WHERE p.amount > 100` returns a mixed list of concrete subclasses. - `@ManyToOne private Payment payment;` works, and Hibernate resolves the concrete type on load. - `em.find(Payment.class, 42L)` returns whichever subclass row 42 is. - `TYPE(p) = CardPayment` and `TREAT(p AS CardPayment)` are available in JPQL. The price is whichever strategy's cost you signed up for: nullable columns (SINGLE_TABLE), joins (JOINED) or unions (TABLE_PER_CLASS), plus polymorphic query cost that grows with the hierarchy. ## The decision rule Ask: **does anything outside the class need to treat the subtypes as one type?** Use `@MappedSuperclass` when the base is *technical* — identifiers, audit stamps, version columns, soft-delete flags, tenant ids. Nobody wants to query "all auditable things"; the base exists so you do not retype five annotations per entity. Use entity inheritance when the base is a *domain concept* — `Payment`, `Document`, `Account` — and the application legitimately lists, references or dispatches on it. If you find yourself running one query per subtype and merging the results in Java, that is the signal you needed a real hierarchy. A useful sanity check: if the base type would never appear as the type of a variable, a method parameter, or a collection element outside its own subclasses, it does not need to be an entity. ## Mistakes this question is testing for - Believing `@MappedSuperclass` produces `TABLE_PER_CLASS`. They look alike in the schema — duplicated columns per concrete table — but `TABLE_PER_CLASS` keeps the base as a queryable entity backed by a `UNION ALL` view, requires hierarchy-wide unique identifiers, and forbids `IDENTITY` generation. `@MappedSuperclass` has none of that machinery because there is no base type at all. - Reaching for entity inheritance to share audit columns, thereby importing polymorphic query cost and a schema decision for zero benefit. - Forgetting that a `@MappedSuperclass` may itself extend another `@MappedSuperclass`, and that a `@MappedSuperclass` can sit *above* an entity hierarchy root — the two mechanisms compose. - Assuming an ordinary (unannotated) Java superclass works: its fields are simply **not** persisted unless the class is `@MappedSuperclass` or `@Entity`. That silent data loss is a classic bug. ## Migration between them Going from `@MappedSuperclass` to entity inheritance is a schema change, not just an annotation change: with SINGLE_TABLE you must merge the per-entity tables into one and add a discriminator; with JOINED you must extract a base table and turn each subclass primary key into a foreign key. It is doable but not free, which argues for thinking about polymorphic need up front — while also arguing against speculatively making everything an entity hierarchy "just in case".