Quarkus JNoSQL Extension

This documentation provides instructions on how to integrate Eclipse JNoSQL, an implementation of the Jakarta NoSQL and Jakarta Data specifications, into a Quarkus project using the Quarkus JNoSQL Extension. This extension supports JNoSQL and facilitates using NoSQL databases in your Quarkus applications.

Introduction

The Quarkus NoSQL Extension facilitates seamless interaction between Quarkus and Eclipse JNoSQL, enabling easy integration with various NoSQL databases in Quarkus applications. By following the steps outlined in this documentation, Quarkus developers can effortlessly incorporate Eclipse JNoSQL into their projects, simplifying NoSQL database interactions and empowering the development of efficient and scalable applications. Eclipse JNoSQL adheres to two essential Jakarta EE specifications: Jakarta Data and Jakarta NoSQL.

Jakarta NoSQL is a Java framework designed to streamline the integration of Java applications with various NoSQL databases. It offers a consistent and easy-to-use API, allowing developers to interact with different NoSQL databases seamlessly.

On the other hand, the Jakarta Data specification provides an API for simplified data access to various database types, including relational and NoSQL databases. Java developers can access these repositories through multiple methods, such as composing custom queries on a Repository interface.

Integrating Eclipse JNoSQL into Quarkus projects ensures adherence to these Jakarta EE standards and leverages the benefits of standardized APIs for enhanced productivity and maintainability.

Why Use Quarkus JNoSQL Extension?

The Quarkus NoSQL Extension offers several advantages for developers:

  • Simplified NoSQL Integration: Abstracts the complexity of working with different NoSQL databases, providing a consistent API regardless of the underlying technology. Facilitates easy switching between databases or using multiple databases in a single application.

  • Type-Safe Queries: Empowers developers to write database queries using Java code rather than raw query strings, improving code readability and catching errors at compile-time.

  • Seamless Quarkus Integration: Utilizes Quarkus' fast startup times and efficient resource utilization while working with NoSQL databases, ensuring lightweight and responsive applications.

  • Database Agnosticism: Supports a wide range of database models, including key-value, document, column, graph, and time-series databases. Offers flexibility to choose the most suitable database for specific use cases without major code changes.

  • Rich Documentation and Ecosystem: Eclipse JNoSQL boasts a thriving community and comprehensive documentation, making it easy for developers to find support, tutorials, and examples. Integration with Quarkus allows tapping into the vibrant Quarkus ecosystem as well.

Getting Started

To use this extension, add the Quarkus JNoSQL Database extension that you need to your build file.For instance, with Maven, include the following dependency in your POM file:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-[DATABASE]</artifactId>
    <version>3.8.0</version>
</dependency>

Replace [DATABASE] with the specific database you want to use. See the supported databases in the next section.

Recommended Quarkus JNoSQL Extension version: 3.8.0 or higher

Supported Databases

The Quarkus JNoSQL extension supports several NoSQL database models. The databases are grouped by their primary data model to make it easier to find the right extension for each use case.

Document

Database Vendor Supports Jakarta Data Provides Codestart Supports Native Compilation

MongoDB

✅

✅

✅

CouchDB

✅

✅

✅

Elasticsearch

✅

✅

❌

Solr

✅

✅

✅

Column

Database Vendor Supports Jakarta Data Provides Codestart Supports Native Compilation

Cassandra

✅

✅

✅

ScyllaDB

✅

✅

✅

Key-Value

Database Vendor Supports Jakarta Data Provides Codestart Supports Native Compilation

DynamoDB

✅

✅

✅

Hazelcast

✅

✅

✅

Redis

✅

✅

✅

Infinispan

✅

✅

Not verified

Memcached

✅

✅

✅

Valkey

✅

✅

✅

Graph

Database Vendor Supports Jakarta Data Provides Codestart Supports Native Compilation

Neo4j

✅

✅

✅

Apache TinkerPop

✅

❌

Depends on the provider

Time Series

Database Vendor Supports Jakarta Data Provides Codestart Supports Native Compilation

InfluxDB

✅

❌

✅

Apache IoTDB

✅

❌

❌

QuestDB

✅

❌

✅

Vector

Database Vendor Supports Jakarta Data Provides Codestart Supports Native Compilation

Qdrant

✅

✅

Not verified

Milvus

✅

✅

Not verified

Weaviate

✅

✅

Not verified

Multi-model

Database Vendor Supported NoSQL Type Supports Jakarta Data Provides Codestart Supports Native Compilation

ArangoDB

Document and Key-Value

✅

✅

✅

Oracle NoSQL

Document and Key-Value

✅

✅

✅

Create your Quarkus JNoSQL Project using Extension Codestarts

The easiest way to get started with Quarkus JNoSQL Extension is by using the codestart provided by the extension. This codestart will generate a Quarkus project with the necessary dependencies and configurations for using JNoSQL with your chosen NoSQL database.

You can use the Quarkus CLI to create a new project passing the Quarkus JNoSQL Extension that you want. It’ll create the project with all required dependencies and configurations automatically. For example, to create a project using Quarkus JNoSQL MongoDB Extension, you can run:

quarkus create app --extensions=jnosql-mongodb

Here are the Quarkus JNoSQL extensions that currently provide codestarts, grouped by database type:

Document

Database Vendor Command

MongoDB

quarkus create app --extensions=jnosql-mongodb

CouchDB

quarkus create app --extensions=jnosql-couchdb

Elasticsearch

quarkus create app --extensions=jnosql-elasticsearch

Solr

quarkus create app --extensions=jnosql-solr

Column

Database Vendor Command

Cassandra

quarkus create app --extensions=jnosql-cassandra

ScyllaDB

quarkus create app --extensions=jnosql-scylladb

Key-Value

Database Vendor Command

DynamoDB

quarkus create app --extensions=jnosql-dynamodb

Hazelcast

quarkus create app --extensions=jnosql-hazelcast

Redis

quarkus create app --extensions=jnosql-redis

Infinispan

quarkus create app --extensions=jnosql-infinispan

Memcached

quarkus create app --extensions=jnosql-memcached

Valkey

quarkus create app --extensions=jnosql-valkey

Graph

Database Vendor Command

Neo4j

quarkus create app --extensions=jnosql-neo4j

Apache TinkerPop

quarkus create app --extensions=jnosql-tinkerpop

Vector

Database Vendor Command

Qdrant

quarkus create app --extensions=jnosql-qdrant

Milvus

quarkus create app --extensions=jnosql-milvus

Weaviate

quarkus create app --extensions=jnosql-weaviate

