High-Performance Java Persistence: JDBC, JPA, Hibernate and jOOQ Examples

What the High-Performance Java Persistence Examples Cover

This repository contains the code examples for the High-Performance Java Persistence book and video course. Its intended users are Java developers working with database access code who want concrete examples involving JDBC, JPA, Hibernate or jOOQ. The README specifically describes it as a place to test those technologies, which makes it more useful than a collection of isolated SQL snippets: each example sits in a buildable Maven project with tests and database integration.

The repository is organized into `core/` and `jooq/`, while `pom.xml`, `build.sh` and `build.bat` provide the top-level project structure. It covers multiple persistence approaches rather than prescribing one. That breadth is useful for comparing low-level JDBC with higher-level JPA and Hibernate abstractions, or with jOOQ. It does not, however, describe itself as a reusable persistence starter kit, and the repository entry list does not indicate a packaged artifact intended for direct application dependencies.

The examples are educational and diagnostic code. They are intended to help developers inspect persistence behavior, mappings, entity relationships, queries and database-specific integration paths. The README contains a separate promotional section about Hypersistence Optimizer. That product reference is not evidence that this repository includes automatic JPA or Hibernate analysis.

Java 17, Maven and Database Selection

The build has a clear minimum toolchain. Every example requires Java 17 or newer because the project uses Text Blocks for more readable JPQL and SQL queries. The README requires Maven 3.6.2 or newer. IntelliJ IDEA is also supported, provided the project is configured to use Java 17 or newer.

Database behavior depends on which test is selected. With no explicit database configuration, tests use HSQLDB. Some integration tests are deliberately tied to Oracle, SQL Server, PostgreSQL, MySQL, MariaDB, YugabyteDB or CockroachDB. For those tests, the project first searches for a local relational database. If it cannot find one, the test uses Testcontainers to start the required database container automatically. This makes database-specific coverage possible without installing every supported database on the host, although the README notes that local databases run faster than container-based startup.

The repository also contains `docker-compose.yml` for MySQL and PostgreSQL. Its MySQL service exposes port `3306`, uses image `mysql:8.4`, and initializes the `high_performance_java_persistence` database. Its PostgreSQL service exposes port `5432`, uses image `postgres:18`, and creates the same database name. These services are optional setup aids rather than evidence that every integration test runs against both engines.

The database configuration is implemented through `DatasourceProvider` instances. The README names `PostgreSQLDataSourceProvider` as an example, so this is the relevant extension point when selecting or changing a JDBC connection for a test.

Running the Examples for the First Time

There is no complete installation or first-test command in the README, so there is no justified command block to reproduce here. The documented setup path is to obtain the repository, configure Java 17 or newer and Maven 3.6.2 or newer, then open or build it with Maven. The README does not provide the exact clone command, a wrapper invocation or the precise test selector for a first example.

For the default path, the most concrete first use is to run a test without configuring an external database, because the README states that HSQLDB is used in that case. The test framework will exercise the persistence code against the embedded default. The repository layout should make the examples discoverable through IntelliJ IDEA, but the README does not name a particular module, test class or expected result.

For a database-specific example, first make the target RDBMS available and configure the corresponding `DatasourceProvider`. If no local instance is found for a supported external database, the project is documented to use Testcontainers. This distinction matters: configuring a local database and allowing Testcontainers to supply one are separate paths, with different startup costs and environmental requirements.

The build files are present, but their contents are not included in the README. It would therefore be unsafe to invent Maven goals, profiles, environment variables or test selectors. A new user should first inspect `pom.xml` and the relevant `DatasourceProvider` before attempting a DB-specific run.

Local Docker Services and Manual Database Requirements

The `docker-compose.yml` file defines two optional services with fixed credentials and database names. MySQL uses the `mysql` user with password `admin`, while PostgreSQL uses the `postgres` user with the same password. Both create `high_performance_java_persistence` and publish their standard container ports to the host.

services:
  mysql:
    image: mysql:8.4
    container_name: hpjp-mysql
    ports:
      - "3306:3306"
    environment:
      MYSQL_ROOT_PASSWORD: admin
      MYSQL_DATABASE: high_performance_java_persistence
      MYSQL_USER: mysql
      MYSQL_PASSWORD: admin
  postgres:
    image: postgres:18
    container_name: hpjp-postgres
    ports:
      - "5432:5432"
    environment:
      POSTGRES_DB: high_performance_java_persistence
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: admin

