Configuring the database

Configure a relational database for Keycloak to store user, client, and realm data.

This guide explains how to configure the Keycloak server to store data in a relational database.

Supported databases

The server has built-in support for different databases. You can query the available databases by viewing the expected values for the db configuration option. The following table lists the supported databases and their tested versions.

Database Option value Tested Version Supported Versions

MariaDB Server

mariadb

11.8

11.8 (LTS), 11.4 (LTS), 10.11 (LTS), 10.6 (LTS)

Microsoft SQL Server

mssql

2022

2022, 2019

MySQL

mysql

8.4

8.4 (LTS), 8.0 (LTS)

Oracle Database

oracle

23.5

23.x (i.e 23.5+), 19c (19.3+) (Note: Oracle RAC is also supported if using the same database engine version, e.g 23.5+, 19.3+)

PostgreSQL

postgres

17

17.x, 16.x, 15.x, 14.x, 13.x

EnterpriseDB Advanced

postgres

17

17

Amazon Aurora PostgreSQL

postgres

17.5

17.x, 16.x, 15.x

Azure SQL Database

mssql

latest

latest

Azure SQL Managed Instance

mssql

latest

latest
It is not a supported configuration if the underlying database specific Hibernate dialect allows the use of a version that differs from those shown.

By default, the server uses the dev-file database. This is the default database that the server will use to persist data and only exists for development use-cases. The dev-file database is not suitable for production use-cases, and must be replaced before deploying to production.

Installing a database driver

Database drivers are shipped as part of Keycloak except for the Oracle Database driver.

Install the necessary missing driver manually if you want to connect to this database or skip this section if you want to connect to a different database for which the database driver is already included.

Overriding the built-in database drivers or supplying your own drivers is considered unsupported. The only supported exceptions are explicitly documented in this guide, such as the Oracle Database driver.

Installing the Oracle Database driver

To install the Oracle Database driver for Keycloak:

  1. Download the ojdbc17 and orai18n JAR files from one of the following sources:

    1. Zipped JDBC driver and Companion Jars version 23.6.0.24.10 from the Oracle driver download page.

    2. Maven Central via ojdbc17 and orai18n.

    3. Installation media recommended by the database vendor for the specific database in use.

  2. When running the unzipped distribution: Place the ojdbc17 and orai18n JAR files in Keycloak’s providers folder

  3. When running containers: Build a custom Keycloak image and add the JARs in the providers folder. When building a custom image for the Operator, those images need to be optimized images with all build-time options of Keycloak set.

    A minimal Containerfile to build an image which can be used with the Keycloak Operator and includes Oracle Database JDBC drivers downloaded from Maven Central looks like the following:

    FROM quay.io/keycloak/keycloak:latest
ADD --chown=keycloak:keycloak --chmod=644 https://repo1.maven.org/maven2/com/oracle/database/jdbc/ojdbc17/23.6.0.24.10/ojdbc17-23.6.0.24.10.jar /opt/keycloak/providers/ojdbc17.jar
ADD --chown=keycloak:keycloak --chmod=644 https://repo1.maven.org/maven2/com/oracle/database/nls/orai18n/23.6.0.24.10/orai18n-23.6.0.24.10.jar /opt/keycloak/providers/orai18n.jar
# Setting the build parameter for the database:
ENV KC_DB=oracle
# Add all other build parameters needed, for example enable health and metrics:
ENV KC_HEALTH_ENABLED=true
ENV KC_METRICS_ENABLED=true
# To be able to use the image with the Keycloak Operator, it needs to be optimized, which requires Keycloak's build step:
RUN /opt/keycloak/bin/kc.sh build

    See the Running Keycloak in a container guide for details on how to build optimized images.

Then continue configuring the database as described in the next section.

Configuring a database

For each supported database, the server provides some opinionated defaults to simplify database configuration. You complete the configuration by providing some key settings such as the database host and credentials.

The configuration can be set during a build command OR a start command:

  1. Using a build command followed by an optimized start command (recommended)

    First, the minimum settings needed to connect to the database can be specified in conf/keycloak.conf:

    # The database vendor.
db=postgres

# The username of the database user.
db-username=keycloak

# The password of the database user.
db-password=change_me