Multi-model

Database Vendor Command

ArangoDB

quarkus create app --extensions=jnosql-arangodb

Oracle NoSQL

quarkus create app --extensions=jnosql-oracle-nosql

The Time Series extensions can currently be added manually to an existing Quarkus project. See the Time Series Databases section for InfluxDB, Apache IoTDB, and QuestDB.

Or you could create it on by downloading the scaffolding project from the code.quarkus.io and selecting the JNoSQL extension for your desired NoSQL database.

Manually adding Quarkus JNoSQL Extension to your project

There are a variety of NoSQL databases, each with its own unique features and capabilities. See the section Supported NoSQL Databases, select the one that fits your needs, and then follow the instructions below to manually add the Quarkus JNoSQL Extension to your project.

If you are using Java 21 or above, make sure to enable the annotation processor execution. If you are using Java 17 or below, you can skip this step and go ahead to implement your entities and repositories.

Enabling the JNoSQL Mapping Lite Annotation Processor

The Quarkus JNoSQL Extensions use the annotation processor provided by the org.eclipse.jnosql.lite:mapping-lite-processor dependency.

This annotation processor generates the required implementation classes used by CDI during build-time processing and AOT compilation.

Although the processor dependency may be included transitively by a Quarkus JNoSQL extension, declaring it explicitly in the compiler configuration makes the build more predictable. This is especially useful when the project uses explicit annotation processor configuration.

Before setting the processor version, check the latest available version on Maven Central:

org.eclipse.jnosql.lite:mapping-lite-processor on Maven Central

To ensure that the annotation processor is executed during the build process, configure your build tool, either Maven accordingly.

Maven

When using Maven, configure the maven-compiler-plugin with the JNoSQL Lite annotation processors explicitly.

The following example enables parameter metadata, sets the Java release version, and registers both the entity and repository processors:

<project>
    <!-- skipping other elements -->
    <build>
        <plugins>
            <!-- skipping other plugins -->

            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>${compiler-plugin.version}</version>
                <configuration>
                    <release>${maven.compiler.release}</release>
                    <parameters>true</parameters>
                    <annotationProcessors>
                        <annotationProcessor>org.eclipse.jnosql.lite.mapping.EntityProcessor</annotationProcessor>
                        <annotationProcessor>org.eclipse.jnosql.lite.mapping.repository.RepositoryProcessor</annotationProcessor>
                    </annotationProcessors>
                    <annotationProcessorPaths>
                        <path>
                            <groupId>org.eclipse.jnosql.lite</groupId>
                            <artifactId>mapping-lite-processor</artifactId>
                            <version>${jnosql-lite-processor.version}</version>
                        </path>
                    </annotationProcessorPaths>
                </configuration>
            </plugin>

            <!-- skipping other plugins -->
        </plugins>
    </build>
    <!-- skipping other elements -->
</project>

The properties used in this example, such as ${compiler-plugin.version}, ${maven.compiler.release}, and ${jnosql-lite-processor.version}, should be defined according to your project setup.

Replace ${jnosql-lite-processor.version} with the latest available version from Maven Central when configuring your project.

Gradle

The target build tool for the Quarkus JNoSQL Extension is Maven. However, if you are using Gradle, you should also make sure that the JNoSQL Lite annotation processor is available during compilation.

The processor is provided by the org.eclipse.jnosql.lite:mapping-lite-processor dependency.

Before setting the processor version, check the latest available version on Maven Central: org.eclipse.jnosql.lite:mapping-lite-processor on Maven Central

When using the JNoSQL Lite annotation processor with Gradle, exclude the jnosql-mapping-reflection module to prevent CDI bean conflicts. In extension versions 3.4.15 and earlier, this module is pulled in transitively, causing both the reflection-based and Lite EntitiesMetadata implementations to be registered as CDI beans. Without this exclusion, the application fails with an AmbiguousResolutionException.

For additional details and the current status of this issue, see GitHub issue #423.

Groovy DSL (build.gradle)

dependencies {
    annotationProcessor "org.eclipse.jnosql.lite:mapping-lite-processor:${jnosqlLiteProcessorVersion}"
}

// Exclude the reflection-based metadata implementation when using JNoSQL Lite.
// Otherwise, both reflection and Lite implementations become CDI beans,
// resulting in an AmbiguousResolutionException.
configurations.configureEach {
 exclude group: 'org.eclipse.jnosql.mapping', module: 'jnosql-mapping-reflection'
}

tasks.withType(JavaCompile).configureEach {
    options.compilerArgs += [
        "-processor",
        "org.eclipse.jnosql.lite.mapping.EntityProcessor,org.eclipse.jnosql.lite.mapping.repository.RepositoryProcessor"
    ]
}

Kotlin DSL (build.gradle.kts)

dependencies {
    annotationProcessor("org.eclipse.jnosql.lite:mapping-lite-processor:${jnosqlLiteProcessorVersion}")
}

// Exclude the reflection-based metadata implementation when using JNoSQL Lite.
// Otherwise, both reflection and Lite implementations become CDI beans,
// resulting in an AmbiguousResolutionException.
configurations.configureEach {
    exclude(
        group = "org.eclipse.jnosql.mapping",
        module = "jnosql-mapping-reflection"
    )
}
tasks.withType < JavaCompile > ().configureEach {
    options.compilerArgs.addAll(
        listOf(
            "-processor",
            "org.eclipse.jnosql.lite.mapping.EntityProcessor,org.eclipse.jnosql.lite.mapping.repository.RepositoryProcessor"
        )
    )
}

The jnosqlLiteProcessorVersion variable should be defined according to your project setup.

Replace it with the latest available version from Maven Central when configuring your project.

Using Jakarta NoSQL and Jakarta Data with Quarkus JNoSQL

Once you have added the Quarkus JNoSQL Extension to your project, you can start using it to interact with your NoSQL database. The following steps outline how to create entities and repositories in your Quarkus application:

Creating entities using Jakarta NoSQL annotations

You can use a POJO (Plain Old Java Object) class annotated with Jakarta NoSQL annotations to represent your entities. For example:

import jakarta.nosql.Column;
import jakarta.nosql.Entity;
import jakarta.nosql.Id;

@Entity
public class TestEntity {

    @Id
    private String id;

    @Column
    private String testField;

    // omitted getters and setters
}

Or Java Record class as well. For example:

import jakarta.nosql.Column;
import jakarta.nosql.Entity;
import jakarta.nosql.Id;

@Entity
public record TestEntity (@Id String id, @Column String testField) {

    // omitted factory methods, or any additional methods
}

