Java persistence frameworks comparison

This project compares usage of non-JPA SQL mapping (persistence) frameworks for Java (jOOQ, Spring JDBCTemplate, etc.). We used it to find out which DB layer would be best during development of

I'm not comparing performance, but rather how are these frameworks used for everyday tasks.

I prepared some common scenarios, which you typically need to implement a data-centric application, and then I implemented these scenarios using various non-JPA DB layer frameworks. This project should serve

Use code in the repository as you like (MIT License)

Frameworks compared

I have following (subjectively evaluated :)) conditions on frameworks which I choose for consideration:

  1. The framework should embrace - not hide - SQL language and RDBMS we are using
  2. The framework must be mature enough for "enterprise level" use.
  3. Can utilize JPA annotations, but must not be full JPA implementation (see "Why only non-JPA?" section below)

With that conditions in respect, following frameworks were compared:

I tried to find optimal (== most readable) implementation in every framework, but comments are welcomed! There are a lot of comments in the code explaining why I chose such implementation and some FIXMEs on places which I do not like, but which cannot be implemented differently or which I have troubles to improve...

Furthermore, I considered (and tried to implement) even following frameworks, but it turned out they do not meet the conditions:

Scenarios implemented

These are the scenarios:

  1. Fetch single entity based on primary key
  2. Fetch list of entities based on condition
  3. Save new single entity and return primary key
  4. Batch insert multiple entities of the same type and return generated keys
  5. Update single existing entity - update all fields of entity at once
  6. Fetch many-to-one relation (Company for Department)
  7. Fetch one-to-many relation (Departments for Company)
  8. Update entities one-to-many relation (Departments in Company) - add two items, update two items and delete one item - all at once
  9. Complex select - construct select where conditions based on some boolean conditions + throw in some JOINs
  10. Call stored procedure/function and process results
  11. Execute query using JDBC simple Statement (not PreparedStatement)
  12. Remove single entity based on primary key

Each scenario has it's implementation in the Scenarios class. See Javadoc of Scenarios methods for a more detailed description of each scenario.

Model used

Simple company database model


  1. Clone the repository
  2. Configure PostgreSQL connection details in
  3. Create tables and data by running create-script.sql
  4. Create one stored procedure by running register_employee.sql
  5. JUnit tests will pass when executed from a Gradle build. If you want tests to be passing even from your IDE, then setup EBean enhancer for your IDE
  6. Give the scenarios a test run by running one of the test classes and enjoy :)

Why only non-JPA?

Well, I and my colleagues were always trying to "stick with the standard" in our projects so we used JPA in the past, but after many years of JPA usage (Hibernate mostly), we realized it's counterproductive. In most of our projects, it caused more problems than it helped to solve - especially in big projects (with lots of tables and relations). There are many reasons for those failures - but the biggest issue is that JPA implementations simply turned into bloatware. A lot of strange magic is happening inside and the complexity is so high, that you need a high-class Hibernate "mega expert" in every team so the app actually shows some performance and the code is manageable...

So we dropped JPA completely, started using JDBCTemplate and discovered that we can deliver apps sooner (which was kind of surprising), they are a lot faster (thanks to effective use of DB) and much more robust... This was really relaxing and we do not plan to return to JPA at all... (yes, even for CRUD applications!)

This project aims to explore other options in the SQL mapping area than just JDBCTemplate.


Please note that following remarks are very subjective, opinionated and do not have to necessarily apply to you.

What would I choose

  1. If a project manager is ok with an additional cost of a license or the project uses one of open source databases (like PostgreSQL) then definitely go with jOOQ.
  2. If your project uses Oracle, DB2, MSSQL or any other commercial database and additional cost for the jOOQ license is not acceptable, then go with JDBCTemplate (for me, personally, it wins over other choices for its maturity and documentation).

Subjective pros/cons of each framework

JDBC Template




JDBI (version 2.77)