# Sets the hostname of the default JDBC URL of the chosen vendor
db-url-host=keycloak-postgres

    Then, the following commands create a new and optimized server image based on the configuration options and start the server.

    bin/kc.[sh|bat] build
bin/kc.[sh|bat] start --optimized

  2. Using only a start command (without --optimized)

    bin/kc.[sh|bat] start --db postgres --db-url-host keycloak-postgres --db-username keycloak --db-password change_me
The examples above include the minimum settings needed to connect to the database but it exposes the database password and is not recommended. Use the conf/keycloak.conf as shown above, environment variables, or keystore for at least the password.

The default schema is keycloak, but you can change it by using the db-schema configuration option.

It is also possible to configure the database when Importing and exporting realms or Bootstrapping and recovering an admin account:

bin/kc.[sh|bat] import --help
bin/kc.[sh|bat] export --help
bin/kc.[sh|bat] bootstrap-admin --help

For more information, see Configuring Keycloak.

Overriding default connection settings

The server uses JDBC as the underlying technology to communicate with the database. If the default connection settings are insufficient, you can specify a JDBC URL using the db-url configuration option.

The following is a sample command for a PostgreSQL database.

bin/kc.[sh|bat] start --db postgres --db-url jdbc:postgresql://mypostgres/mydatabase

Be aware that you need to escape characters when invoking commands containing special shell characters such as ; using the CLI, so you might want to set it in the configuration file instead.

Configuring Unicode support for the database

Unicode support for all fields depends on whether the database allows VARCHAR and CHAR fields to use the Unicode character set.

  • If these fields can be set, Unicode is likely to work, usually at the expense of field length.

  • If the database only supports Unicode in the NVARCHAR and NCHAR fields, Unicode support for all text fields is unlikely to work because the server schema uses VARCHAR and CHAR fields extensively.

The database schema provides support for Unicode strings only for the following special fields:

  • Realms: display name, HTML display name, localization texts (keys and values)

  • Federation Providers: display name

  • Users: username, given name, last name, attribute names and values

  • Groups: name, attribute names and values

  • Roles: name

  • Descriptions of objects

Otherwise, characters are limited to those contained in database encoding, which is often 8-bit. However, for some database systems, you can enable UTF-8 encoding of Unicode characters and use the full Unicode character set in all text fields. For a given database, this choice might result in a shorter maximum string length than the maximum string length supported by 8-bit encodings.

Configuring Unicode support for an Oracle database

Unicode characters are supported in an Oracle database if the database was created with Unicode support in the VARCHAR and CHAR fields. For example, you configured AL32UTF8 as the database character set. In this case, the JDBC driver requires no special settings.

If the database was not created with Unicode support, you need to configure the JDBC driver to support Unicode characters in the special fields. You configure two properties. Note that you can configure these properties as system properties or as connection properties.

  1. Set oracle.jdbc.defaultNChar to true.

  2. Optionally, set oracle.jdbc.convertNcharLiterals to true.

    For details on these properties and any performance implications, see the Oracle JDBC driver configuration documentation.

Unicode support for a Microsoft SQL Server database

Unicode characters are supported only for the special fields for a Microsoft SQL Server database. The database requires no special settings.

The sendStringParametersAsUnicode property of JDBC driver should be set to false to significantly improve performance. Without this parameter, the Microsoft SQL Server might be unable to use indexes.

Configuring Unicode support for a MySQL database

Unicode characters are supported in a MySQL database if the database was created with Unicode support in the VARCHAR and CHAR fields when using the CREATE DATABASE command.

Note that the utf8mb4 character set is not supported due to different storage requirements for the utf8 character set. See MySQL documentation for details. In that situation, the length restriction on non-special fields does not apply because columns are created to accommodate the number of characters, not bytes. If the database default character set does not allow Unicode storage, only the special fields allow storing Unicode values.

  1. Start MySQL Server.

  2. Under JDBC driver settings, locate the JDBC connection settings.

  3. Add this connection property: characterEncoding=UTF-8

Configuring Unicode support for a PostgreSQL database