More information about Jakarta NoSQL Annotations can be found in the Jakarta NoSQL Specification.

Embeddable Fields and Embeddable classes

Jakarta NoSQL supports Embeddable Fields as well. An embeddable field is a field whose type is an embeddable class. Embeddable classes must be annotated with @jakarta.nosql.Embeddable annotation.

An embeddable class does not have its own database structure. Instead, the state of an instance is stored in the structure mapped by the owning entity.

Persistent fields and properties of an embeddable class are mapped using the same mapping annotations used for entity classes and may hold instances of other embeddable types.

An embeddable class can have two types of strategies:

  • @Embeddable(FLAT) or @Embeddable: where the embeddable class is treated as a parent entity type.

  • @Embeddable(GROUPING): where the embeddable class is stored in a structured type.

In the example below, the Address class is an embeddable class that will be flattening their state into the data structure representing the parent entity:

import jakarta.nosql.Column;
import jakarta.nosql.Embeddable;

@Embeddable
public class Address {
    @Column
    private String street;
    @Column
    private String city;
    @Column
    private String postalCode;
}
import jakarta.nosql.Column;
import jakarta.nosql.Entity;
import jakarta.nosql.Id;

@Entity
public class Person {
    @Id
    private Long id;
    @Column
    private String name;
    @Column
    private Address address;  // flat embedded field
}

In a document, wide-column, or graph database, the JSON representation of a Person entity instance where the Address class is flat might be:

{
  "id": 1,
  "name": "John Doe",
  "street": "123 Main St",
  "city": "Sampleville",
  "postalCode": "12345"
}

In a structured representation, when the embeddable field is grouping it will be together in the data schema.

@Embeddable(GROUPING)
public class Address {
    @Column
    private String street;
    @Column
    private String city;
    @Column
    private String postalCode;
}

In a document, wide-column, or graph database, the JSON representation of a Person entity instance where the Address class is grouping might be:

{
  "id": 1,
  "name": "John Doe",
  "address":
  {
    "street": "123 Main St",
    "city": "Sampleville",
    "postalCode": "12345"
  }
}

For more information about embeddable fields and classes, take a look at the Jakarta NoSQL Specification.

Using Jakarta NoSQL Template

Example using jakarta.nosql.Template:

@Inject
// If your NoSQL database supports multiple types,
// you can specify the type using the @Database annotation.

// @Database(DatabaseType.DOCUMENT) for Document databases
// @Database(DatabaseType.COLUMN) for Column databases
// @Database(DatabaseType.GRAPH) for Graph databases
// @Database(DatabaseType.KEY_VALUE) for Key-Value databases
// @Database(DatabaseType.TIME_SERIES) for Time-Series databases
protected Template template;

public void insert(TestEntity entity) {
    template.insert(entity);
}

More information about the jakarta.nosql.Template usage can be found in the Jakarta NoSQL Specification.

Using Jakarta Data Repository

For implementations that offer Jakarta Data support, you may create and inject a Jakarta Data Repository:

@Repository
public interface TestEntityRepository extends NoSQLRepository<TestEntity, String> {
}

Jakarta Data repositories provide a powerful way to interact with your NoSQL database using a repository pattern.

The interface org.eclipse.jnosql.mapping.NoSQLRepository used above extends the jakarta.data.repository.BasicRepository, which is a Jakarta Data Repository interface that brings a specialization for NoSQL useful operations, allowing developers to use pre-defined methods. Also,you can define custom queries using method names or annotations, and the framework will handle the implementation for you. More information about Jakarta Data can be found in the Jakarta Data Specification.

Using the Jakarta Data Repositories or Jakarta NoSQL Templates in your service

@ApplicationScope
class TestEntityService {

    @Inject
    // If your NoSQL database supports multiple types,
    // you can specify the type using the @Database annotation.

    // @Database(DatabaseType.DOCUMENT) for Document databases
    // @Database(DatabaseType.COLUMN) for Column databases
    // @Database(DatabaseType.GRAPH) for Graph databases
    // @Database(DatabaseType.KEY_VALUE) for Key-Value databases
    // @Database(DatabaseType.TIME_SERIES) for Time-Series databases
    Template template;

    @Inject
    // If your NoSQL database supports multiple types,
    // you can specify the type using the @Database annotation.

    // @Database(DatabaseType.DOCUMENT) for Document databases
    // @Database(DatabaseType.COLUMN) for Column databases
    // @Database(DatabaseType.GRAPH) for Graph databases
    // @Database(DatabaseType.KEY_VALUE) for Key-Value databases
    // @Database(DatabaseType.TIME_SERIES) for Time-Series databases
    TestEntityRepository repository;

    public void insertViaRepository(TestEntity entity) {
        repository.save(entity);
    }

    public void insertViaTemplate(TestEntity entity) {
        template.insert(entity);
    }

}

Now, you can use the TestEntityService to perform CRUD operations on your TestEntity objects using the repository.

That’s it! You have successfully set up a Quarkus application with the Quarkus JNoSQL Extension, allowing you to interact with your NoSQL database using Jakarta NoSQL and Jakarta Data.

Next, we provide more instructions for each supported database.

Document Databases

MongoDB

MongoDB Project

MongoDB is a free and open-source cross-platform document-oriented database program.

This driver provides support for the Document NoSQL API and Jakarta Data.

To create a Quarkus project with this extension, you can use the Quarkus CLI:

quarkus create app --extensions=jnosql-mongodb

To add this extension with the Quarkus CLI to an existing project:

quarkus create app --extensions=jnosql-mongodb

Or add it manually to your pom.xml:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-mongodb</artifactId>
    <version>3.8.0</version>
</dependency>

Set the database name in application.properties:

jnosql.document.database=my-database-name

If you are using Java 21 or above, make sure to enable the annotation processor execution. If you are using Java 17 or below, you can skip this step and go ahead to implement your entities and repositories.

Do you want to get started to create your entities and repositories? See the section Using Jakarta NoSQL and Jakarta Data with Quarkus JNoSQL.

More details: JNoSQL MongoDB Database Driver.

CouchDB

CouchDB

CouchDB provides an API integration between Java and the database.

Supports the Document NoSQL API and Jakarta Data.

To create a Quarkus project with this extension, you can use the Quarkus CLI:

quarkus create app --extensions=jnosql-couchdb

To add this extension with the Quarkus CLI to an existing project:

quarkus create app --extensions=jnosql-couchdb

Or add it manually to your pom.xml:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-couchdb</artifactId>
    <version>3.8.0</version>
</dependency>

Set the database name in application.properties:

