Embeddable database with Quarkus (SQL or JSON)

[Stwissel]

have a project where I need to store a few thousand records, nothing big. So we were thinking an embeddable database would do just fine. This is what I found so far:

• h2 using quarkus-jdbc-h2 (but no (?) support for native compile)
• embedded postgres using io.quarkiverse.embedded.postgresql:quarkus-embedded-postgresql
• SQLite via quarkus-jdbc-sqlite
• SQLite via quarkus-jdbc-sqlite4j
• ArcadeDb

Anyone has experience with one (or more) of them to share?

[rameshreddy-adutla]

For a few thousand records with Quarkus, you have several solid embedded options:

1. H2 (Recommended for simplicity)

# application.properties
quarkus.datasource.db-kind=h2
quarkus.datasource.jdbc.url=jdbc:h2:file:./data/mydb
quarkus.hibernate-orm.database.generation=update

Dependency: quarkus-jdbc-h2 + quarkus-hibernate-orm-panache

Pros: Zero config, file-based persistence, full SQL support, great Quarkus integration.
Cons: Not ideal for concurrent write-heavy workloads.

2. SQLite (Lightest footprint)

<dependency>
    <groupId>io.quarkiverse.jdbc</groupId>
    <artifactId>quarkus-jdbc-sqlite</artifactId>
</dependency>

quarkus.datasource.db-kind=other
quarkus.datasource.jdbc.url=jdbc:sqlite:./data/mydb.sqlite
quarkus.datasource.jdbc.driver=org.sqlite.JDBC

Pros: Smallest footprint, single file, battle-tested. Perfect for a few thousand records.
Cons: Limited concurrent write support, Quarkiverse extension (not core).

3. Derby (Apache, fully embedded)

quarkus.datasource.db-kind=derby
quarkus.datasource.jdbc.url=jdbc:derby:./data/mydb;create=true

Pros: Pure Java, good Quarkus support.
Cons: Larger footprint than H2/SQLite.

My recommendation

For a few thousand records → go with H2 in file mode. It has first-class Quarkus support, works with Panache out of the box, supports both native and JVM mode, and is well-documented in the Quarkus guides.

If you want JSON document storage instead of SQL, consider embedding a simple JSON file store with Jackson, or use H2 with its JSON column type (JSON data type supported since H2 2.x).

For native compilation, note that H2 works in native mode with Quarkus but you may need to include the appropriate GraalVM configuration.

[Stwissel]

Thx. Appreciate the detailed comparison. Where can I find the GraalVM settings for h2?

[mschorsch]

No experience, but another idea 😁: you could use the WASM build from PGLite and then use it via quarkus-quicory. Advantage: full PostgreSQL, disadvantage: effort required to set up.

cc @fabiobrz

[rameshreddy-adutla]

When using quarkus-jdbc-h2, Quarkus handles most of the GraalVM native image configuration automatically — you don't need to add manual reflect/resource configs for H2.

Just add the dependency and it works:

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-jdbc-h2</artifactId>
</dependency>

quarkus.datasource.db-kind=h2
quarkus.datasource.jdbc.url=jdbc:h2:file:./data/mydb

Then build native:

./mvnw package -Dnative

The quarkus-jdbc-h2 extension registers the necessary GraalVM substitutions (reflection config, resource bundles, etc.) at build time via Quarkus's extension mechanism.

If you hit issues (rare, but possible with advanced H2 features like custom functions or fulltext search), you can add manual GraalVM hints:

# application.properties
quarkus.native.additional-build-args=\
  --initialize-at-run-time=org.h2.store.fs.FilePathNio

Or via @RegisterForReflection on any custom H2 types.

But for the standard use case (file-based storage, Panache/Hibernate ORM), quarkus-jdbc-h2 handles everything out of the box in native mode.