Unicode is supported for a PostgreSQL database when the database character set is UTF8. Unicode characters can be used in any field with no reduction of field length for non-special fields. The JDBC driver requires no special settings. The character set is determined when the PostgreSQL database is created.

  1. Check the default character set for a PostgreSQL cluster by entering the following SQL command.

    show server_encoding;

  2. If the default character set is not UTF 8, create the database with the UTF8 as the default character set using a command such as:

    create database keycloak with encoding 'UTF8';

Preparing for PostgreSQL

When running PostgreSQL reader and writer instances, Keycloak needs to always connect to the writer instance to do its work. When using the original PostgreSQL driver, Keycloak sets the targetServerType property of the PostgreSQL JDBC driver to primary to ensure that it always connects to a writable primary instance and never connects to a secondary reader instance in failover or switchover scenarios.

You can override this behavior by setting your own value for targetServerType in the DB URL or additional properties.

The targetServerType is only applied automatically to the primary datasource, as requirements might be different for additional datasources.
Secure Your PostgreSQL Connection

To secure your database connection, configure your PostgreSQL server to use TLS and perform full server certificate verification on the client side.

Server-side Configuration (Prerequisites): Before using the properties below, ensure your PostgreSQL server is configured for TLS.

Client-side Configuration: Secure the connection by adding the following properties to your connection URL:

db-url=jdbc:postgresql://...?sslmode=verify-full&sslrootcert=/path/to/certificate

  • sslmode=verify-full: Forces TLS and verifies the server’s identity against the trusted certificate.

  • sslrootcert=/path/to/certificate: The path to the server’s public certificate file on the client machine.

Preparing for Amazon Aurora PostgreSQL

When using Amazon Aurora PostgreSQL, the Amazon Web Services JDBC Driver offers additional features like transfer of database connections when a writer instance changes in a Multi-AZ setup. This driver is not part of the distribution and needs to be installed before it can be used.

To install this driver, apply the following steps:

  1. When running the unzipped distribution: Download the JAR file from the Amazon Web Services JDBC Driver releases page and place it in Keycloak’s providers folder.

  2. When running containers: Build a custom Keycloak image and add the JAR in the providers folder.

    A minimal Containerfile to build an image which can be used with the Keycloak Operator looks like the following:

    FROM quay.io/keycloak/keycloak:latest
ADD --chmod=0666 https://github.com/awslabs/aws-advanced-jdbc-wrapper/releases/download/2.5.6/aws-advanced-jdbc-wrapper-2.5.6.jar /opt/keycloak/providers/aws-advanced-jdbc-wrapper.jar

    See the Running Keycloak in a container guide for details on how to build optimized images, and the Using custom Keycloak images guide on how to run optimized and non-optimized images with the Keycloak Operator.

  3. Configure Keycloak to run with the following parameters:

    db-url

    Insert aws-wrapper to the regular PostgreSQL JDBC URL resulting in a URL like jdbc:aws-wrapper:postgresql://....

    db-driver

    Set to software.amazon.jdbc.Driver to use the AWS JDBC wrapper.

When overriding the wrapperPlugins option of the AWS JDBC Driver, always include the failover or failover2 plugin to ensure that Keycloak always connects to the writer instance even in failover or switchover scenarios.
Secure Your Aurora PostgreSQL Connection

Amazon Aurora PostgreSQL 17.0 or later requires TLS connections by default.

While this encrypts the connection, you must still perform a full server certificate verification. To do this download the certificate bundle for your AWS region.

Secure the connection by adding the sslmode=verify-full and sslrootcert=/path/to/certificate properties to your connection URL:

db-url=jdbc:aws-wrapper:postgresql://...?sslmode=verify-full&sslrootcert=/path/to/certificate

  • sslmode=verify-full: Forces TLS and verifies the server’s identity against the trusted certificate.

  • sslrootcert=/path/to/certificate: The path to the downloaded certificate bundle.

Preparing for MySQL server

Beginning with MySQL 8.0.30, MySQL supports generated invisible primary keys for any InnoDB table that is created without an explicit primary key (more information here). If this feature is enabled, the database schema initialization and also migrations will fail with the error message Multiple primary key defined (1068). You then need to disable it by setting the parameter sql_generate_invisible_primary_key to OFF in your MySQL server configuration before installing or upgrading Keycloak.

Changing database locking timeout in a cluster configuration

