Here is some context:
We are using an Idp and we have an use case where users can login with a token for example. But because that Idp doesn’t support custom authentication, we are considering to connect the current Idp with Keycloak so Keycloak can handle those users. In other words the “main” Idp will delegate authentication to Keycloak.
Keycloak will receive a token and will validate that token, also we will fetch the user data from an external service, so we can get the info about that user. In a few words, we won’t store any information about the users in Keycloak nor groups and roles. We just want to use Keycloak as a “validator”.
Is there any reason to use another database different from the H2 that comes out-of-the-box?
Keycloak comes with its own embedded Java-based relational database called H2. This is the default database that Keycloak will use to persist data and really only exists so that you can run the authentication server out of the box. We highly recommend that you replace it with a more production ready external database. The H2 database is not very viable in high concurrency situations and should not be used in a cluster either.
However, it really depends on what you are using Keycloak for. For example, I have many customers that just use Keycloak as a “shim” between their application and their customers’ IdP. In that use case, they are fine running a single instance of Keycloak with H2 on a persistent volume. They are tolerant of downtime, and don’t mind losing data if the pod disappears between volume snapshots. If this is similar to your use case, it’s not a bad decision.
Regarding the “H2 database is not very viable in high concurrency situations”, I have never had a concurrency problem with it, even under high, concurrent load. It can even be much faster in a single node setup than using a remote database. However, as they say, it is unsuitable for cluster use.
If you are new to Keycloak and just want to check if the provided functionality satisfies your needs, H2 is suitable. But in production, it might be a risk. Because of reliability.
I used H2 for a Keycloak test system. One realm, 10 clients, 20 users, no concurrency, no load. Started with KC3, migrated through the versions up to KC11 without problems. Then, Keycloak DB migrations during upgrade from KC11 to KC12 shreddered the H2. Went back to KC11, H2 still not usable, fatal errors during startup. Restored a backup of the H2, migrated again to KC12 → H2 in pieces again…
(while my MS SQL based setups migrated without problems.)