Replies: 22 comments 13 replies
-
|
Thanks for being transparent about this issue. I would argue that a good predicate to deciding which databases to support would be to understand how Keycloak is actually being deployed and used in the "wild". E.g.:
Etc. I've noticed that there are a lot of exciting things happening (e.g. switch to Quarkus, new store, this database support change), but very few of them seem to be driven by a broad understanding of the above. Especially in the recent switch from Wildfly to Quarkus, I heard a lot of "Whoa! What happened? Didn't they know I relied on X?", met with "Is that even something we want to support?" rather than the ability to fall back on usage and survey data for justification. In any case, I appreciate the more open discussions that have been happening in the last few months, and I hope it can continue to expand the understanding of use cases and the community. |
Beta Was this translation helpful? Give feedback.
-
Let me try to be more clear about how each of my above questions could help us to understand the issue of database support:
This would help to assign meaning to a significant change like database support. How many users would be in the first/second/community classes, and how many would be left with unsupported databases? If those numbers could be posted here, it would help the community engage in the decision, because they know how they would be effected. The lack of engagement you may have encountered in other issues (e.g. Wildfly -> Quarkus) was less about not caring, and more about not understanding the impact to them.
Database type selection would likely vary by installation size. E.g. I would not choose something like Cockroach if I only need tens of users for a small business application. Is Keycloak targeting big public cloud deployments, or small on-prem applications? The answer changes the candidates for database support.
As with the size question, the primary use case can effect the database type selection. E.g. If I only use it for
As @dasniko and I have discovered in supporting many companies, there are a lot of guidelines used by enterprises for different environments. Some admins won't have the luxury of selecting their databases, because it will be a matter of policy. By contrast, other companies with public cloud deployments may have the ability to select from many hosted database types, like the ones you list.
This is meant to get to your understanding of the community use versus RedHat's customer use. I'm sure you have daily conversations with the latter, but from the looks of the mailing list and discourse, the former appears to be often poorly understood. While it is not clear to me that Keycloak versus RH-SSO draws a line around financial and training resources, it would be useful to know more about the aggregate numbers in order to know who you will be supporting and who you would be leaving behind. A better understanding of both use cases could help influence the database support decision.
Similar to the above, these are a question of manageability and how to select the most appropriate mix of support. Databases can have vastly different maintenance profiles. For example, many historically chose MySQL because it was perceived to be easier to install and maintain. While we may not agree with those profiles, it is important to understand the capabilities and environments of the users to appropriately select database support. |
Beta Was this translation helpful? Give feedback.
-
|
I see your thoughts.
I fear, that this won't be as easy as you think. There are a lot of companies ("enterprises") out there, which have strict guidelines, which databases they support. Some are only allowed to use MySQL, many Microsoft-infused companies only allow/support to use MS SQL DB, etc. Even if the teams who support/use Keycloak want to use another database, the company policies doesn't allow them to use these. Unfortunately. |
Beta Was this translation helpful? Give feedback.
-
|
I was thinking the same thing. If I recall correctly IBM, the owner of Red Hat, don't support PostgreSQL databases for their clients. It could be that my experiences were project-specific or team-specific and not universally true, but it was unfortunate. (IBM also supported that project before they acquired Red Hat, so maybe their offerings changed. This was about 6 years ago.) In the end, we ran up our own PostgreSQL databases without their support, so functionally we were fine, but I imagine this scenario happens a lot through the corporate/enterprise world. Edit: That all being said, I always run Keycloak with PostgreSQL, so I'm pleased to see it as the first class option. |
Beta Was this translation helpful? Give feedback.
-
|
There a plan for a fully open source solution to multi region HA Keycloak? Not sure you can get there with postgres? Maybe the commercial version of cockroachdb (they mention multiregion is ccl paid)? Vitess would be a potentially good option but mysql based. |
Beta Was this translation helpful? Give feedback.
-
|
i relly hope they add support for Vitess (see: https://vitess.io/) |
Beta Was this translation helpful? Give feedback.
-
I am much in favour of this. Persistent (session) caches using the PostgreSQL database instead of relying on a multi-node Infinispan cluster would make smaller deployments easier to maintain and leaner. This could also improve Keycloak's role in the use case as an AuthN/AuthZ component in smaller standalone applications rather than as an external global service. Just like database systems evolved over time from global centralized systems in an organization to lean components in cloud native apps. |
Beta Was this translation helpful? Give feedback.
-
|
I like cockroachdb(CRDB)-compatible postgres. That means that keycloak is tested on CRDB and Postgres to ensure that they both function. In reality, it means not using any postgres features (extensions, stored procedures, etc) that are not supported in CRDB. I'm happy to help contribute with support for this model (or any efforts that enhance ease of use on k8s). |
Beta Was this translation helpful? Give feedback.
-
|
Would you supply a migration tool, say from MySQL to PostgreSQL ? Or maybe export/import from one instance to another would be sufficient ? |
Beta Was this translation helpful? Give feedback.
-
|
The plan is to provide a migration tool from the old store to the new store. Not sure how exactly it will look like, but should be something better than export/import to json. |
Beta Was this translation helpful? Give feedback.
-
|
We're using an external MySQL DB for realms storage and a NoSQL DB (couchbase) for user data storage. |
Beta Was this translation helpful? Give feedback.
-
|
If my database is not supported, can I simply just implement one of the SPI interfaces? Maybe there can be community implementations for non-standard databases. E.g. at scale, people might want to use something like cassandra, and I really don't think that the keycloak team should support something like that. but, it would be helpful if you guys could have examples of that that are supported. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that will be possible. A storage implementation can choose which entity types it wants to support, and leave other entity types to other stores. Thereby you can implement for example a store only for some of the session types while not implementing it for others. You'll get an idea how modular this is by looking into https://github.com/keycloak/keycloak/blob/main/testsuite/integration-arquillian/tests/base/src/test/resources/META-INF/keycloak-server.json and searching for "concurrenthashmap"). In the folder https://github.com/keycloak/keycloak/tree/main/model/jpa you'll find a work-in-progress implementation for JPA supports already some of the entity types. |
Beta Was this translation helpful? Give feedback.
-
|
We have relatively many customers from the government sector and install keycloak in their existing infrastructure. It is completely different which databases are used (MySQL, MariaDB, Oracle, MSSQL). I chose keycloak because it is flexible enough to support many databases. In my opinion, we should not simply give up this flexibility. |
Beta Was this translation helpful? Give feedback.
-
|
I reached out to current and former customers and companies I have helped with Keycloak installations and asked which database they are using with Keycloak. I did not ask for version or whether they were using a cloud vendor hosted version.
And I added a bonus question. How many are using CockroachDB for any reason? Only 1 of 36! What was interesting to me is that there was no clear winner here. While PostgreSQL was first, it was still only about a third. Curious if other consultants and vendors that serve Keycloak users and companies that use Keycloak can add their numbers here. I have a suspicion that the way forward is already decided, but this might be a good way to identify candidates for community supported implementations. I second the observations of @commander81 and @dasniko. Customers/Users of Keycloak often have little control over what database they use, and have chosen Keycloak because of its broad database support. |
Beta Was this translation helpful? Give feedback.
-
|
Looks like my case of #10392 is affected here. |
Beta Was this translation helpful? Give feedback.
-
@stianst Could you please clarify what that "support" means? As far as I know, JPA is not going to be dropped from Keycloak's code base - so what is meant by "phase out support" exactly? My first interpretation of that sentence was that anyone who plans to introduce Keycloak into an environment that neither uses PostgreSQL nor CockroachDB will face a major obstacle in the future and is strongly advised to think twice. If that's not the intention of that paragraph, the published blog post (https://www.keycloak.org/2022/02/dbs) could be misinterpreted (i.e. it misses information from your comment on a migration tool). I can also confirm @xgp's observation: in most projects - not only limited to Keycloak-related ones - the choice of database technology is dictated by an official policy or indirectly by available know-how. Based on my own observations I suspect that database technology preferences vary also from industry to industry, which would put more weight on know-how limitations. |
Beta Was this translation helpful? Give feedback.
-
|
@stianst ping. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I just happened on this discussion today. While I'm glad that you're planning to support a cloud native database I would argue that YugabyteDB (https://www.yugabyte.com/) would be a better fit as it's a fully open-source database (see : https://docs.yugabyte.com/latest/legal/) when CockroachDB is not (see : https://www.cockroachlabs.com/docs/stable/licensing-faqs.html). Especially, YugabyteDB doesn't have any features locked behind an "Enterprise" version. |
Beta Was this translation helpful? Give feedback.
-
|
Vitess (see : https://vitess.io/) is open-source too |
Beta Was this translation helpful? Give feedback.
-
|
The discussion is very relevant to us. We just introduced Keycloak for our software suite that is deployed by > 100 customers in the german eGovernment sector in heterogeneous environments. Our customers are not free to change the DBMS. For our software suite we support Oracle, MS SQL-Server, MySQL and MariaDB. Our customers use
The wide support of DBMS for Keycloak was a reason for introducing Keycloak. So DB support is essential to us for keep using Keycloak. @stianst do you have already results from your survey? How do you plan to implement community support for databases? will you host the dbms tests and just get the support implemented by the community? |
Beta Was this translation helpful? Give feedback.
-
|
We are currently developing a Cassandra-based UserStorage-extension for a customer in the public sector, which we are planning to release as an Open Source-project down the line. |
Beta Was this translation helpful? Give feedback.
-
|
I think it's not easy to "only" provide a migration path from i.e. MySQL to PostgreSQL. Chances are implementations rely on a specific MySQL distribution for clustering, backed by infrastructure and expertise. It is one thing to install a single PostgreSQL instance and import a database dump which run through some conversion script - it's another thing to find a PostgreSQL distribution fitting the clustering needs, learning, configuring, testing, deploying it. All the while possibly keeping the MySQL cluster up for other applications. Please note I am stating this under the assumption MySQL is not considered a "legacy" database solution - I am not suggesting holding on to any arbitrary piece of legacy software is a good idea, but that MySQL is still a powerful and actively deployed database solution. I understand that stripping database support will likely make maintenance of the project and support easier - but as already pointed out by others, wide database support will allow way broader access to the product, the beneficial return of which I assume outweighs the effort. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the transparency on this issue! As others have pointed out, I mainly see problems in environments that need to deal with complex database setups. If you just use the single keycloak, single DB setup, there are likely no significant pro's con's to come up with for any DB provider. Once you start talking about clustering, high availability, etc. then it becomes complicated. As these mechanisms are non-trivial to setup with any DB provider, a company is likely to have invested in a specific DB vendor regarding these non-trivial setup tasks. For such companies, moving to any other DB vendor is going to be painful and/or expensive, since they'll need to re-lean that DB-vendor specific knowledge (or purchase it through consulting). I would like to offer an altnerative approach to this issue, albeit a mainly theoretical one at this point, I'm hoping others can chime in and come up with more specific practical implementations: I got this idea thinking about how Elastic offers their search product: I use it quite extensively in my day-to-day job, and know it uses APache Lucence under the hood, but I don't know the first thing about Lucene, mainly because I don't have to worry about it. Elastic documents how to set up clusters, configure HA, etc, using their DSL for configuration, and their software will worry about configuring the underlying Lucene engine to do what is being requested by the user. I realise that something like this could really blow up the scope on this issue, but at least I'd like to see it considered. |
Beta Was this translation helpful? Give feedback.
-
|
The aim with the first class databases is to basically get as close to what you are proposing as we can and makes sense. I don't think we should actually "embed" a database in Keycloak, but rather recommend "managed" databases through Kubernetes Operators and SaaS vendors, as mentioned for PostgreSQL there are many options here. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for all the comments, and to everyone filling in the survey. We've had a tremendous amount of people filling in the survey (672!). We're still reviewing the survey and this thread, so have not made a conclusion yet. For the time being here's the overall results:
The results clearly show more interest in PostgreSQL, and growing interest in CockroachDB. However, at the same time it also shows interest in other database vendors, that we can't simply ignore. The current plans are the new store will focus on PostgreSQL and CockroachDB first, and we will get back to everyone with more details later what happens to other databases. What happens to MySQL, MariaDB, SQL Server, and Oracle in the long run is still a bit unclear. We are leaning towards keeping support for at least some of them, but that's not a given at this point, and will certainly not see the same love and attention that we plan to offer to the first class databases. One thing worth keeping in mind here is that MySQL and MariaDB from our perspective are so aligned that we can consider that close to a single database from the effort of keeping support for them. Oracle and SQL Server on the other hand are more expensive for us to maintain, and have fairly low interest from the survey. |
Beta Was this translation helpful? Give feedback.
-
|
I would like to add something to this discussion: our company uses keycloak as the authorisation server for on-premise installations. So we install keycloak a lot on-site at our customers. And our survey looks quite different. Most of our customers use Oracle or MSSQL. These are the databases that are comercially available. That might even be the reason why they are used. So you paid (a lot of) money for the database and maybe hired an expert who knows to handle the database. These customers are VERY reluctant to change their already installed database (or add another one). I don't know what you want to change in your persistence layer and what would make a database expensive to maintain. We also use liquibase/hibernate and had not problems with different databases so far (apart from cockroachDB of course, but that was when they could not add a primary key to a table after the table was created). So we hope that you will consider not to cut off support for the only two commercial databases that we primarily (have to) use. |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to point out one thing here, which is the fact that quite a few people are stating need to continue support for MySQL, Oracle, etc. and many are expressing the word "customer" when they do so. That means you are making money out of an open source project, and in turn could consider contribute something back. So far many has expressed a request to continue supporting all the database we support today, but no one has so far stepped-up to help make that happen. Dropping additional database is not something we want to do, but may end up having to do due to capacity. Supporting additional databases comes at the expense of other things. Anyone interested in contributing to make this happen let me know, and we can talk to figure out how you can best contribute for us to be able to continue supporting a wide selection of different databases with Keycloak. |
Beta Was this translation helpful? Give feedback.
-
I made a proposal for an alternative solution, but so far received no feedback on that. Feel free to let me know if you would like to discuss that proposal through some other channel. |
Beta Was this translation helpful? Give feedback.
-
Currently it is hard for me to estimate the contribution efford necessary to support the second class databases:
|
Beta Was this translation helpful? Give feedback.
-
I have the same questions as Sebastian :-) I think we would contribute to support Oracle and SqlServer. As I said, we currently have to run Keycloak on those database and even if we can convince everyone to move to postgres or add a postgres database instance, this will take some time. The decision is not mine though and an estimate of the expected effort that will be needed would help. |
Beta Was this translation helpful? Give feedback.
-
There is original design proposal: https://github.com/keycloak/keycloak-community/blob/main/design/keycloak.x/storage-persistence.md In the design proposal there is mentioned There is module https://github.com/keycloak/keycloak/tree/main/model/map-jpa with current ongoing development, which might provide some guidance. Each implementation of new storage should implement |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I implemented a proof-of-concept to support mssql as a backend of map-jpa - see PR #14773. The purpose of this PR is to have a basis for a discussion on how a implementation could look like. I just changed the existing map-jpa provider (which uses postgresql) to work with mssql. Whats working?
I'm not a database expert, so I would be glad if people with more knowledge in that area could have look onto his. @jhollmannk from your comment I understand that you're also working with mssql, so maybe you're interested in have a look. Any feedback is appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
Hey we migrated successfully from MSSQL to Postgres using this tool here: https://github.com/Nuvalence/sqlserver2pgsql-docker Ready to use image: https://hub.docker.com/r/grohankarn/sqlserver2psql/tags With good preperation the downtime was <15min for us. |
Beta Was this translation helpful? Give feedback.
-
|
Beware now we got a Problem with Liquibase checksums read here: #19467 |
Beta Was this translation helpful? Give feedback.
and others
-
Maintaining a broad selection of relational database support is expensive, and also more importantly limits how well the databases can be supported.
With that in mind we are looking at supporting databases at different levels; first class, second class, and community.
Please fill in this survey as we'd like to gather as much feedback as we can.
First class databases
The aim of first class databases is to offer better levels of tuning and testing, better defaults, and better documentation. We will also be considering testing with different versions and variants of the selected first class databases, such as cloud services.
First class databases will be the solutions we are looking towards when scaling and tuning database to accommodate large scale deployments with high-availability, including multi-region deployments.
As first class databases we aim to support one traditional relational database, and a cloud native database. With this in mind we have selected PostgreSQL and CockroachDB as the best candidates.
PostgreSQL is a high quality fully open source database, with many supported offerings such as:
CockroachDB is an cloud native open source database, with PostgreSQL compatibility. By cloud native it means that it can scale horizontally, including spanning multiple-regions. There are some competitive solutions, but not as mature, and with less streamlined PostgreSQL compatibility. There are obviously also NoSQL and other non-relational database that could in theory be a good fit for Keycloak, but would be a lot of additional effort to support.
It is also worth mentioning that we are still looking towards Infinispan as our cache layer, but are also aiming to support running Keycloak without Infinspan for smaller deployments with PostgreSQL and larger deployments with CockroachDB.
Second class databases
The aim for second class databases are to offer mostly the same support as we offer for any database in Keycloak today. We will only test one version, there will be no database vendor specific documentation, or any additional tuning on our end.
We do hope that the majority of the Keycloak community are able to migrate to first class databases, and that this will in the end be a better solution for everyone. As such we are not currently planning on offering any second class databases long term, and rather phase out support for MySQL, MariaDB, SQL Server, and Oracle over time.
Community supported databases
If there is interest from the community to support additional databases, including non-relational database, we would like to discuss and figure out how this could look like. Including making it easy to install community maintained databases, as well as continuously testing of the integration.
Beta Was this translation helpful? Give feedback.
All reactions