jnosql.document.database=my-database-name

If you are using Java 21 or above, make sure to enable the annotation processor execution. If you are using Java 17 or below, you can skip this step and go ahead to implement your entities and repositories.

Do you want to get started to create your entities and repositories? See the section Using Jakarta NoSQL and Jakarta Data with Quarkus JNoSQL.

More details about JNoSQL CouchDB Database driver.

Elasticsearch

Elasticsearch Project

Elasticsearch is a search engine based on Lucene.

Supports the Document NoSQL API and Jakarta Data.

Does not support native compilation.

To create a Quarkus project with this extension, you can use the Quarkus CLI:

quarkus create app --extensions=jnosql-elasticsearch

To add this extension with the Quarkus CLI to an existing project:

quarkus create app --extensions=jnosql-elasticsearch

Or add it manually to your pom.xml:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-elasticsearch</artifactId>
    <version>3.8.0</version>
</dependency>

Set the database name in application.properties:

jnosql.document.database=my-database-name

If you are using Java 21 or above, make sure to enable the annotation processor execution. If you are using Java 17 or below, you can skip this step and go ahead to implement your entities and repositories.

Do you want to get started to create your entities and repositories? See the section Using Jakarta NoSQL and Jakarta Data with Quarkus JNoSQL.

More details about the Elasticsearch Client Quarkus extension.

More details about JNoSQL Elasticsearch Database driver.

Solr

Apache Solr Project

Solr is an open-source enterprise-search platform.

Supports the Document NoSQL API and Jakarta Data.

To create a Quarkus project with this extension, you can use the Quarkus CLI:

quarkus create app --extensions=jnosql-solr

To add this extension with the Quarkus CLI to an existing project:

quarkus create app --extensions=jnosql-solr

Or add it manually to your pom.xml:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-solr</artifactId>
    <version>3.8.0</version>
</dependency>

Set the database name in application.properties:

jnosql.document.database=my-database-name

If you are using Java 21 or above, make sure to enable the annotation processor execution. If you are using Java 17 or below, you can skip this step and go ahead to implement your entities and repositories.

Do you want to get started to create your entities and repositories? See the section Using Jakarta NoSQL and Jakarta Data with Quarkus JNoSQL.

More details about JNoSQL Solr Database driver.

Column Databases

Cassandra

Apache Cassandra Project

Apache Cassandra is a distributed database management system.

Supports the Column NoSQL API and Jakarta Data.

To create a Quarkus project with this extension, you can use the Quarkus CLI:

quarkus create app --extensions=jnosql-cassandra

To add this extension with the Quarkus CLI to an existing project:

quarkus create app --extensions=jnosql-cassandra

Or add it manually to your pom.xml:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-cassandra</artifactId>
    <version>3.8.0</version>
</dependency>

Set the database name in application.properties:

jnosql.column.database=my-database-name

If you are using Java 21 or above, make sure to enable the annotation processor execution. If you are using Java 17 or below, you can skip this step and go ahead to implement your entities and repositories.

Do you want to get started to create your entities and repositories? See the section Using Jakarta NoSQL and Jakarta Data with Quarkus JNoSQL.

More details: JNoSQL Cassandra Database Driver.

ScyllaDB

ScyllaDB supports the Column API, Jakarta NoSQL Template, and generated Jakarta Data repositories for POJOs and records.

quarkus create app --extensions=jnosql-scylladb

Or add the extension to pom.xml:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-scylladb</artifactId>
    <version>3.8.0</version>
</dependency>

This extension uses org.eclipse.jnosql.databases:jnosql-scylladb at the project’s managed JNoSQL version, currently 1.1.19, with the native ScyllaDB artifacts com.scylladb:java-driver-core and com.scylladb:java-driver-query-builder:4.19.2.1. It does not use the Cassandra Quarkus client. The ScyllaDB client retains com.datastax.oss.driver package names; do not combine it with the Cassandra extension/client because the client classes overlap.

Configure the keyspace and connection in application.properties:

jnosql.column.database=developers
jnosql.scylladb.host.1=localhost
jnosql.scylladb.port=9042
jnosql.scylladb.data.center=datacenter1

Additional contact points use jnosql.scylladb.host.2, .3, and so on, with one shared port. The port defaults to 9042 and the local data center to datacenter1; select the data center that matches your cluster. Optional driver properties are jnosql.scylladb.name (application name), jnosql.scylladb.user, and jnosql.scylladb.password.

Provision keyspaces and tables before use; mapping does not create them. The driver’s jnosql.scylladb.query.* settings can execute startup CQL, sorted lexicographically by key:

jnosql.scylladb.query.000=CREATE KEYSPACE IF NOT EXISTS developers WITH replication = {'class': 'NetworkTopologyStrategy', 'replication_factor': 1};
jnosql.scylladb.query.001=CREATE TABLE IF NOT EXISTS developers.developer ("_id" text PRIMARY KEY, name text, language text);

This replication example is for single-node development, not production sizing. Enable the mapping-lite annotation processor for standard entities and Jakarta Data repositories. See Using Jakarta NoSQL and Jakarta Data. The driver’s separate portable-CDI-extension repository API is not part of this support.

CDI shares one configured factory and one Column manager/session. The extension closes the managed session on shutdown and delegates connection, serialization, queries and retries to the existing driver. Low-level access is available by injecting ScyllaDBColumnManager with @Database(DatabaseType.COLUMN). Callers creating additional managers through ScyllaDBColumnManagerFactory.apply(keyspace) must close those managers themselves.

The Java codestart and integration tests use a real scylladb/scylla:2026.3.1 container, matching the upstream JNoSQL 1.1.19 tests. They use one shard, 1 GB of memory, and dynamic Testcontainers host/CQL-port mappings. Docker is required.

Native compilation and Column, Template and repository CRUD have been verified with Mandrel 25.0.4.1 in a Linux container. The extension relies on the ScyllaDB client’s bundled native metadata and defers MetadataManager initialization to avoid capturing its default contact point at build time. No Cassandra-specific native configuration is copied.

Key-Value Databases

Jakarta Data BasicRepository Support for Key-Value Databases

Eclipse JNoSQL supports basic Jakarta Data repository operations for key-value databases. A repository interface can simply extend BasicRepository without declaring any additional method:

import jakarta.data.repository.BasicRepository;
import jakarta.data.repository.Repository;

@Repository
public interface PersonRepository
        extends BasicRepository<Person, String> {
}

The inherited methods are available through CDI:

@Inject
PersonRepository repository;

repository.save(person);

Optional<Person> result = repository.findById(id);