This excerpt shows the configured service identities and connection ports. The README separately states that MySQL 8 requires the `mysql` user password `admin`, and that the user needs schema privileges plus select permission on `mysql.PROC`. PostgreSQL requires a database named `high_performance_java_persistence`. Oracle requires Oracle XE, a `sys` password of `admin`, and a database user named `oracle`. SQL Server Express Edition uses mixed-mode authentication and an `sa` password of `adm1n`.

Those settings are suitable for the documented local development examples, not for production credentials or production deployment. The Oracle instructions also involve changing listener settings and restarting Windows services, so that path is more invasive than the HSQLDB default.

Why the Examples Need Database-Specific Tests

The repository's main value is its support for comparing persistence mechanisms against real relational database behavior. JDBC exposes SQL and resource handling directly. JPA and Hibernate add mapping, entity relationship and query abstractions. jOOQ provides a type-oriented Java API that can generate database-aware SQL. The README positions the examples as a way to test code involving all four, but it does not provide a comparative matrix or claim that one approach performs better than another.

The test strategy also reflects an important boundary. A database-specific test may require Oracle, SQL Server, PostgreSQL, MySQL, MariaDB, YugabyteDB or CockroachDB because the test is written for that engine's behavior. Running only the default HSQLDB path does not prove that a JDBC statement, JPQL query, Hibernate mapping or jOOQ query will behave identically elsewhere. Database selection is therefore part of interpreting a result, not merely an environment preference.

The source also includes a `docker/` directory and database-specific initialization material referenced by the Compose configuration. Based on the repository layout, these files support repeatable local setup. The README does not claim that the examples model production deployment, and it does not publish benchmark results, latency figures or throughput comparisons. Any performance conclusion must come from measurements taken against a defined schema, dataset, database and workload.

Maintenance, License and Upgrade Boundaries

The repository is not archived, and its last push was on 2026-10-15. There are no GitHub releases listed. That means there is no release history here to use as a compatibility matrix or migration target. The absence of releases also means that consumers should treat the default branch as the source of truth and inspect the build files before depending on an example.

Upgrading the project can affect Java, Maven, database images and provider assumptions. The README sets minimum versions for Java and Maven, but it does not publish an upgrade policy for individual examples. Docker images are pinned in `docker-compose.yml` to `mysql:8.4` and `postgres:18`, so changing those values would be a deliberate environment change rather than an automatically documented upgrade path.

The repository is licensed under `Apache-2.0`. That license provides the stated permissions and conditions for use and redistribution, but this review does not interpret the license as legal advice. The code examples are still subject to the dependencies declared by the project, and the README does not provide a dependency audit or compatibility statement for every supported database.

Where This Repository Is the Wrong Choice

This project is the wrong tool when you need a production persistence framework with a supported public API, automatic migrations, runtime monitoring or vendor support. It is code examples for a book and course, not a general-purpose ORM distributed as a normal application framework. The README also does not document a standalone command-line application, deployment service or API.

It is also unsuitable as a shortcut to performance validation. The repository gives examples and integration tests, but the README contains no benchmark protocol, dataset definition or claim of a guaranteed speed improvement. A team should not infer production behavior from HSQLDB results or from a passing database-specific test without checking the SQL, schema, indexes, connection settings and workload.

The repository is a better fit for developers studying persistence patterns or maintaining a test matrix across JDBC, JPA, Hibernate and jOOQ. Its practical limitation is that setup knowledge is spread across the README, Maven configuration, database providers and Compose files. The README does not provide a complete first-run tutorial with a verified test command, so adoption requires reading those project files rather than installing a self-contained library.

Editorial conclusion

Adopt this repository if you need executable examples or database-specific tests for Java persistence work. Do not treat it as an application framework or as evidence of performance gains without measuring your own workload. Verify first that your Java 17 or newer, Maven 3.6.2 or newer, database availability and target database match the example you intend to use.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. vladmihalcea/high-performance-java-persistence on GitHub