Skip to content
Bluetape4k docs1.11

Choosing the surrounding persistence stack

Latest stable Based on Bluetape4k release 1.11.0

Hibernate fits aggregate lifecycle, dirty checking, lazy associations, JPA annotations, and Spring Data JPA. A small SQL adapter or reporting query can be simpler without entity state and flush rules.

NeedStart withBoundary
Direct SQL, connection, and vendor controlbluetape4k-jdbcExplicit mapping and transactions
JPA lifecycle and Spring Databluetape4k-hibernateORM aggregate model
Kotlin table and SQL DSLbluetape4k-exposedSQL-oriented JDBC or R2DBC runtime
Non-blocking persistencebluetape4k-hibernate-reactive, bluetape4k-r2dbcDo not wrap blocking Session calls in coroutines

Hibernate and JDBC can coexist, but one transaction owner must provide the connection when they share a transaction. Do not leak Hibernate entities, Exposed rows, and JDBC DTOs across the same persistence boundary.

Hibernate is natural when aggregate changes are persisted by dirty checking. Exposed is often simpler when SQL shape stays explicit and rows map directly to DTOs. Existing JPA mappings, Spring Data repositories, and operational tooling also influence the choice. Align all library versions through the bluetape4k-dependencies BOM.

This chapter can later link to a central ecosystem guide for Hibernate versus Exposed, JDBC-to-R2DBC migration, and transaction-manager combinations.