boolean exists = repository.findById(id).isPresent();

repository.deleteById(id);

The behavior below was verified with integration tests against DynamoDB, Hazelcast, Infinispan, Memcached, Redis and Valkey, using Jakarta Data 1.0.1 and Eclipse JNoSQL 1.2.0.

BasicRepository method Behavior

save(entity)

✅ Inserts the entity, or updates it when the identifier already exists.

saveAll(entities)

✅ Saves each entity by identifier.

findById(id)

✅ Returns an Optional, empty when the key does not exist.

deleteById(id)

✅ Removes the entry; deleting an unknown key is a no-op.

delete(entity)

✅ Removes the entry using the entity identifier.

deleteAll(entities)

✅ Removes the entry of each given entity.

findAll()

❌ Throws UnsupportedOperationException.

findAll(PageRequest, Order)

❌ Throws UnsupportedOperationException.

Jakarta Data 1.0.1 BasicRepository does not declare existsById; to check whether a key exists, use findById(id).isPresent().

Limitations

  • Key-value access is centered on entity identifiers.

  • Extending BasicRepository does not guarantee that every inherited operation is implemented by every key-value provider.

  • Arbitrary derived queries against non-key attributes are outside the documented key-value repository capabilities, and Jakarta Data’s general query capabilities should not be assumed for key-value databases.

  • Unsupported inherited operations retain their existing failure behavior (UnsupportedOperationException).

  • DynamoDB exposes more than one database type, so injecting the repository requires the @Database(DatabaseType.KEY_VALUE) qualifier.

See also the Jakarta NoSQL and Eclipse JNoSQL documentation.

DynamoDB

70553550 f033b980 1b40 11ea 9192 759b3b1053b3

Amazon DynamoDB is a fully managed, serverless, key-value and document NoSQL database.

Supports Key-Value.

See Jakarta Data BasicRepository Support for Key-Value Databases for the supported repository operations.

To create a Quarkus project with this extension, you can use the Quarkus CLI:

quarkus create app --extensions=jnosql-dynamodb

To add this extension with the Quarkus CLI to an existing project:

quarkus create app --extensions=jnosql-dynamodb

Or add it manually to your pom.xml:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-dynamodb</artifactId>
    <version>3.8.0</version>
</dependency>

Set the database name in application.properties:

jnosql.keyvalue.database=my-database-name

If you are using Java 21 or above, make sure to enable the annotation processor execution. If you are using Java 17 or below, you can skip this step and go ahead to implement your entities and repositories.

Do you want to get started to create your entities and repositories? See the section Using Jakarta NoSQL and Jakarta Data with Quarkus JNoSQL.

See more details about DynamoDB Quarkiverse extension.

More details about JNoSQL DynamoDB Database driver.

Hazelcast

Hazelcast Project

Hazelcast is an open source in-memory data grid.

Supports Key-Value.

See Jakarta Data BasicRepository Support for Key-Value Databases for the supported repository operations.

To create a Quarkus project with this extension, you can use the Quarkus CLI:

quarkus create app --extensions=jnosql-hazelcast

To add this extension with the Quarkus CLI to an existing project:

quarkus create app --extensions=jnosql-hazelcast

Or add it manually to your pom.xml:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-hazelcast</artifactId>
    <version>3.8.0</version>
</dependency>

Set the database name in application.properties:

jnosql.keyvalue.database=my-database-name

If you are using Java 21 or above, make sure to enable the annotation processor execution. If you are using Java 17 or below, you can skip this step and go ahead to implement your entities and repositories.

Do you want to get started to create your entities and repositories? See the section Using Jakarta NoSQL and Jakarta Data with Quarkus JNoSQL.

More details about Quarkus Hazelcast extension.

More details about JNoSQL Hazelcast Database driver.

Redis

Redis Project

Redis is an open source, in-memory data structure store used as a database, cache, and message broker.

Supports Key-Value.

See Jakarta Data BasicRepository Support for Key-Value Databases for the supported repository operations.

The extension uses the Jedis-based JNoSQL Redis driver directly, sharing a single connection pool across the whole application.

To create a Quarkus project with this extension, you can use the Quarkus CLI:

quarkus create app --extensions=jnosql-redis

To add this extension with the Quarkus CLI to an existing project:

quarkus create app --extensions=jnosql-redis

Or add it manually to your pom.xml:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-redis</artifactId>
    <version>3.8.0</version>
</dependency>

Set the database name in application.properties:

jnosql.keyvalue.database=my-database-name

The connection and the connection pool can be configured through the jnosql.redis.* properties, for example:

jnosql.redis.host=localhost
jnosql.redis.port=6379
jnosql.redis.max.total=50

If you are using Java 21 or above, make sure to enable the annotation processor execution. If you are using Java 17 or below, you can skip this step and go ahead to implement your entities and repositories.

Do you want to get started to create your entities and repositories? See the section Using Jakarta NoSQL and Jakarta Data with Quarkus JNoSQL.

More details about JNoSQL Redis Database driver.

Infinispan

Infinispan supports the Key-Value API through org.eclipse.jnosql.databases:jnosql-infinispan. The extension provides CDI injection of BucketManager, BucketManagerFactory, and Jakarta NoSQL Template, including POJO and record mapping.

See Jakarta Data BasicRepository Support for Key-Value Databases for the supported repository operations.

quarkus create app --extensions=jnosql-infinispan

Or add the dependency to an existing project:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-infinispan</artifactId>
    <version>3.8.0</version>
</dependency>

For an embedded, local cache, configure application.properties:

jnosql.keyvalue.database=people
jnosql.infinispan.config=infinispan.xml

Create src/main/resources/infinispan.xml with a cache matching the database name:

<infinispan xmlns="urn:infinispan:config:16.0">
    <cache-container name="jnosql">
        <local-cache name="people"/>
    </cache-container>
</infinispan>

The codestart includes this configuration and runs without a server or Docker. Infinispan searches the classpath first, then the filesystem. An absolute path such as jnosql.infinispan.config=/etc/my-app/infinispan.xml selects an external file. Missing or invalid XML fails rather than falling back to a default cache. XML parsing, cache creation, serialization, and mapping remain the responsibility of Infinispan and JNoSQL.

The property corresponds to the driver’s configuration API:

Settings settings = Settings.builder()
        .put(InfinispanConfigurations.CONFIG, "infinispan.xml")
        .build();

Settings is org.eclipse.jnosql.communication.Settings; InfinispanConfigurations is org.eclipse.jnosql.databases.infinispan.communication.InfinispanConfigurations. In Quarkus, prefer configuring properties and injecting the manager or template to creating another factory.

