Skip to content
Bluetape4k docs1.11

Choosing a persistence technology

Latest stable Based on Bluetape4k release 1.11.0

Primary requirementStart withReason
Spring JPA, blocking JDBC, conventional EntityManagerbluetape4k-hibernateUses regular Hibernate Session and the JPA ecosystem.
Non-blocking I/O while retaining relations and dirty checkingbluetape4k-hibernate-reactiveRuns Reactive ORM over the Vert.x SQL Client.
Direct control of SQL, row mapping, pools, and Flowbluetape4k-r2dbcBuilds R2DBC boundaries without an ORM persistence context.

Both Hibernate modules share the entity-mapping model but differ in execution. Conventional Hibernate fits JDBC-based blocking calls, EntityManager and Session helpers, converters, and Querydsl integration. Hibernate Reactive assumes a Vert.x context, Uni or CompletionStage, and reactive Session APIs.

Although bluetape4k-hibernate-reactive has an API dependency on bluetape4k-hibernate, do not call blocking helpers inside a reactive callback. Entity models and common types may be shared; execution models may not.

R2DBC makes queries and row mapping central. The code directly shows which SQL runs and which DTO receives each row, without entity graphs, cascades, or dirty checking. Hibernate Reactive is stronger when entity relations and the persistence context are the primary model.

Use these questions to choose:

  • Must relation changes be expressed through a managed-entity lifecycle?
  • Is the team prepared to operate lazy associations and fetch plans?
  • Would direct vendor SQL and row mapping be simpler?
  • Does the team already own JPA mappings or SQL/R2DBC pipelines?

Different bounded contexts may choose different technologies. Within one atomic operation, however, make sure they do not open independent connections and transactions. When multiple technologies update the same table, document version columns, cache invalidation, and schema-migration ownership.