Replies: 16 comments 17 replies
-
We are looking at CockroachDB support in the new store. |
Beta Was this translation helpful? Give feedback.
-
An alternative to Cockroach that is getting attention lately is YugaByte. |
Beta Was this translation helpful? Give feedback.
-
Is there a list of priorities of work on the new store somewhere? Has there been a survey of Keycloak users to determine the value in pursuing support for different implementations of the new store? I ask because I have many customers with on-prem deployments that use Keycloak for a limited use case (shim between an application and their in-house IdP) that want Keycloak to be more lightweight (most requested is running without Infinispan). |
Beta Was this translation helpful? Give feedback.
-
We did a proof of concept using CockroachDB for Keycloak a few years ago (https://github.com/cloudtrust/keycloak/tree/cockroach-db). Unfortunately we didn't have the resources to go further, so it's now a fairly old version, but maybe this fork can give you an idea of the changes/impacts. Even though we had to freeze this initiative on our side, I think it would be very interesting for Keycloak to support this kind of database in the future, as it is particularly suitable for large scale deployment in cloud. |
Beta Was this translation helpful? Give feedback.
-
True, but I think we should pick on, not two, that we support, and in this regard CockroachDB is more mature, and seems to be the better option, but I don't have any real insight which is actually the better for Keycloak. |
Beta Was this translation helpful? Give feedback.
-
+1 for official CockroachDB support. There already are CockroachDB dialects in newer Hibernate releases: 5.4 to 5.6, 6.0. So it looks like most of the work would be to upgrade to that version, find or implement a way to use the appropriate dialect as the driver and jdbc are still going to be postgresql, implement tests and update documentation. For now I don't see anything else that would need to be specifically reworked or optimized for CockroachDB in Keycloak code. See also https://blog.flant.com/ha-keycloak-infinispan-kubernetes/ for a recent example of an automated deployment of Keycloak with CockroachDB as data storage. |
Beta Was this translation helpful? Give feedback.
-
With keycloak.x 15.0.2 I hit an issue on start up of keycloak. I have manually done an IMPORT PGDUMP to prepare the crdb. The error I am seeing liquibase still trying to run and possibly migrate the db schema and the error it is getting is on creating an index
It would be great if there was a way to tell keycloak to not attempt the schema change with liquibase on startup. |
Beta Was this translation helpful? Give feedback.
-
thanks. I am using 21.2, but seems there is still an issue. would be good to not have to manually modify the XML though. For the SQL, when I make that change in keycloak standalone it doesn't seem to generate, just fails when it gets to that db migrate step. with keycloak.x I wasn't able to find how to indicate the migration strategy (may keep me from having to manually modify the XML if I was able to do it) |
Beta Was this translation helpful? Give feedback.
-
The multi-region capability of Cockroach DB sounds really nice. However, there don't seem to be any offers by the big cloud providers (definitely not on Azure). There is a marketplace offering in Azure but I don't know if its used that much, at least it doesn't have any rating. We would most likely not operate our own DB, so I am wondering how many people would actually be able to use Cockroach DB at this time. |
Beta Was this translation helpful? Give feedback.
-
With keycloak 19.0 new storage you just need to use |
Beta Was this translation helpful? Give feedback.
-
Dear Keycloak maintainers,
Currently we have Keycloak 21. Can we say that Keycloak is ready to be used with CockroachDB? I've been evaluating previous version of Keycloak and observed that one of the major problems with Cockroach in Keycloak 19 ("TransactionWriteTooOld") was fixed in Keycloak 20 (#13210). Not sure about the rest though. |
Beta Was this translation helpful? Give feedback.
-
We were choosing a distributed database for ourselves and finally settled on YugabyteDB. It is simpler, more convenient and, most importantly, much more productive than CockroachDB. To confirm my words, here are the prufs: |
Beta Was this translation helpful? Give feedback.
-
A bit late to this thread, but because there will never be CockroachDB support for the “legacy” store, we patched Keycloak in order to enable it. We maintain a docker image that is up to date with Keycloak releases that contains our patch. Keycloak on CockroachDB docker images It must be run with a few configuration options set:
|
Beta Was this translation helpful? Give feedback.
-
We use CockroachDB and Postgres today. We've looked at Yugabyte and it's not a good solution for us. Cockroach is our preferred database and am really looking forward to official Keycloak support for this database. Thank you, @xgp for creating the patch. We will test it out. |
Beta Was this translation helpful? Give feedback.
-
I think it needs to be said, in this Issue where we are supposed to justify the use of cockroachdb, that there was already such a demand for what it provides that Keycloak began working on a new storage strategy using cockroachdb. Do we really still need to justify it? I would think, if Keycloak was being written from scratch today, that a decision might be made to go with a solution which scales such as cockroachdb rather than postgres. (The discontinuation post speaks about wanting cross-DC support from the get go, is postgres really the best way to go if you could choose any database?) In a home project I started out with postgres and then began looking into cockroachdb so that I could offer a db which scales in addition to postgres, then it occurred to me, why would I start with postgres (other than it is popular), when I could just start with a single-node cockroachdb deployment by default for small scale installations, and for large deployments simply scale up? The idea of justification is around avoiding having to support several databases, as has been done in the past with Keycloak and over time database support for several databases was dropped to simplify the code base ... I get it, but why stick with postgres when the base database could be cockroachdb? Maybe there should be an issue where folks need to post the reasons why postgres should be a supported database option instead of just assumed. In an HA scenario where the postgres master has failed and its time to switch over to the slave, how common knowledge are those next steps to recover things? Will it just be handled automatically? How much time will it take to switch over to the slave? With cockroachdb things just keep going right? Isn't that the preferred desired user experience? Why wouldn't that be the default/first choice? |
Beta Was this translation helpful? Give feedback.
-
We also need to run Keycloak with CockroachDB. This feature is essential for our setup and would greatly enhance our system's reliability and scalability. Despite trying a simple example with CockroachDB
To reproduce, use this Docker Compose setup:
Can anyone provide an update on the current state of Keycloak's support for CockroachDB and any potential solutions or workarounds? |
Beta Was this translation helpful? Give feedback.
-
CockroachDB could provide a lot of benefits for larger deployments and deployments that require additional disaster recovery such as multi-region deployments.
Some more information can be found in the Geographically Distributed Stateful Workloads blog series:
In addition the Disaster Recovery Strategies for Applications Running on OpenShift provides useful information.
Beta Was this translation helpful? Give feedback.
All reactions