The driver’s jnosql.infinispan.host. or generic jnosql.host. properties select Hot Rod and take precedence over XML. Leave them unset for embedded XML mode. Without hosts or XML, the driver creates its default embedded container without defining application caches. Remote mode is delegated unchanged to JNoSQL but is not covered by the local-cache tests.

The extension uses org.infinispan:infinispan-bom:16.3.0, aligning core, commons, Hot Rod, and counter API at 16.3.1 and ProtoStream at 6.0.12. Updating only core while Quarkus still manages commons at 16.0.15 causes NoClassDefFoundError: MemoryMonitor.

For existing applications, import this BOM before the Quarkus BOM inside your application’s dependencyManagement:

<dependency>
    <groupId>org.infinispan</groupId>
    <artifactId>infinispan-bom</artifactId>
    <version>16.3.0</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

Application dependency management overrides transitive extension dependencies. The codestart includes explicit overrides because Quarkus’s POM merger places its BOM first. When upgrading, keep the codestart’s ProtoStream version aligned with the Infinispan BOM. Micrometer core is included for native linking of the 16.2 metrics factory’s API references; this does not install a Prometheus registry or enable metrics collection.

The driver’s obsolete shaded infinispan-embedded 9.x dependency is excluded. The extension shares one driver factory and delegates shutdown to its close() method.

In JNoSQL 1.1.19, InfinispanBucketManagerFactory.close() is a no-op. Embedded container shutdown and cleanup during dev-mode reloads remain upstream limitations. Native local-XML cache read/write, POJO/record mapping, and concurrent operations have been exercised with Mandrel 25.0.4.1. Remote and clustered native configurations remain unverified.

More details about the JNoSQL Infinispan driver.

Memcached

Memcached is an in-memory, cache-oriented Key-Value store. The extension uses org.eclipse.jnosql.databases:jnosql-memcached and the existing JNoSQL BucketManager and Jakarta NoSQL Template programming model.

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-memcached</artifactId>
    <version>3.8.0</version>
</dependency>

A Java codestart is provided:

quarkus create app --extensions=jnosql-memcached

Configure a logical bucket name and the numbered host list in application.properties:

jnosql.keyvalue.database=people
jnosql.memcached.host.1=localhost:11211

Additional servers use jnosql.memcached.host.2, .3, and so on, each with a host:port value. These are the host-prefix entries read by the JNoSQL driver’s MemcachedConfigurations.HOST. The bucket name namespaces keys; it does not create a durable database. The codestart tests use memcached:latest, port 11211, and Testcontainers' default wait strategy, overriding the host entry with the container’s dynamically mapped address.

The driver’s default object serialization requires stored entities to implement java.io.Serializable. The extension adapts the client’s deserialization class lookup to Quarkus’s application class loader; the driver’s serialization format is unchanged. Use key-based store, retrieve, and delete operations; do not assume durable persistence, queries, ordering, secondary indexes, or transactions. Only key-based BasicRepository operations are supported; see Jakarta Data BasicRepository Support for Key-Value Databases.

Native compilation and entity CRUD through Template and BucketManager have been verified with Mandrel 25.0.4.1 in a Linux container. The extension includes spymemcached’s optional com.codahale.metrics:metrics-core:3.0.1 dependency for native linking and initializes its random-seed holder at runtime.

The extension registers entity hierarchies, String, and ArrayList for native Java serialization. Additional concrete types stored through BucketManager, or used in polymorphic fields and other collection implementations, may require explicit @RegisterForReflection(serialization = true, targets = {…​}) registration.

In JNoSQL 1.1.18, the Memcached factory’s close() is a no-op. The extension shares one factory and delegates shutdown to the driver, but the driver does not shut down its client. This can retain client threads across application reloads.

For entity mapping, enable the JNoSQL Mapping Lite annotation processor.

Valkey

Valkey is an open source, in-memory data structure store used as a database, cache, and message broker. It is wire-compatible with Redis.

Supports Key-Value.

See Jakarta Data BasicRepository Support for Key-Value Databases for the supported repository operations.

The extension uses the JNoSQL Valkey driver directly, sharing a single connection pool across the whole application.

To create a Quarkus project with this extension, you can use the Quarkus CLI:

quarkus create app --extensions=jnosql-valkey

To add this extension with the Quarkus CLI to an existing project:

quarkus create app --extensions=jnosql-valkey

Or add it manually to your pom.xml:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-valkey</artifactId>
    <version>3.8.0</version>
</dependency>

Set the database name in application.properties:

jnosql.keyvalue.database=my-database-name

The connection and the connection pool can be configured through the jnosql.valkey.* properties, for example:

jnosql.valkey.host=localhost
jnosql.valkey.port=6379
jnosql.valkey.max.total=50

If you are using Java 21 or above, make sure to enable the annotation processor execution. If you are using Java 17 or below, you can skip this step and go ahead to implement your entities and repositories.

Do you want to get started to create your entities and repositories? See the section Using Jakarta NoSQL and Jakarta Data with Quarkus JNoSQL.

More details about JNoSQL Valkey Database driver.

Graph Databases

Neo4j

Neo4J Project

Neo4J is a highly scalable, native graph database.

Supports Graph operations and Jakarta Data.

To create a Quarkus project with this extension, you can use the Quarkus CLI:

quarkus create app --extensions=jnosql-neo4j

To add this extension with the Quarkus CLI to an existing project:

quarkus create app --extensions=jnosql-neo4j

Or add it manually to your pom.xml:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-neo4j</artifactId>
    <version>3.8.0</version>
</dependency>

Set the database name in application.properties:

jnosql.graph.database=my-database-name

If you are using Java 21 or above, make sure to enable the annotation processor execution. If you are using Java 17 or below, you can skip this step and go ahead to implement your entities and repositories.

Example using GraphTemplate:

@Inject
@Database(DatabaseType.GRAPH)
protected GraphTemplate template;

public void insert(TestEntity entity) {
    template.insert(entity);
}

Do you want to get started to create your entities and repositories? See the section Using Jakarta NoSQL and Jakarta Data with Quarkus JNoSQL.

More details about the Quarkus Neo4j extension.

More details about JNoSQL Neo4j Database driver.

Apache TinkerPop

Apache TinkerPop provides a common graph API (org.apache.tinkerpop.gremlin.structure.Graph) implemented by multiple graph database providers.

The Quarkus JNoSQL TinkerPop extension integrates Eclipse JNoSQL with Apache TinkerPop through CDI. Applications provide their own Graph implementation, allowing the same integration to work with different TinkerPop-compatible databases.

