Chapter 1. Configure data sources
Use a unified configuration model to define data sources for Java Database Connectivity (JDBC) and Reactive drivers in Quarkus.
Applications use datasources to access relational databases. Quarkus provides a unified configuration model to define datasources for Java Database Connectivity (JDBC) and Reactive database drivers.
Quarkus uses Agroal and Vert.x to provide high-performance, scalable data source connection pooling for JDBC and reactive drivers. The jdbc-*
and reactive-*
extensions provide build time optimizations and integrate configured data sources with Quarkus features like security, health checks, and metrics.
For more information about consuming and using a reactive datasource, see the Quarkus Reactive SQL clients guide.
Additionally, refer to the Quarkus Hibernate ORM guide for information on consuming and using a JDBC datasource.
1.1. Get started with configuring datasources
in Quarkus
For users familiar with the fundamentals, this section provides an overview and code samples to set up data sources quickly.
For more advanced configuration with examples, see References.
1.1.1. Zero-config setup in development mode
Quarkus simplifies database configuration by offering the Dev Services feature, enabling zero-config database setup for testing or running in development (dev) mode. In dev mode, the suggested approach is to use DevServices and let Quarkus handle the database for you, whereas for production mode, you provide explicit database configuration details pointing to a database managed outside of Quarkus.
To use Dev Services, add the appropriate driver extension, such as jdbc-postgresql
, for your desired database type to the pom.xml
file. In dev mode, if you do not provide any explicit database connection details, Quarkus automatically handles the database setup and provides the wiring between the application and the database.
If you provide user credentials, the underlying database will be configured to use them. This is useful if you want to connect to the database with an external tool.
To use this feature, ensure a Docker or Podman container runtime is installed, depending on the database type. Certain databases, such as H2, operate in in-memory mode and do not require a container runtime.
Prefix the actual connection details for prod mode with %prod.
to ensure they are not applied in dev mode. For more information, see the Profiles section of the "Configuration reference" guide.
For more information about Dev Services, see Dev Services overview.
For more details and optional configurations, see Dev Services for databases.
1.1.2. Configure a JDBC datasource
Add the correct JDBC extension for the database of your choice.
-
jdbc-db2
-
jdbc-derby
-
jdbc-h2
-
jdbc-mariadb
-
jdbc-mssql
-
jdbc-mysql
-
jdbc-oracle
-
jdbc-postgresql
-
Configure your JDBC datasource:
quarkus.datasource.db-kind=postgresql 1 quarkus.datasource.username=<your username> quarkus.datasource.password=<your password> quarkus.datasource.jdbc.url=jdbc:postgresql://localhost:5432/hibernate_orm_test quarkus.datasource.jdbc.max-size=16
- 1
- This configuration value is only required if there is more than one database extension on the classpath.
If only one viable extension is available, Quarkus assumes this is the correct one. When you add a driver to the test scope, Quarkus automatically includes the specified driver in testing.
1.1.2.1. JDBC connection pool size adjustment
To protect your database from overloading during load peaks, size the pool adequately to throttle the database load. The optimal pool size depends on many factors, such as the number of parallel application users or the nature of the workload.
Be aware that setting the pool size too low might cause some requests to time out while waiting for a connection.
For more information about pool size adjustment properties, see the JDBC configuration reference section.
1.1.3. Configure a reactive datasource
Add the correct reactive extension for the database of your choice.
-
reactive-db2-client
-
reactive-mssql-client
-
reactive-mysql-client
-
reactive-oracle-client
-
reactive-pg-client
-
Configure your reactive datasource:
quarkus.datasource.db-kind=postgresql 1 quarkus.datasource.username=<your username> quarkus.datasource.password=<your password> quarkus.datasource.reactive.url=postgresql:///your_database quarkus.datasource.reactive.max-size=20
- 1
- This configuration value is only required if there is more than one Reactive driver extension on the classpath.
1.2. Configure datasources
The following section describes the configuration for single or multiple datasources. For simplicity, we will reference a single datasource as the default (unnamed) datasource.
1.2.1. Configure a single datasource
A datasource can be either a JDBC datasource, reactive, or both. This depends on the configuration and the selection of project extensions.
Define a datasource with the following configuration property, where
db-kind
defines which database platform to connect to, for example,h2
:quarkus.datasource.db-kind=h2
Quarkus deduces the JDBC driver class it needs to use from the specified value of the
db-kind
database platform attribute.NoteThis step is required only if your application depends on multiple database drivers. If the application operates with a single driver, this driver is detected automatically.
Quarkus currently includes the following built-in database kinds:
-
DB2:
db2
-
Derby:
derby
-
H2:
h2
-
MariaDB:
mariadb
-
Microsoft SQL Server:
mssql
-
MySQL:
mysql
-
Oracle:
oracle
-
PostgreSQL:
postgresql
,pgsql
orpg
To use a database kind that is not built-in, use
other
and define the JDBC driver explicitlyNoteYou can use any JDBC driver in a Quarkus app in JVM mode as described in Using other databases. However, using a non-built-in database kind is unlikely to work when compiling your application to a native executable.
For native executable builds, it is recommended to either use the available JDBC Quarkus extensions or contribute a custom extension for your specific driver.
-
DB2:
Configure the following properties to define credentials:
quarkus.datasource.username=<your username> quarkus.datasource.password=<your password>
You can also retrieve the password from Vault by using a credential provider for your datasource.
Until now, the configuration has been the same regardless of whether you are using a JDBC or a reactive driver. When you have defined the database kind and the credentials, the rest depends on what type of driver you are using. It is possible to use JDBC and a reactive driver simultaneously.
1.2.1.1. JDBC datasource
JDBC is the most common database connection pattern, typically needed when used in combination with non-reactive Hibernate ORM.
To use a JDBC datasource, start with adding the necessary dependencies:
For use with a built-in JDBC driver, choose and add the Quarkus extension for your relational database driver from the list below:
-
Derby -
jdbc-derby
H2 -
jdbc-h2
NoteH2 and Derby databases can be configured to run in "embedded mode"; however, the Derby extension does not support compiling the embedded database engine into native executables.
Read Testing with in-memory databases for suggestions regarding integration testing.
-
DB2 -
jdbc-db2
-
MariaDB -
jdbc-mariadb
-
Microsoft SQL Server -
jdbc-mssql
-
MySQL -
jdbc-mysql
-
Oracle -
jdbc-oracle
-
PostgreSQL -
jdbc-postgresql
Other JDBC extensions, such as SQLite and its documentation, can be found in the Quarkiverse.
For example, to add the PostgreSQL driver dependency:
./mvnw quarkus:add-extension -Dextensions="jdbc-postgresql"
NoteUsing a built-in JDBC driver extension automatically includes the Agroal extension, which is the JDBC connection pool implementation applicable for custom and built-in JDBC drivers. However, for custom drivers, Agroal needs to be added explicitly.
-
Derby -
For use with a custom JDBC driver, add the
quarkus-agroal
dependency to your project alongside the extension for your relational database driver:./mvnw quarkus:add-extension -Dextensions="agroal"
To use a JDBC driver for another database, use a database with no built-in extension or with a different driver.
Configure the JDBC connection by defining the JDBC URL property:
quarkus.datasource.jdbc.url=jdbc:postgresql://localhost:5432/hibernate_orm_test
NoteNote the
jdbc
prefix in the property name. All the configuration properties specific to JDBC have thejdbc
prefix. For reactive datasources, the prefix isreactive
.
For more information about configuring JDBC, see JDBC URL format reference and Quarkus extensions and database drivers reference.
1.2.1.1.1. Custom databases and drivers
If you need to connect to a database for which Quarkus does not provide an extension with the JDBC driver, you can use a custom driver instead. For example, if you are using the OpenTracing JDBC driver in your project.
Without an extension, the driver will work correctly in any Quarkus app running in JVM mode. However, the driver is unlikely to work when compiling your application to a native executable. If you plan to make a native executable, use the existing JDBC Quarkus extensions, or contribute one for your driver.
An example with the OpenTracing driver:
quarkus.datasource.jdbc.driver=io.opentracing.contrib.jdbc.TracingDriver
An example for defining access to a database with no built-in support in JVM mode:
quarkus.datasource.db-kind=other quarkus.datasource.jdbc.driver=oracle.jdbc.driver.OracleDriver quarkus.datasource.jdbc.url=jdbc:oracle:thin:@192.168.1.12:1521/ORCL_SVC quarkus.datasource.username=scott quarkus.datasource.password=tiger
For all the details about the JDBC configuration options and configuring other aspects, such as the connection pool size, refer to the JDBC configuration reference section.
1.2.1.1.2. Consuming the datasource
With Hibernate ORM, the Hibernate layer automatically picks up the datasource and uses it.
For the in-code access to the datasource, obtain it as any other bean as follows:
@Inject AgroalDataSource defaultDataSource;
In the above example, the type is AgroalDataSource
, a javax.sql.DataSource
subtype. Because of this, you can also use javax.sql.DataSource
as the injected type.
1.2.1.2. Reactive datasource
Quarkus offers several reactive clients for use with a reactive datasource.
Add the corresponding extension to your application:
-
DB2:
quarkus-reactive-db2-client
-
MariaDB/MySQL:
quarkus-reactive-mysql-client
-
Microsoft SQL Server:
quarkus-reactive-mssql-client
-
Oracle:
quarkus-reactive-oracle-client
PostgreSQL:
quarkus-reactive-pg-client
The installed extension must be consistent with the
quarkus.datasource.db-kind
you define in your datasource configuration.
-
DB2:
After adding the driver, configure the connection URL and define a proper size for your connection pool.
quarkus.datasource.reactive.url=postgresql:///your_database quarkus.datasource.reactive.max-size=20
1.2.1.2.1. Reactive connection pool size adjustment
To protect your database from overloading during load peaks, size the pool adequately to throttle the database load. The proper size always depends on many factors, such as the number of parallel application users or the nature of the workload.
Be aware that setting the pool size too low might cause some requests to time out while waiting for a connection.
For more information about pool size adjustment properties, see the Reactive datasource configuration reference section.
1.2.1.3. JDBC and reactive datasources simultaneously
When a JDBC extension - along with Agroal - and a reactive datasource extension handling the given database kind are included, they will both be created by default.
To disable the JDBC datasource explicitly:
quarkus.datasource.jdbc=false
To disable the reactive datasource explicitly:
quarkus.datasource.reactive=false
TipIn most cases, the configuration above will be optional as either a JDBC driver or a reactive datasource extension will be present, not both.
1.2.2. Configure multiple datasources
The Hibernate ORM extension supports defining persistence units by using configuration properties. For each persistence unit, point to the datasource of your choice.
Defining multiple datasources works like defining a single datasource, with one important change - you have to specify a name (configuration key) for each datasource.
The following example provides three different datasources:
- the default one
-
a datasource named
users
-
a datasource named
inventory
Each with its configuration:
quarkus.datasource.db-kind=h2 quarkus.datasource.username=username-default quarkus.datasource.jdbc.url=jdbc:h2:mem:default quarkus.datasource.jdbc.max-size=13 quarkus.datasource.users.db-kind=h2 quarkus.datasource.users.username=username1 quarkus.datasource.users.jdbc.url=jdbc:h2:mem:users quarkus.datasource.users.jdbc.max-size=11 quarkus.datasource.inventory.db-kind=h2 quarkus.datasource.inventory.username=username2 quarkus.datasource.inventory.jdbc.url=jdbc:h2:mem:inventory quarkus.datasource.inventory.jdbc.max-size=12
Notice there is an extra section in the configuration key. The syntax is as follows: quarkus.datasource.[optional name.][datasource property]
.
Even when only one database extension is installed, named databases need to specify at least one build-time property so that Quarkus can detect them. Generally, this is the db-kind
property, but you can also specify Dev Services properties to create named datasources according to the Dev Services for Databases guide.
1.2.2.1. Named datasource injection
When using multiple datasources, each DataSource
also has the io.quarkus.agroal.DataSource
qualifier with the name of the datasource as the value.
By using the properties mentioned in the previous section to configure three different datasources, inject each one of them as follows:
@Inject AgroalDataSource defaultDataSource; @Inject @DataSource("users") AgroalDataSource usersDataSource; @Inject @DataSource("inventory") AgroalDataSource inventoryDataSource;
1.3. Datasource integrations
1.3.1. Datasource health check
If you use the quarkus-smallrye-health
extension, the quarkus-agroal
and reactive client extensions automatically add a readiness health check to validate the datasource.
When you access your application’s health readiness endpoint, /q/health/ready
by default, you receive information about the datasource validation status. If you have multiple datasources, all datasources are checked, and if a single datasource validation failure occurs, the status changes to DOWN
.
This behavior can be disabled by using the quarkus.datasource.health.enabled
property.
To exclude only a particular datasource from the health check, use:
quarkus.datasource."datasource-name".health-exclude=true
1.3.2. Datasource metrics
If you are using the quarkus-micrometer
or quarkus-smallrye-metrics
extension, quarkus-agroal
can contribute some datasource-related metrics to the metric registry. This can be activated by setting the quarkus.datasource.metrics.enabled
property to true
.
For the exposed metrics to contain any actual values, a metric collection must be enabled internally by the Agroal mechanisms. By default, this metric collection mechanism is enabled for all datasources when a metrics extension is present, and metrics for the Agroal extension are enabled.
To disable metrics for a particular data source, set quarkus.datasource.jdbc.enable-metrics
to false
, or apply quarkus.datasource.<datasource name>.jdbc.enable-metrics
for a named datasource. This disables collecting the metrics and exposing them in the /q/metrics
endpoint if the mechanism to collect them is disabled.
Conversely, setting quarkus.datasource.jdbc.enable-metrics
to true
, or quarkus.datasource.<datasource name>.jdbc.enable-metrics
for a named datasource explicitly enables metrics collection even if a metrics extension is not in use. This can be useful if you need to access the collected metrics programmatically. They are available after calling dataSource.getMetrics()
on an injected AgroalDataSource
instance.
If the metrics collection for this datasource is disabled, all values result in zero.
1.3.3. Narayana transaction manager integration
Integration is automatic if the Narayana JTA extension is also available.
You can override this by setting the transactions
configuration property:
-
quarkus.datasource.jdbc.transactions
for default unnamed datasource -
quarkus.datasource.<datasource-name>.jdbc.transactions
for named datasource
For more information, see the Configuration reference section below.
To facilitate the storage of transaction logs in a database by using JDBC, see Configuring transaction logs to be stored in a datasource section of the Using transactions in Quarkus guide.
1.3.3.1. Named datasources
When using Dev Services, the default datasource will always be created, but to specify a named datasource, you need to have at least one build time property so Quarkus can detect how to create the datasource.
You will usually specify the db-kind
property or explicitly enable Dev Services by setting quarkus.datasource."name".devservices.enabled=true
.
1.3.4. Testing with in-memory databases
Some databases like H2 and Derby are commonly used in the embedded mode as a facility to run integration tests quickly.
The recommended approach is to use the real database you intend to use in production, especially when Dev Services provide a zero-config database for testing, and running tests against a container is relatively quick and produces expected results on an actual environment. However, it is also possible to use JVM-powered databases for scenarios when the ability to run simple integration tests is required.
1.3.4.1. Support and limitations
Embedded databases (H2 and Derby) work in JVM mode. For native mode, the following limitations apply:
- Derby cannot be embedded into the application in native mode. However, the Quarkus Derby extension allows native compilation of the Derby JDBC client, supporting remote connections.
- Embedding H2 within your native image is not recommended. Consider using an alternative approach, for example, using a remote connection to a separate database instead.
1.3.4.2. Run an integration test
Add a dependency on the artifacts providing the additional tools that are under the following Maven coordinates:
-
io.quarkus:quarkus-test-h2
for H2 io.quarkus:quarkus-test-derby
for DerbyThis will allow you to test your application even when it is compiled into a native executable while the database will run as a JVM process.
-
Add the following specific annotation on any class in your integration tests for running integration tests in both JVM or native executables:
-
@QuarkusTestResource(H2DatabaseTestResource.class)
@QuarkusTestResource(DerbyDatabaseTestResource.class)
This ensures that the test suite starts and terminates the managed database in a separate process as required for test execution.
H2 example
package my.app.integrationtests.db; import io.quarkus.test.common.QuarkusTestResource; import io.quarkus.test.h2.H2DatabaseTestResource; @QuarkusTestResource(H2DatabaseTestResource.class) public class TestResources { }
-
Configure the connection to the managed database:
quarkus.datasource.db-kind=h2 quarkus.datasource.jdbc.url=jdbc:h2:tcp://localhost/mem:test
1.4. References
1.4.1. Common datasource configuration reference
Configuration property fixed at build time - All other configuration properties are overridable at runtime
Type | Default | |
The kind of database we will connect to (e.g. h2, postgresql…).
Environment variable: | string | |
The version of the database we will connect to (e.g. '10.0'). Caution
The version number set here should follow the same numbering scheme as the string returned by As a rule, the version set here should be as high as possible, but must be lower than or equal to the version of any database your application will connect to. A high version will allow better performance and using more features (e.g. Hibernate ORM may generate more efficient SQL, avoid workarounds and take advantage of more database features), but if it is higher than the version of the database you want to connect to, it may lead to runtime exceptions (e.g. Hibernate ORM may generate invalid SQL that your database will reject). Some extensions (like the Hibernate ORM extension) will try to check this version against the actual database version on startup, leading to a startup failure when the actual version is lower or simply a warning in case the database cannot be reached. The default for this property is specific to each extension; the Hibernate ORM extension will default to the oldest version it supports.
Environment variable: | string | |
If DevServices has been explicitly enabled or disabled. DevServices is generally enabled by default unless an existing configuration is present. When DevServices is enabled, Quarkus will attempt to automatically configure and start a database when running in Dev or Test mode.
Environment variable: | boolean | |
The container image name for container-based DevServices providers. This has no effect if the provider is not a container-based database, such as H2 or Derby.
Environment variable: | string | |
Optional fixed port the dev service will listen to. If not defined, the port will be chosen randomly.
Environment variable: | int | |
The container start command to use for container-based DevServices providers. This has no effect if the provider is not a container-based database, such as H2 or Derby.
Environment variable: | string | |
The database name to use if this Dev Service supports overriding it.
Environment variable: | string | |
The username to use if this Dev Service supports overriding it.
Environment variable: | string | |
The password to use if this Dev Service supports overriding it.
Environment variable: | string | |
The path to a SQL script to be loaded from the classpath and applied to the Dev Service database. This has no effect if the provider is not a container-based database, such as H2 or Derby.
Environment variable: | string | |
Whether this particular data source should be excluded from the health check if the general health check for data sources is enabled. By default, the health check includes all configured data sources (if it is enabled).
Environment variable: | boolean |
|
Whether or not a health check is published in case the smallrye-health extension is present. This is a global setting and is not specific to a datasource.
Environment variable: | boolean |
|
Whether or not datasource metrics are published in case a metrics extension is present. This is a global setting and is not specific to a datasource. Note This is different from the "jdbc.enable-metrics" property that needs to be set on the JDBC datasource level to enable collection of metrics for that datasource.
Environment variable: | boolean |
|
The datasource username
Environment variable: | string | |
The datasource password
Environment variable: | string | |
The credentials provider name
Environment variable: | string | |
The credentials provider bean name.
This is a bean name (as in
For Vault, the credentials provider bean name is
Environment variable: | string | |
Environment variables that are passed to the container.
Environment variable: |
| |
Generic properties that are passed for additional container configuration. Properties defined here are database-specific and are interpreted specifically in each database dev service implementation.
Environment variable: |
| |
Generic properties that are added to the database connection URL.
Environment variable: |
| |
The volumes to be mapped to the container. The map key corresponds to the host location; the map value is the container location. If the host location starts with "classpath:", the mapping loads the resource from the classpath with read-only permission. When using a file system location, the volume will be generated with read-write permission, potentially leading to data loss or modification in your file system. This has no effect if the provider is not a container-based database, such as H2 or Derby.
Environment variable: |
| |
Type | Default | |
The kind of database we will connect to (e.g. h2, postgresql…).
Environment variable: | string | |
The version of the database we will connect to (e.g. '10.0'). Caution
The version number set here should follow the same numbering scheme as the string returned by As a rule, the version set here should be as high as possible, but must be lower than or equal to the version of any database your application will connect to. A high version will allow better performance and using more features (e.g. Hibernate ORM may generate more efficient SQL, avoid workarounds and take advantage of more database features), but if it is higher than the version of the database you want to connect to, it may lead to runtime exceptions (e.g. Hibernate ORM may generate invalid SQL that your database will reject). Some extensions (like the Hibernate ORM extension) will try to check this version against the actual database version on startup, leading to a startup failure when the actual version is lower or simply a warning in case the database cannot be reached. The default for this property is specific to each extension; the Hibernate ORM extension will default to the oldest version it supports.
Environment variable: | string | |
If DevServices has been explicitly enabled or disabled. DevServices is generally enabled by default unless an existing configuration is present. When DevServices is enabled, Quarkus will attempt to automatically configure and start a database when running in Dev or Test mode.
Environment variable: | boolean | |
The container image name for container-based DevServices providers. This has no effect if the provider is not a container-based database, such as H2 or Derby.
Environment variable: | string | |
Environment variables that are passed to the container.
Environment variable: |
| |
Generic properties that are passed for additional container configuration. Properties defined here are database-specific and are interpreted specifically in each database dev service implementation.
Environment variable: |
| |
Generic properties that are added to the database connection URL.
Environment variable: |
| |
Optional fixed port the dev service will listen to. If not defined, the port will be chosen randomly.
Environment variable: | int | |
The container start command to use for container-based DevServices providers. This has no effect if the provider is not a container-based database, such as H2 or Derby.
Environment variable: | string | |
The database name to use if this Dev Service supports overriding it.
Environment variable: | string | |
The username to use if this Dev Service supports overriding it.
Environment variable: | string | |
The password to use if this Dev Service supports overriding it.
Environment variable: | string | |
The path to a SQL script to be loaded from the classpath and applied to the Dev Service database. This has no effect if the provider is not a container-based database, such as H2 or Derby.
Environment variable: | string | |
The volumes to be mapped to the container. The map key corresponds to the host location; the map value is the container location. If the host location starts with "classpath:", the mapping loads the resource from the classpath with read-only permission. When using a file system location, the volume will be generated with read-write permission, potentially leading to data loss or modification in your file system. This has no effect if the provider is not a container-based database, such as H2 or Derby.
Environment variable: |
| |
Whether this particular data source should be excluded from the health check if the general health check for data sources is enabled. By default, the health check includes all configured data sources (if it is enabled).
Environment variable: | boolean |
|
The datasource username
Environment variable: | string | |
The datasource password
Environment variable: | string | |
The credentials provider name
Environment variable: | string | |
The credentials provider bean name.
This is a bean name (as in
For Vault, the credentials provider bean name is
Environment variable: | string |
1.4.2. JDBC configuration reference
Configuration property fixed at build time - All other configuration properties are overridable at runtime
Type | Default | |
If we create a JDBC datasource for this datasource.
Environment variable: | boolean |
|
The datasource driver class name
Environment variable: | string | |
Whether we want to use regular JDBC transactions, XA, or disable all transactional capabilities.
When enabling XA you will need a driver implementing
Environment variable: |
|
|
Enable datasource metrics collection. If unspecified, collecting metrics will be enabled by default if a metrics extension is active.
Environment variable: | boolean | |
Enable JDBC tracing. Disabled by default.
Environment variable: | boolean |
|
Enable OpenTelemetry JDBC instrumentation.
Environment variable: | boolean |
|
The datasource URL
Environment variable: | string | |
The initial size of the pool. Usually you will want to set the initial size to match at least the minimal size, but this is not enforced so to allow for architectures which prefer a lazy initialization of the connections on boot, while being able to sustain a minimal pool size after boot.
Environment variable: | int | |
The datasource pool minimum size
Environment variable: | int |
|
The datasource pool maximum size
Environment variable: | int |
|
The interval at which we validate idle connections in the background.
Set to
Environment variable: |
| |
Perform foreground validation on connections that have been idle for longer than the specified interval.
Environment variable: | ||
The timeout before cancelling the acquisition of a new connection
Environment variable: |
| |
The interval at which we check for connection leaks.
Environment variable: |
| |
The interval at which we try to remove idle connections.
Environment variable: |
| |
The max lifetime of a connection.
Environment variable: |
| |
The transaction isolation level.
Environment variable: |
| |
Collect and display extra troubleshooting info on leaked connections.
Environment variable: | boolean |
|
Allows connections to be flushed upon return to the pool. It’s not enabled by default.
Environment variable: | boolean |
|
When enabled, Agroal will be able to produce a warning when a connection is returned to the pool without the application having closed all open statements. This is unrelated with tracking of open connections. Disable for peak performance, but only when there’s high confidence that no leaks are happening.
Environment variable: | boolean |
|
Query executed when first using a connection.
Environment variable: | string | |
Query executed to validate a connection.
Environment variable: | string | |
Disable pooling to prevent reuse of Connections. Use this when an external pool manages the life-cycle of Connections.
Environment variable: | boolean |
|
Require an active transaction when acquiring a connection. Recommended for production. WARNING: Some extensions acquire connections without holding a transaction for things like schema updates and schema validation. Setting this setting to STRICT may lead to failures in those cases.
Environment variable: |
| |
Enable JDBC tracing.
Environment variable: | boolean |
|
Trace calls with active Spans only
Environment variable: | boolean |
|
Ignore specific queries from being traced
Environment variable: | string |
|
Enable OpenTelemetry JDBC instrumentation.
Environment variable: | boolean |
|
Other unspecified properties to be passed to the JDBC driver when creating new connections.
Environment variable: |
| |
Type | Default | |
If we create a JDBC datasource for this datasource.
Environment variable: | boolean |
|
The datasource driver class name
Environment variable: | string | |
Whether we want to use regular JDBC transactions, XA, or disable all transactional capabilities.
When enabling XA you will need a driver implementing
Environment variable: |
|
|
Enable datasource metrics collection. If unspecified, collecting metrics will be enabled by default if a metrics extension is active.
Environment variable: | boolean | |
Enable JDBC tracing. Disabled by default.
Environment variable: | boolean |
|
Enable OpenTelemetry JDBC instrumentation.
Environment variable: | boolean |
|
The datasource URL
Environment variable: | string | |
The initial size of the pool. Usually you will want to set the initial size to match at least the minimal size, but this is not enforced so to allow for architectures which prefer a lazy initialization of the connections on boot, while being able to sustain a minimal pool size after boot.
Environment variable: | int | |
The datasource pool minimum size
Environment variable: | int |
|
The datasource pool maximum size
Environment variable: | int |
|
The interval at which we validate idle connections in the background.
Set to
Environment variable: |
| |
Perform foreground validation on connections that have been idle for longer than the specified interval.
Environment variable: | ||
The timeout before cancelling the acquisition of a new connection
Environment variable: |
| |
The interval at which we check for connection leaks.
Environment variable: |
| |
The interval at which we try to remove idle connections.
Environment variable: |
| |
The max lifetime of a connection.
Environment variable: |
| |
The transaction isolation level.
Environment variable: |
| |
Collect and display extra troubleshooting info on leaked connections.
Environment variable: | boolean |
|
Allows connections to be flushed upon return to the pool. It’s not enabled by default.
Environment variable: | boolean |
|
When enabled, Agroal will be able to produce a warning when a connection is returned to the pool without the application having closed all open statements. This is unrelated with tracking of open connections. Disable for peak performance, but only when there’s high confidence that no leaks are happening.
Environment variable: | boolean |
|
Query executed when first using a connection.
Environment variable: | string | |
Query executed to validate a connection.
Environment variable: | string | |
Disable pooling to prevent reuse of Connections. Use this when an external pool manages the life-cycle of Connections.
Environment variable: | boolean |
|
Require an active transaction when acquiring a connection. Recommended for production. WARNING: Some extensions acquire connections without holding a transaction for things like schema updates and schema validation. Setting this setting to STRICT may lead to failures in those cases.
Environment variable: |
| |
Other unspecified properties to be passed to the JDBC driver when creating new connections.
Environment variable: |
| |
Enable JDBC tracing.
Environment variable: | boolean |
|
Trace calls with active Spans only
Environment variable: | boolean |
|
Ignore specific queries from being traced
Environment variable: | string |
|
Enable OpenTelemetry JDBC instrumentation.
Environment variable: | boolean |
|
To write duration values, use the standard java.time.Duration
format. See the Duration#parse() javadoc for more information.
You can also use a simplified format, starting with a number:
- If the value is only a number, it represents time in seconds.
-
If the value is a number followed by
ms
, it represents time in milliseconds.
In other cases, the simplified format is translated to the java.time.Duration
format for parsing:
-
If the value is a number followed by
h
,m
, ors
, it is prefixed withPT
. -
If the value is a number followed by
d
, it is prefixed withP
.
1.4.3. JDBC URL reference
Each of the supported databases contains different JDBC URL configuration options. The following section gives an overview of each database URL and a link to the official documentation.
1.4.3.1. DB2
jdbc:db2://<serverName>[:<portNumber>]/<databaseName>[:<key1>=<value>;[<key2>=<value2>;]]
- Example
-
jdbc:db2://localhost:50000/MYDB:user=dbadm;password=dbadm;
For more information on URL syntax and additional supported options, see the official documentation.
1.4.3.2. Derby
jdbc:derby:[//serverName[:portNumber]/][memory:]databaseName[;property=value[;property=value]]
- Example
-
jdbc:derby://localhost:1527/myDB
,jdbc:derby:memory:myDB;create=true
Derby is an embedded database that can run as a server, based on a file, or can run completely in memory. All of these options are available as listed above.
For more information, see the official documentation.
1.4.3.3. H2
jdbc:h2:{ {.|mem:}[name] | [file:]fileName | {tcp|ssl}:[//]server[:port][,server2[:port]]/name }[;key=value…]
- Example
-
jdbc:h2:tcp://localhost/~/test
,jdbc:h2:mem:myDB
H2 is a database that can run in embedded or server mode. It can use a file storage or run entirely in memory. All of these options are available as listed above.
For more information, see the official documentation.
1.4.3.4. MariaDB
jdbc:mariadb:[replication:|failover:|sequential:|aurora:]//<hostDescription>[,<hostDescription>…]/[database][?<key1>=<value1>[&<key2>=<value2>]]
hostDescription:: <host>[:<portnumber>] or address=(host=<host>)[(port=<portnumber>)][(type=(master|slave))]
- Example
-
jdbc:mariadb://localhost:3306/test
For more information, see the official documentation.
1.4.3.5. Microsoft SQL server
jdbc:sqlserver://[serverName[\instanceName][:portNumber]][;property=value[;property=value]]
- Example
-
jdbc:sqlserver://localhost:1433;databaseName=AdventureWorks
The Microsoft SQL Server JDBC driver works essentially the same as the others.
For more information, see the official documentation.
1.4.3.6. MySQL
jdbc:mysql:[replication:|failover:|sequential:|aurora:]//<hostDescription>[,<hostDescription>…]/[database][?<key1>=<value1>[&<key2>=<value2>]]
hostDescription:: <host>[:<portnumber>] or address=(host=<host>)[(port=<portnumber>)][(type=(master|slave))]
- Example
-
jdbc:mysql://localhost:3306/test
For more information, see the official documentation.
1.4.3.6.1. MySQL limitations
When compiling a Quarkus application to a native image, the MySQL support for JMX and Oracle Cloud Infrastructure (OCI) integrations are disabled as they are incompatible with GraalVM native images.
- The lack of JMX support is a natural consequence of running in native mode and is unlikely to be resolved.
- The integration with OCI is not supported.
1.4.3.7. Oracle
jdbc:oracle:driver_type:@database_specifier
- Example
-
jdbc:oracle:thin:@localhost:1521/ORCL_SVC
For more information, see the official documentation.
1.4.3.8. PostgreSQL
jdbc:postgresql:[//][host][:port][/database][?key=value…]
- Example
-
jdbc:postgresql://localhost/test
The defaults for the different parts are as follows:
host
- localhost
port
- 5432
database
- same name as the username
For more information about additional parameters, see the official documentation.
1.4.4. Quarkus extensions and database drivers reference
The following tables list the built-in db-kind
values, the corresponding Quarkus extensions, and the JDBC drivers used by those extensions.
When using one of the built-in datasource kinds, the JDBC and Reactive drivers are resolved automatically to match the values from these tables.
Database kind | Quarkus extension | Drivers |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Database kind | Quarkus extension | Driver |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This automatic resolution is applicable in most cases so that driver configuration is not needed.
1.4.5. Reactive datasource configuration reference
Configuration property fixed at build time - All other configuration properties are overridable at runtime
Type | Default | |
If we create a Reactive datasource for this datasource.
Environment variable: | boolean |
|
Whether prepared statements should be cached on the client side.
Environment variable: | boolean |
|
The datasource URLs. If multiple values are set, this datasource will create a pool with a list of servers instead of a single server. The pool uses round-robin load balancing for server selection during connection establishment. Note that certain drivers might not accommodate multiple values in this context.
Environment variable: | list of string | |
The datasource pool maximum size.
Environment variable: | int |
|
When a new connection object is created, the pool assigns it an event loop.
When
Environment variable: | int | |
Whether all server certificates should be trusted.
Environment variable: | boolean |
|
PEM Trust config is disabled by default.
Environment variable: | boolean |
|
Comma-separated list of the trust certificate files (Pem format).
Environment variable: | list of string | |
JKS config is disabled by default.
Environment variable: | boolean |
|
Path of the key file (JKS format).
Environment variable: | string | |
Password of the key file.
Environment variable: | string | |
PFX config is disabled by default.
Environment variable: | boolean |
|
Path to the key file (PFX format).
Environment variable: | string | |
Password of the key.
Environment variable: | string | |
PEM Key/cert config is disabled by default.
Environment variable: | boolean |
|
Comma-separated list of the path to the key files (Pem format).
Environment variable: | list of string | |
Comma-separated list of the path to the certificate files (Pem format).
Environment variable: | list of string | |
JKS config is disabled by default.
Environment variable: | boolean |
|
Path of the key file (JKS format).
Environment variable: | string | |
Password of the key file.
Environment variable: | string | |
PFX config is disabled by default.
Environment variable: | boolean |
|
Path to the key file (PFX format).
Environment variable: | string | |
Password of the key.
Environment variable: | string | |
The number of reconnection attempts when a pooled connection cannot be established on first try.
Environment variable: | int |
|
The interval between reconnection attempts when a pooled connection cannot be established on first try.
Environment variable: |
| |
The hostname verification algorithm to use in case the server’s identity should be checked. Should be HTTPS, LDAPS or an empty string.
Environment variable: | string | |
The maximum time a connection remains unused in the pool before it is closed.
Environment variable: |
| |
Set to true to share the pool among datasources. There can be multiple shared pools distinguished by name, when no specific name is set, the
Environment variable: | boolean |
|
Set the pool name, used when the pool is shared among datasources, otherwise ignored.
Environment variable: | string | |
Other unspecified properties to be passed through the Reactive SQL Client directly to the database when new connections are initiated.
Environment variable: |
| |
Type | Default | |
If we create a Reactive datasource for this datasource.
Environment variable: | boolean |
|
Whether prepared statements should be cached on the client side.
Environment variable: | boolean |
|
The datasource URLs. If multiple values are set, this datasource will create a pool with a list of servers instead of a single server. The pool uses round-robin load balancing for server selection during connection establishment. Note that certain drivers might not accommodate multiple values in this context.
Environment variable: | list of string | |
The datasource pool maximum size.
Environment variable: | int |
|
When a new connection object is created, the pool assigns it an event loop.
When
Environment variable: | int | |
Whether all server certificates should be trusted.
Environment variable: | boolean |
|
PEM Trust config is disabled by default.
Environment variable: | boolean |
|
Comma-separated list of the trust certificate files (Pem format).
Environment variable: | list of string | |
JKS config is disabled by default.
Environment variable: | boolean |
|
Path of the key file (JKS format).
Environment variable: | string | |
Password of the key file.
Environment variable: | string | |
PFX config is disabled by default.
Environment variable: | boolean |
|
Path to the key file (PFX format).
Environment variable: | string | |
Password of the key.
Environment variable: | string | |
PEM Key/cert config is disabled by default.
Environment variable: | boolean |
|
Comma-separated list of the path to the key files (Pem format).
Environment variable: | list of string | |
Comma-separated list of the path to the certificate files (Pem format).
Environment variable: | list of string | |
JKS config is disabled by default.
Environment variable: | boolean |
|
Path of the key file (JKS format).
Environment variable: | string | |
Password of the key file.
Environment variable: | string | |
PFX config is disabled by default.
Environment variable: | boolean |
|
Path to the key file (PFX format).
Environment variable: | string | |
Password of the key.
Environment variable: | string | |
The number of reconnection attempts when a pooled connection cannot be established on first try.
Environment variable: | int |
|
The interval between reconnection attempts when a pooled connection cannot be established on first try.
Environment variable: |
| |
The hostname verification algorithm to use in case the server’s identity should be checked. Should be HTTPS, LDAPS or an empty string.
Environment variable: | string | |
The maximum time a connection remains unused in the pool before it is closed.
Environment variable: |
| |
Set to true to share the pool among datasources. There can be multiple shared pools distinguished by name, when no specific name is set, the
Environment variable: | boolean |
|
Set the pool name, used when the pool is shared among datasources, otherwise ignored.
Environment variable: | string | |
Other unspecified properties to be passed through the Reactive SQL Client directly to the database when new connections are initiated.
Environment variable: |
|
To write duration values, use the standard java.time.Duration
format. See the Duration#parse() javadoc for more information.
You can also use a simplified format, starting with a number:
- If the value is only a number, it represents time in seconds.
-
If the value is a number followed by
ms
, it represents time in milliseconds.
In other cases, the simplified format is translated to the java.time.Duration
format for parsing:
-
If the value is a number followed by
h
,m
, ors
, it is prefixed withPT
. -
If the value is a number followed by
d
, it is prefixed withP
.
1.4.5.1. Reactive DB2 configuration
Configuration property fixed at build time - All other configuration properties are overridable at runtime
Type | Default | |
Whether SSL/TLS is enabled.
Environment variable: | boolean |
|
Type | Default | |
Whether SSL/TLS is enabled.
Environment variable: | boolean |
|
1.4.5.2. Reactive MariaDB/MySQL specific configuration
Configuration property fixed at build time - All other configuration properties are overridable at runtime
Type | Default | |
Charset for connections.
Environment variable: | string | |
Collation for connections.
Environment variable: | string | |
Desired security state of the connection to the server.
Environment variable: |
|
|
Connection timeout in seconds
Environment variable: | int | |
The authentication plugin the client should use. By default, it uses the plugin name specified by the server in the initial handshake packet.
Environment variable: |
|
|
The maximum number of inflight database commands that can be pipelined. By default, pipelining is disabled.
Environment variable: | int | |
Whether to return the number of rows matched by the WHERE clause in UPDATE statements, instead of the number of rows actually changed.
Environment variable: | boolean |
|
Type | Default | |
Charset for connections.
Environment variable: | string | |
Collation for connections.
Environment variable: | string | |
Desired security state of the connection to the server.
Environment variable: |
|
|
Connection timeout in seconds
Environment variable: | int | |
The authentication plugin the client should use. By default, it uses the plugin name specified by the server in the initial handshake packet.
Environment variable: |
|
|
The maximum number of inflight database commands that can be pipelined. By default, pipelining is disabled.
Environment variable: | int | |
Whether to return the number of rows matched by the WHERE clause in UPDATE statements, instead of the number of rows actually changed.
Environment variable: | boolean |
|
1.4.5.3. Reactive Microsoft SQL server-specific configuration
Configuration property fixed at build time - All other configuration properties are overridable at runtime
Type | Default | |
The desired size (in bytes) for TDS packets.
Environment variable: | int | |
Whether SSL/TLS is enabled.
Environment variable: | boolean |
|
Type | Default | |
The desired size (in bytes) for TDS packets.
Environment variable: | int | |
Whether SSL/TLS is enabled.
Environment variable: | boolean |
|
1.4.5.4. Reactive Oracle-specific configuration
Configuration property fixed at build time - All other configuration properties are overridable at runtime
Type | Default |
1.4.5.5. Reactive PostgreSQL-specific configuration
Configuration property fixed at build time - All other configuration properties are overridable at runtime
Type | Default | |
The maximum number of inflight database commands that can be pipelined.
Environment variable: | int | |
SSL operating mode of the client. See Protection Provided in Different Modes.
Environment variable: |
|
|
Type | Default | |
The maximum number of inflight database commands that can be pipelined.
Environment variable: | int | |
SSL operating mode of the client. See Protection Provided in Different Modes.
Environment variable: |
|
|
1.4.6. Reactive datasource URL reference
1.4.6.1. DB2
db2://[user[:[password]]@]host[:port][/database][?<key1>=<value1>[&<key2>=<value2>]]
- Example
-
db2://dbuser:secretpassword@database.server.com:50000/mydb
Currently, the client supports the following parameter keys:
-
host
-
port
-
user
-
password
-
database
Configuring parameters in the connection URL overrides the default properties.
1.4.6.2. Microsoft SQL server
sqlserver://[user[:[password]]@]host[:port][/database][?<key1>=<value1>[&<key2>=<value2>]]
- Example
-
sqlserver://dbuser:secretpassword@database.server.com:1433/mydb
Currently, the client supports the following parameter keys:
-
host
-
port
-
user
-
password
-
database
Configuring parameters in the connection URL overrides the default properties.
1.4.6.3. MySQL / MariaDB
mysql://[user[:[password]]@]host[:port][/database][?<key1>=<value1>[&<key2>=<value2>]]
- Example
-
mysql://dbuser:secretpassword@database.server.com:3211/mydb
Currently, the client supports the following parameter keys (case-insensitive):
-
host
-
port
-
user
-
password
-
schema
-
socket
-
useAffectedRows
Configuring parameters in the connection URL overrides the default properties.
1.4.6.4. Oracle
1.4.6.4.1. EZConnect format
oracle:thin:@[[protocol:]//]host[:port][/service_name][:server_mode][/instance_name][?connection properties]
- Example
-
oracle:thin:@mydbhost1:5521/mydbservice?connect_timeout=10sec
1.4.6.4.2. TNS alias format
oracle:thin:@<alias_name>[?connection properties]
- Example
-
oracle:thin:@prod_db?TNS_ADMIN=/work/tns/
1.4.6.5. PostgreSQL
postgresql://[user[:[password]]@]host[:port][/database][?<key1>=<value1>[&<key2>=<value2>]]
- Example
-
postgresql://dbuser:secretpassword@database.server.com:5432/mydb
Currently, the client supports:
Following parameter keys:
-
host
-
port
-
user
-
password
-
dbname
-
sslmode
-
Additional properties, such as:
-
application_name
-
fallback_application_name
-
search_path
-
options
-
Configuring parameters in the connection URL overrides the default properties.