Because cluster nodes can boot concurrently, they take extra time for database actions. For example, a booting server instance may perform some database migration, importing, or first time initializations. A database lock prevents start actions from conflicting with each other when cluster nodes boot up concurrently.

The maximum timeout for this lock is 900 seconds. If a node waits on this lock for more than the timeout, the boot fails. The need to change the default value is unlikely, but you can change it by entering this command:

bin/kc.[sh|bat] start --spi-dblock--jpa--lock-wait-timeout 900

Using Database Vendors with XA transaction support

Keycloak uses non-XA transactions and the appropriate database drivers by default.

If you wish to use the XA transaction support offered by your driver, enter the following command:

bin/kc.[sh|bat] build --db=<vendor> --transaction-xa-enabled=true

Keycloak automatically chooses the appropriate JDBC driver for your vendor.

Certain vendors, such as Azure SQL and MariaDB Galera, do not support or rely on the XA transaction mechanism.

XA recovery defaults to enabled and will use the file system location KEYCLOAK_HOME/data/transaction-logs to store transaction logs.

Enabling XA transactions in a containerized environment does not fully support XA recovery unless stable storage is available at that path.

Setting JPA provider configuration option for migrationStrategy

To setup the JPA migrationStrategy (manual/update/validate) you should setup JPA provider as follows:

Setting the migration-strategy for the quarkus provider of the connections-jpa SPI
bin/kc.[sh|bat] start --spi-connections--jpa--quarkus-migration-strategy=manual

If you want to get a SQL file for DB initialization, too, you have to add this additional SPI initializeEmpty (true/false):

Setting the initialize-empty for the quarkus provider of the connections-jpa SPI
bin/kc.[sh|bat] start --spi-connections--jpa--quarkus-initialize-empty=false

In the same way the migrationExport to point to a specific file and location:

Setting the migration-export for the quarkus provider of the connections-jpa SPI
bin/kc.[sh|bat] start --spi-connections--jpa--quarkus-migration-export=<path>/<file.sql>

For more information, check the Migrating the database documentation.

Configuring the connection pool

MySQL and MariaDB

In order to prevent 'No operations allowed after connection closed' exceptions from being thrown, it is necessary to ensure that Keycloak’s connection pool has a connection maximum lifetime that is less than the server’s configured wait_timeout. When using the MySQL and MariaDB database, Keycloak configures a default max lifetime of 7 hours and 50 minutes, as this is less than the default server value of 8 hours.

If you are explicitly configuring the wait_timeout in your database, it is necessary to ensure that you configure a db-pool-max-lifetime value that is less than the wait_timeout. The recommended best practice, is to define this value to be your wait_timeout minus a few minutes. Failure to correctly configure the db-pool-max-lifetime will result in Keycloak logging a warning on startup.

Configure multiple datasources

Keycloak allows you to specify additional datasources in case you need to access another database from your extensions. This is useful when using the main Keycloak datasource is not a viable option for storing custom data, like users.

You can find more details on how to connect to your own users database in the User Storage SPI documentation.

Defining multiple datasources works like defining a single datasource, with one important change - you have to specify a name for each datasource as part of the config option name.

Required configuration

In order to enable an additional datasource, you need to set up 2 things - the JPA persistence.xml file and Keycloak configuration. The persistence.xml file serves to specify persistence units as part of the Jakarta Persistence API standard, and is required for proper configuration propagation to the Hibernate ORM framework. When you complete the part with the persistence.xml file, you need to set up Keycloak configuration accordingly.

The additional datasource properties might be specified via the standard config sources like CLI, keycloak.conf, or environment variables.

The additional datasources can be configured in a similar way as the main datasource. This is achieved by using analogous names for config options, which additionally include the name of the additional datasource. For example, when the main datasource uses the db-username, the additional one would be db-username-<datasource>. See the Relevant options chapter for the complete list of them.

1. JPA persistence.xml file

The persistence.xml provides configuration for Jakarta Persistence API (JPA) such as what entities it should manage, the datasource name, JDBC settings, JPA/Hibernate custom settings, and more. The file needs to be placed in the META-INF/persistence.xml folder of your custom Keycloak extension.

Be aware that Quarkus provides the ability to set up the JPA persistence unit via Hibernate ORM properties instead of using the persistence.xml file. However, the supported way for Keycloak is using the persistence.xml file, and if the file is present, the Quarkus properties are ignored.

