jOOQ

A Java library that models SQL as a type-safe API: a code generator reads your database schema into Java classes, and you write queries against them that the compiler checks.

What it is: Object-relational mapping (query builders)
Type: Open source
Made by: Data Geekery GmbH
License: Apache 2.0 with open-source databases; commercial licence for commercial databases
Facts checked: 8 October 2026

What it is

jOOQ describes itself as an internal DSL and source code generator that models the SQL language as a type-safe Java API. You point the code generator at a live database (or at SQL or Liquibase files) and it writes a Java class per table, with typed fields per column: AUTHOR.LAST_NAME, BOOK.AUTHOR_ID. Queries are then ordinary Java method chains, create.select(...).from(AUTHOR).join(BOOK).on(...), that read like SQL, render to the dialect you configure, and come back as typed records. If a column is renamed, regenerating the classes turns every query that used it into a compile error. It can also be used without code generation, as a plain SQL builder or executor.

jOOQ keeps SQL in charge rather than objects. There is no session or lazy loading: nested data comes from joins, implicit joins along foreign keys, or the standard SQL MULTISET operator, which jOOQ emulates with SQL/JSON or SQL/XML on databases that lack it, to return nested collections in one query. Secondary features include UpdatableRecord CRUD and generated DAOs, a SQL parser that translates between dialects, reactive execution through R2DBC, and support for Kotlin and Scala. The README claims dialect support for 30+ databases. The Open Source Edition, under Apache 2.0, covers the latest versions of open-source databases such as PostgreSQL, MySQL, MariaDB, SQLite, DuckDB and ClickHouse; Oracle, SQL Server, older database versions and support need a commercial edition, from €99 to €799 per developer workstation per year, with servers licensed free. The current release is 3.21.

Why teams pick it

SQL with compile-time checking: generated classes make column and type errors show up in the build, not in production
Full access to each database’s SQL, including window functions, CTEs and MULTISET nested collections
Predictable: what you write is the query that runs, with no session, lazy loading or hidden flushes
Works alongside JPA or alone, from Java, Kotlin or Scala, with a translator between SQL dialects

Watch out for

Commercial databases such as Oracle and SQL Server, and older versions of open-source ones, require a paid licence per developer
The code generator adds a build step that needs the schema available, from a running database or from SQL or Liquibase files
No object graph or unit of work: rich domain models and change tracking are left to you
Long method chains and generated types can be verbose next to plain SQL strings

Alternatives

What all query builders have in common →

Drizzle ORMOpen sourceA TypeScript library that declares tables in code and queries them through a typed API shaped like SQL, plus a relational API for nested data that always compiles to a single SQL statement.

How it fits with other technologies

What jOOQ uses

A join and aggregation written against classes generated from the schema · java

import static org.jooq.impl.DSL.count;
import static com.example.db.Tables.*;   // AUTHOR, BOOK: generated by jOOQ’s code generator

DSLContext create = DSL.using(connection, SQLDialect.POSTGRES);

Result<Record2<String, Integer>> result = create
    .select(AUTHOR.LAST_NAME, count())
    .from(AUTHOR)
    .join(BOOK).on(BOOK.AUTHOR_ID.eq(AUTHOR.ID))
    .where(BOOK.PUBLISHED_IN.gt(2000))       // a typo in a column name won’t compile
    .groupBy(AUTHOR.LAST_NAME)
    .orderBy(count().desc())
    .fetch();

See it in a real stack

No architecture uses jOOQ yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2009–2026

Lukas Eder started jOOQ around 2009, when, in his words, the Java database middleware market was dominated by ORMs implementing JPA and hardly challenged by alternatives. Developers who wrote a lot of SQL had no API that made SQL a first-class citizen in Java. jOOQ filled that gap by using the Java compiler to check a SQL statement’s syntax and types.

For its first four years jOOQ was free under the Apache License 2.0. With jOOQ 3.2 in October 2013, Eder’s company Data Geekery made it dual-licensed: still Apache 2.0 for use with open-source databases, and a commercial licence with professional support and warranties for commercial databases such as Oracle and SQL Server, which customers had been asking for. After feedback on the first licence’s wording, a revised version explicitly allowed customers to embed jOOQ in their applications.

jOOQ has since leaned further into what SQL can do. Version 3.15 in July 2021 added the MULTISET operator for nested collections in a single query, and today’s releases also cover DuckDB, ClickHouse and Trino. The 3.21 series is current, with 3.22 in development.

Why it’s built this way

Model SQL, not objects: JPA ORMs hid SQL behind an object model. jOOQ’s premise was that developers who think in SQL should be able to write it directly in Java and have the compiler validate it.
Generate code from the database schema: Generating a class per table ties queries to the real schema, so type mismatches and renamed columns fail at compile time rather than at runtime.
Dual licensing: Customers on commercial databases wanted support and warranties. Charging only for commercial databases kept jOOQ free for open-source stacks while funding the work.
Nested results with MULTISET instead of lazy loading: Rather than map object graphs and fetch children on demand, jOOQ uses a standard SQL operator to return nested collections in one query, avoiding N+1 round trips.

Timeline

2009
Lukas Eder starts jOOQ
2013
jOOQ 3.2 introduces dual licensing in October
2021
jOOQ 3.15 adds MULTISET nested collections in July
2026
jOOQ 3.21 is the current release

Sources6 · facts checked 8 October 2026

Improve this page on GitHub