More details: Apache TinkerPop documentation and Eclipse JNoSQL.

Add the extension:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-tinkerpop</artifactId>
    <version>3.8.0</version>
</dependency>

The extension has no dependency on any graph database. Add the dependency of the TinkerPop provider you chose; for example, the ArangoDB provider:

<dependency>
    <groupId>com.arangodb</groupId>
    <artifactId>arangodb-tinkerpop-provider</artifactId>
    <version>4.0.0</version>
</dependency>

Providing the Graph

The application owns the Graph: it chooses the provider, creates and configures the instance, manages credentials and closes it. The extension only consumes a CDI Graph bean and never creates, replaces or closes one.

@ApplicationScoped
public class GraphProducer {

    @ConfigProperty(name = "app.arangodb.hosts")
    String hosts;

    @Produces
    @ApplicationScoped
    public Graph graph() {
        Configuration configuration = new BaseConfiguration();
        configuration.setProperty("gremlin.graph", "ArangoDBGraph");
        configuration.setProperty("gremlin.arangodb.conf.graph.enableDataDefinition", true);
        configuration.setProperty("gremlin.arangodb.conf.graph.type", "COMPLEX");
        configuration.setProperty("gremlin.arangodb.conf.graph.edgeDefinitions", "knows:[Person]->[Person]");
        configuration.setProperty("gremlin.arangodb.conf.driver.hosts", hosts);
        return GraphFactory.open(configuration);
    }

    public void dispose(@Disposes Graph graph) throws Exception {
        graph.close();
    }
}

If no Graph bean with the default qualifiers exists, the build fails with a message asking for a CDI producer of org.apache.tinkerpop.gremlin.structure.Graph. There is no fallback graph.

Template and repositories

@ApplicationScoped
public class PersonService {

    @Inject
    TinkerpopTemplate template;

    @Inject
    PersonRepository repository;
}

Repositories are the driver’s own TinkerPopRepository interfaces (no @Repository annotation), which the extension registers as CDI beans:

public interface PersonRepository extends TinkerPopRepository<Person, String> {
    List<Person> findByName(String name);
}

Jakarta Data repositories

Jakarta Data repositories are also supported and use the same application-owned Graph:

@Repository
public interface PersonDataRepository extends BasicRepository<Person, String> {

    List<Person> findByName(String name);
}

Validation and limitations

  • The integration is tested against a single real database, ArangoDB (arangodb:3.12.13 via Testcontainers, with arangodb-tinkerpop-provider 4.0.0). The tests cover injection of the application Graph and TinkerpopTemplate, reading entities, creating edges, traversals, repository queries and the missing-Graph failure. Compatibility with other TinkerPop providers follows from the TinkerPop API but has not been tested here.

  • With the ArangoDB provider, TinkerpopTemplate.insert and TinkerPopRepository.save fail because the JNoSQL driver writes the _id property, which that provider reserves. The tests therefore create vertices through the application’s Graph and read them back through JNoSQL. This is a driver/provider interaction, not a limitation of the extension.

  • Jakarta Data @Repository interfaces are verified against ArangoDB through the application’s Graph: derived queries such as findByName work. Id-based operations (findById, deleteById, save) rely on the _id property written by the JNoSQL driver, which the ArangoDB provider reserves, so they are not covered by the tests with that provider.

  • Native compilation depends on the chosen TinkerPop provider: the extension registers the repository proxies and reflection it needs, but the provider itself must also support native image.

Time Series Databases

The Time Series extensions expose TimeSeriesTemplate and Jakarta Data repositories generated by the JNoSQL Lite processor for DatabaseType.TIME_SERIES. A repository is declared and injected like this (see the JNoSQL Time Series documentation):

@Repository
public interface Metrics extends NoSQLRepository<Metric, Instant> {
}

@Inject
@Database(DatabaseType.TIME_SERIES)
Metrics metrics;

Repository behavior verified by the integration tests differs per provider: insert, findById and derived queries work on all three; update is rejected by InfluxDB and IoTDB and is a no-op on QuestDB; deleteById works on IoTDB and is rejected by InfluxDB and QuestDB. QuestDB ingestion is asynchronous, so a row may take a moment to become queryable.

InfluxDB

InfluxDB is a database optimized for time-series data.

This driver provides support for the Eclipse JNoSQL Time Series Mapping API and Jakarta Data.

To create a Quarkus project with this extension, you can use the Quarkus CLI:

quarkus create app --extensions=jnosql-influxdb

Or add it manually to your pom.xml:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-influxdb</artifactId>
    <version>3.8.0</version>
</dependency>

Configure the database, URL, and token in application.properties:

jnosql.timeseries.database=metrics
jnosql.influxdb.url=http://localhost:8181
jnosql.influxdb.token=jnosql-influxdb-test-token

Inject TimeSeriesTemplate, or define a Jakarta Data repository for a time-series entity.

If you are using Java 21 or above, make sure to enable the annotation processor execution. If you are using Java 17 or below, you can skip this step and go ahead to implement your entities and repositories.

More details: JNoSQL InfluxDB Database Driver.

Apache IoTDB

Apache IoTDB is a time-series database designed for IoT and industrial data scenarios.

This driver provides support for the Eclipse JNoSQL Time Series Mapping API and Jakarta Data.

To add this extension to an existing Quarkus project:

quarkus extension add jnosql-iotdb

Or add it manually to your pom.xml:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-iotdb</artifactId>
    <version>3.8.0</version>
</dependency>

Configure the database and IoTDB connection in application.properties:

jnosql.timeseries.database=jnosql
jnosql.iotdb.host=localhost
jnosql.iotdb.port=6667
jnosql.iotdb.username=root
jnosql.iotdb.password=root
jnosql.iotdb.enable.redirection=false

If you are using Java 21 or above, make sure to enable the annotation processor execution. If you are using Java 17 or below, you can skip this step and go ahead to implement your entities and repositories.

More details: JNoSQL Apache IoTDB Database Driver.

QuestDB

QuestDB is a high-performance time-series database designed for fast ingestion and SQL analytics over time-oriented data.

This driver provides support for the Eclipse JNoSQL Time Series Mapping API and Jakarta Data.

To add this extension to an existing Quarkus project:

quarkus extension add jnosql-questdb

Or add it manually to your pom.xml:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-questdb</artifactId>
    <version>3.8.0</version>
</dependency>

Configure the database and QuestDB connection in application.properties:

jnosql.timeseries.database=qdb
jnosql.questdb.url=ws::addr=localhost:9000;