In Keycloak, most of the configuration is automatic, and you just need to provide fundamental configuration details - the datasource name and transaction type.

Keycloak requires setting the transaction type for the additional datasource to JTA. You can set the transaction type and datasource name as follows for this minimal persistence.xml file:

<persistence xmlns="https://jakarta.ee/xml/ns/persistence"
                         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                         xsi:schemaLocation="https://jakarta.ee/xml/ns/persistence https://jakarta.ee/xml/ns/persistence/persistence_3_0.xsd"
                         version="3.0">
    <persistence-unit name="user-store-pu" transaction-type="JTA">
        <class>org.your.extension.UserEntity</class>
        <properties>
            <property name="jakarta.persistence.jtaDataSource" value="user-store" />
        </properties>
    </persistence-unit>
</persistence>
To properly set the datasource name, you should set the jakarta.persistence.jtaDataSource property. If it is not set, the persistence unit name will be used as the datasource name instead (so user-store-pu in this case). In the example above, the resulting datasource name is user-store. The datasource name can be the same as the persistence unit name.

In order to use your own JPA entities, you need to provide the <class> properties that mark JPA entities that will be managed by this persistence unit, directed to a specific datasource. In the example above, the org.your.extension.UserEntity JPA entity will be managed by the persistence unit user-store-pu, directed to the user-store datasource.

2. Required properties

Once you have set up your persistence.xml, the minimal configuration on the Keycloak side is the setup of the DB kind/vendor for the specified datasource. You need to specify the build time option db-kind-<name>, where the <name> is the name of your datasource and must be the same as specified in the persistence.xml file.

Therefore, you can enable the additional datasource user-store as follows (postgres as an example):

bin/kc.[sh|bat] start --db-kind-user-store=postgres

After specifying the db-kind for the datasource, all database-kind–specific defaults (such as the driver and dialect) are automatically applied, just like for the main datasource.

Configuration via environment variables

If you do not want to configure the datasource via CLI or keycloak.conf properties, you can use the environment variables.

You can set the DB kind via environment variables (for the user-store datasource) as follows:

export KC_DB_KIND_USER_STORE=postgres
export KC_DB_USERNAME_USER_STORE=my-username

It maps to the db-kind-user-store and db-username-user-store Keycloak properties due to the default mapping of the _ (underscore) to the - (dash) for environment variables. However, sometimes, the name of the datasource might contain some special characters like _, $ or .

In order to have it properly configured via the Keycloak environment variables, you need to explicitly say what the key for the datasource should look like. You can use a pair of unique Keycloak environment variables with a special case of the KCKEY_.

For instance, for a datasource with the name user_store$marketing, you can set environment variables as follows:

export KC_USER_STORE_DB_KIND=mariadb
export KCKEY_USER_STORE_DB_KIND=db-kind-user_store$marketing

You can find more information in the guide Configuring Keycloak, in subsection Formats for environment variable keys with special characters.

Backward compatibility for the quarkus.properties

In the past, we instructed users to use raw Quarkus properties to configure additional datasources in some places. However, as using Quarkus properties in the conf/quarkus.properties file is considered unsupported, it is strongly recommended to use the dedicated additional datasources options as described above.

Before you are able to migrate to the dedicated options, you can still specify the datasource settings via the Quarkus properties as follows:

quarkus.datasource.user-store.db-kind=h2
quarkus.datasource.user-store.username=sa
quarkus.datasource.user-store.jdbc.url=jdbc:h2:mem:user-store;DB_CLOSE_DELAY=-1
quarkus.datasource.user-store.jdbc.transactions=xa
Use Quarkus properties without quotation for the datasource name, as properties with the quoted datasource name clash with the new datasource options mapping. Therefore, use quarkus.datasource.user-store.db-kind=h2, instead of quarkus.datasource."user-store".db-kind=h2 to prevent any issues.

Relevant options

Type or Values Default

db

The database vendor.

In production mode the default value of dev-file is deprecated, you should explicitly specify the db instead.

Named key: db-kind-<datasource>

CLI: --db
Env: KC_DB

dev-file, dev-mem, mariadb, mssql, mysql, oracle, postgres, tidb