If you are using Java 21 or above, make sure to enable the annotation processor execution. If you are using Java 17 or below, you can skip this step and go ahead to implement your entities and repositories.

More details: JNoSQL QuestDB Database Driver.

Vector Databases

The Vector extensions integrate the Eclipse JNoSQL Vector Mapping API (VectorTemplate, VectorManager) and share the quarkus-jnosql-vector module, so each one only adds its own driver and configuration. They can currently be added manually to an existing Quarkus project.

Select the database name, and optionally the provider, in application.properties. The provider is only required when more than one JNoSQL provider is on the classpath:

jnosql.vector.database=articles
jnosql.vector.provider=org.eclipse.jnosql.databases.qdrant.communication.QdrantConfiguration

Entities need a DenseVector field and, with the Lite annotation processor, a setter for each mapped field:

@Entity
public class Article {

    @Id
    private String id;

    @Column
    private String title;

    @Column
    private DenseVector embedding;

    // getters and setters
}

Inject the template to persist entities and to search by similarity:

@Inject
@Database(DatabaseType.VECTOR)
VectorTemplate template;

template.insert(new Article("1", "Quarkus", DenseVector.of(1f, 0f, 0f, 0f)));

Optional<Article> article = template.find(Article.class, "1");

List<Article> similar = template.search(Article.class)
        .vector(DenseVector.of(1f, 0f, 0f, 0f))
        .where("title").eq("Quarkus")
        .limit(Limit.of(5))
        .result();

Jakarta Data repositories are generated by the JNoSQL Lite processor for the VECTOR database type, so the same repository works with every Vector extension:

@Repository
public interface ArticleRepository extends BasicRepository<Article, String> {

    List<Article> findByCategory(String category);
}

@Inject
ArticleRepository repository;

The integration tests verify save (insert and update), findById, deleteById and a derived findByCategory query against each database. See the JNoSQL and Jakarta Data documentation for the repository API. With more than one Vector provider on the classpath, the provider must be chosen with jnosql.vector.provider.

Only DenseVector is exercised by the integration tests of these extensions (other representations depend on each driver). Native compilation has not been verified. Each extension provides a codestart (quarkus create app --extensions=jnosql-qdrant, jnosql-milvus or jnosql-weaviate) with an Article entity, an ArticleRepository and a test that starts the database with Testcontainers.

Qdrant

Qdrant is an open-source vector database. The extension connects through gRPC.

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-qdrant</artifactId>
    <version>3.8.0</version>
</dependency>
jnosql.qdrant.host=localhost
jnosql.qdrant.port=6334
jnosql.qdrant.collection.distance=COSINE
jnosql.qdrant.collection.vector.size=4
# optional: jnosql.qdrant.api.key, jnosql.qdrant.tls, jnosql.qdrant.timeout (milliseconds)

The collection (named after the entity) is created on the first insert when a distance is configured. Supported distances: COSINE, EUCLID, DOT, MANHATTAN. Entities may have a single vector, and TTL on save is not supported.

Milvus

Milvus is an open-source vector database.

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-milvus</artifactId>
    <version>3.8.0</version>
</dependency>
jnosql.milvus.host=localhost
jnosql.milvus.port=19530
jnosql.milvus.collection.metric=COSINE
jnosql.milvus.collection.vector.size=4
# optional: jnosql.milvus.uri, jnosql.milvus.token, jnosql.milvus.tls, jnosql.milvus.timeout,
# jnosql.milvus.consistency, jnosql.milvus.collection.string.max.length

Supported metrics: COSINE, EUCLIDEAN, INNER_PRODUCT. The integration tests use the milvusdb/milvus:v3.0.4 image, which needs DEPLOY_MODE=STANDALONE to run with the embedded etcd.

Weaviate

Weaviate is an open-source vector database. The client uses both HTTP and gRPC, so both ports must be reachable.

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-weaviate</artifactId>
    <version>3.8.0</version>
</dependency>
jnosql.weaviate.host=localhost
jnosql.weaviate.http.port=8080
jnosql.weaviate.grpc.port=50051
jnosql.weaviate.collection.distance=COSINE
# optional: jnosql.weaviate.api.key, jnosql.weaviate.secure, jnosql.weaviate.timeout

Supported distances: COSINE, DOT, EUCLIDEAN, MANHATTAN, HAMMING.

More details: JNoSQL Database Drivers.

Multi-model Databases

ArangoDB

ArangoDB Project

ArangoDB is a native multi-model database.

Supports Document and Key-Value types, and Jakarta Data for Document entities.

To create a Quarkus project with this extension, you can use the Quarkus CLI:

quarkus create app --extensions=jnosql-arangodb

To add this extension with the Quarkus CLI to an existing project:

quarkus create app --extensions=jnosql-arangodb

Or add it manually to your pom.xml:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-arangodb</artifactId>
    <version>3.8.0</version>
</dependency>

Set the database name in application.properties:

For the Key-Value database:

jnosql.keyvalue.database=my-database-name

For the Document database name:

jnosql.document.database=my-database-name

If you are using Java 21 or above, make sure to enable the annotation processor execution. If you are using Java 17 or below, you can skip this step and go ahead to implement your entities and repositories.

Do you want to get started to create your entities and repositories? See the section Using Jakarta NoSQL and Jakarta Data with Quarkus JNoSQL.

More details: Using ArangoDB JNoSQL driver.

Oracle NoSQL

Oracle NoSQL Project

Oracle NoSQL Database is a multi-model database.

Supports Document and Key-Value types and Jakarta Data.

To create a Quarkus project with this extension, you can use the Quarkus CLI:

quarkus create app --extensions=jnosql-oracle-nosql

To add this extension with the Quarkus CLI to an existing project:

quarkus create app --extensions=jnosql-oracle-nosql

Or add it manually to your pom.xml:

<dependency>
    <groupId>io.quarkiverse.jnosql</groupId>
    <artifactId>quarkus-jnosql-oracle-nosql</artifactId>
    <version>3.8.0</version>
</dependency>

Set the database name in application.properties:

  • For Document database:

    jnosql.document.database=my-database-name

  • For Key-Value database:

    jnosql.keyvalue.database=my-database-name

If you are using Java 21 or above, make sure to enable the annotation processor execution. If you are using Java 17 or below, you can skip this step and go ahead to implement your entities and repositories.

Do you want to get started to create your entities and repositories? See the section Using Jakarta NoSQL and Jakarta Data with Quarkus JNoSQL.

More details about JNoSQL Oracle NoSQL Database driver.