dev-file

db-debug-jpql

Add JPQL information as comments to SQL statements to debug JPA SQL statement generation.

Named key: db-debug-jpql-<datasource>

CLI: --db-debug-jpql
Env: KC_DB_DEBUG_JPQL

true, false

false

db-driver

The fully qualified class name of the JDBC driver.

If not set, a default driver is set accordingly to the chosen database.

Named key: db-driver-<datasource>

CLI: --db-driver
Env: KC_DB_DRIVER

String

db-log-slow-queries-threshold

Log SQL statements slower than the configured threshold with logger org.

hibernate.SQL_SLOW and log-level info.

Named key: db-log-slow-queries-threshold-<datasource>

CLI: --db-log-slow-queries-threshold
Env: KC_DB_LOG_SLOW_QUERIES_THRESHOLD

Integer

10000

db-password

The password of the database user.

Named key: db-password-<datasource>

CLI: --db-password
Env: KC_DB_PASSWORD

String

db-pool-initial-size

The initial size of the connection pool.

Named key: db-pool-initial-size-<datasource>

CLI: --db-pool-initial-size
Env: KC_DB_POOL_INITIAL_SIZE

Integer

db-pool-max-lifetime

The maximum time a connection remains in the pool, after which it will be closed upon return and replaced as necessary.

May be an ISO 8601 duration value, an integer number of seconds, or an integer followed by one of [ms, h, m, s, d].

CLI: --db-pool-max-lifetime
Env: KC_DB_POOL_MAX_LIFETIME

String

db-pool-max-size

The maximum size of the connection pool.

Named key: db-pool-max-size-<datasource>

CLI: --db-pool-max-size
Env: KC_DB_POOL_MAX_SIZE

Integer

100

db-pool-min-size

The minimal size of the connection pool.

Named key: db-pool-min-size-<datasource>

CLI: --db-pool-min-size
Env: KC_DB_POOL_MIN_SIZE

Integer

db-schema

The database schema to be used.

Named key: db-schema-<datasource>

CLI: --db-schema
Env: KC_DB_SCHEMA

String

db-url

The full database JDBC URL.

If not provided, a default URL is set based on the selected database vendor. For instance, if using postgres, the default JDBC URL would be jdbc:postgresql://localhost/keycloak.

Named key: db-url-full-<datasource>

CLI: --db-url
Env: KC_DB_URL

String

db-url-database

Sets the database name of the default JDBC URL of the chosen vendor.

If the db-url option is set, this option is ignored.

Named key: db-url-database-<datasource>

CLI: --db-url-database
Env: KC_DB_URL_DATABASE

String

db-url-host

Sets the hostname of the default JDBC URL of the chosen vendor.

If the db-url option is set, this option is ignored.

Named key: db-url-host-<datasource>

CLI: --db-url-host
Env: KC_DB_URL_HOST

String

db-url-port

Sets the port of the default JDBC URL of the chosen vendor.

If the db-url option is set, this option is ignored.

Named key: db-url-port-<datasource>

CLI: --db-url-port
Env: KC_DB_URL_PORT

Integer

db-url-properties

Sets the properties of the default JDBC URL of the chosen vendor.

Make sure to set the properties accordingly to the format expected by the database vendor, as well as appending the right character at the beginning of this property value. If the db-url option is set, this option is ignored.

Named key: db-url-properties-<datasource>

CLI: --db-url-properties
Env: KC_DB_URL_PROPERTIES

String

db-username

The username of the database user.

Named key: db-username-<datasource>

CLI: --db-username
Env: KC_DB_USERNAME

String

transaction-xa-enabled

If set to true, XA datasources will be used.

Named key: transaction-xa-enabled-<datasource>

CLI: --transaction-xa-enabled
Env: KC_TRANSACTION_XA_ENABLED

true, false

false

Additional datasources options

Type or Values Default

db-debug-jpql-<datasource>

Used for named <datasource>.

Add JPQL information as comments to SQL statements to debug JPA SQL statement generation.

CLI: --db-debug-jpql-<datasource>
Env: KC_DB_DEBUG_JPQL_<DATASOURCE>

true, false

false

db-driver-<datasource>

Used for named <datasource>.

The fully qualified class name of the JDBC driver. If not set, a default driver is set accordingly to the chosen database.

CLI: --db-driver-<datasource>
Env: KC_DB_DRIVER_<DATASOURCE>

String

db-enabled-<datasource>

If the named datasource <datasource> should be enabled at runtime.

CLI: --db-enabled-<datasource>
Env: KC_DB_ENABLED_<DATASOURCE>

true, false

true

db-kind-<datasource>

Used for named <datasource>.

The database vendor. In production mode the default value of dev-file is deprecated, you should explicitly specify the db instead.

CLI: --db-kind-<datasource>
Env: KC_DB_KIND_<DATASOURCE>

dev-file, dev-mem, mariadb, mssql, mysql, oracle, postgres, tidb

db-log-slow-queries-threshold-<datasource>

Used for named <datasource>.

Log SQL statements slower than the configured threshold with logger org.hibernate.SQL_SLOW and log-level info.

CLI: --db-log-slow-queries-threshold-<datasource>
Env: KC_DB_LOG_SLOW_QUERIES_THRESHOLD_<DATASOURCE>

Integer

10000

db-password-<datasource>

Used for named <datasource>.

The password of the database user.

CLI: --db-password-<datasource>
Env: KC_DB_PASSWORD_<DATASOURCE>

String

db-pool-initial-size-<datasource>

Used for named <datasource>.

The initial size of the connection pool.

CLI: --db-pool-initial-size-<datasource>
Env: KC_DB_POOL_INITIAL_SIZE_<DATASOURCE>

Integer

db-pool-max-size-<datasource>

Used for named <datasource>.

The maximum size of the connection pool.

CLI: --db-pool-max-size-<datasource>
Env: KC_DB_POOL_MAX_SIZE_<DATASOURCE>

Integer

100

db-pool-min-size-<datasource>

Used for named <datasource>.

The minimal size of the connection pool.

CLI: --db-pool-min-size-<datasource>
Env: KC_DB_POOL_MIN_SIZE_<DATASOURCE>

Integer

db-schema-<datasource>

Used for named <datasource>.

The database schema to be used.

CLI: --db-schema-<datasource>
Env: KC_DB_SCHEMA_<DATASOURCE>

String

db-url-database-<datasource>

Used for named <datasource>.

Sets the database name of the default JDBC URL of the chosen vendor. If the db-url option is set, this option is ignored.

CLI: --db-url-database-<datasource>
Env: KC_DB_URL_DATABASE_<DATASOURCE>

String

db-url-full-<datasource>

Used for named <datasource>.

The full database JDBC URL. If not provided, a default URL is set based on the selected database vendor. For instance, if using postgres, the default JDBC URL would be jdbc:postgresql://localhost/keycloak.

CLI: --db-url-full-<datasource>
Env: KC_DB_URL_FULL_<DATASOURCE>

String

db-url-host-<datasource>

Used for named <datasource>.

Sets the hostname of the default JDBC URL of the chosen vendor. If the db-url option is set, this option is ignored.

CLI: --db-url-host-<datasource>
Env: KC_DB_URL_HOST_<DATASOURCE>

String

db-url-port-<datasource>

Used for named <datasource>.

Sets the port of the default JDBC URL of the chosen vendor. If the db-url option is set, this option is ignored.

CLI: --db-url-port-<datasource>
Env: KC_DB_URL_PORT_<DATASOURCE>

Integer

db-url-properties-<datasource>

Used for named <datasource>.

Sets the properties of the default JDBC URL of the chosen vendor. Make sure to set the properties accordingly to the format expected by the database vendor, as well as appending the right character at the beginning of this property value. If the db-url option is set, this option is ignored.

CLI: --db-url-properties-<datasource>
Env: KC_DB_URL_PROPERTIES_<DATASOURCE>

String

db-username-<datasource>

Used for named <datasource>.

The username of the database user.

CLI: --db-username-<datasource>
Env: KC_DB_USERNAME_<DATASOURCE>

String

transaction-xa-enabled-<datasource>

If set to true, XA for <datasource> datasource will be used.

CLI: --transaction-xa-enabled-<datasource>
Env: KC_TRANSACTION_XA_ENABLED_<DATASOURCE>

true, false

true
On this page
Edit this guide