Keycloak vs authentik vs Zitadel

Keycloak, authentik and Zitadel differ most in what you must run around the server. Keycloak needs a relational database in production, and the supported databases include PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database and Amazon Aurora PostgreSQL. The dev-file database is for development only. Keycloak documents three high availability designs: one cluster optionally spread across availability zones, multi-cluster deployments (v2) without an external Infinispan cluster, and the deprecated multi-cluster v1. Both supported designs require a synchronously replicated database, so your database team must own replication and failover as part of the Keycloak design. Confirm the database vendor's replication model before you commit to a topology.

authentik runs as a server container with an embedded outpost, plus a worker container for background tasks, and stores its configuration and data in PostgreSQL. The 2025.10 release notes state that authentik no longer uses Redis, moving caching, tasks, sessions and WebSocket functions to PostgreSQL, and warn of roughly 50% more PostgreSQL connections after upgrading. For operations, that means one fewer component to run, but PostgreSQL connection capacity and pooling become a sizing question. Check the connection limits on your database before upgrading an existing authentik install, and confirm the worker container is scaled and monitored alongside the server.

Zitadel is event sourced: it stores every change as an event, which gives a built-in audit trail of all changes over an unlimited period. Self-hosted Zitadel uses PostgreSQL 14 through 18 and documents Linux and macOS binaries, Docker Compose and Kubernetes, with the official Helm chart recommended for high availability. The operational consequence is that your event store grows with change history, so retention, backup and restore procedures should be tested against that model. Ask the vendor how event data is compacted or archived in your target version, and treat the audit trail as a data-protection question as well as a feature.

For Keycloak, the cadence question is less about how often patches arrive and more about how often you must test a minor upgrade. The project plans four minor releases a year and a major release every two to three years, and since Keycloak 26.0 it has said that breaking changes in a minor release will be opt-in. That lowers the risk of surprises, but your team still has to choose which minor line to run, read the upgrading guide for each one it adopts, and retest realm configuration, custom providers and themes. Keycloak 26.8.1 is the current release. The Operator adds a second decision: the Operator documentation strongly recommends manual approval mode for operator updates, so someone on your team must own the approval step and keep it on a schedule.

authentik versions by year and month, so 2026.8.4 is the current release, and its security policy lists 2026.5.x and 2026.8.x as the lines receiving security fixes. The project announces security releases at least 24 hours in advance, which is a short window for a team that must schedule a change, back up PostgreSQL and verify the outpost after the update. Plan for patch days as an on-call or change-window task rather than quarterly work. Confirm which line your deployment is on, because an install on a line outside the supported list falls outside the security policy. The 2025.10 release notes also warn of roughly 50% more PostgreSQL connections after upgrading, so a routine-looking patch can still need database capacity checks. Read the authentik security policy before setting a patch rule.

Zitadel's current release is v4.19.5, released on October 15, 2026, and it follows a major.minor.patch tag format that you can see on its GitHub releases page. Confirm the support window for each line on that page before you write an internal patch policy. Because Zitadel stores every change as an event in PostgreSQL 14 to 18, each upgrade touches the same database that holds your audit trail, so a tested backup is part of every change. Whatever the cadence, the recurring work is the same: test each release in staging, apply database changes with a verified restore path, and track the Helm chart or Compose versions you deploy. Your own staff carry most of this work. A partner such as DeployOpen can take on upgrades or continuous support only under a written scope, so ask for the upgrade steps, test coverage and rollback plan in any quote.

The cost of moving off an identity provider is mostly the data and the trust relationships around it, not the software. Keycloak keeps users, credentials, roles, groups and client registrations in its database, and each application depends on a client configuration that defines redirect URIs, scopes and token settings. authentik stores its configuration and data in PostgreSQL, and Zitadel organizes users under instances, organizations and projects. Each product models these objects differently, so an export from one rarely maps one to one into another. Before any decision, inventory the realms, clients, protocol mappers, identity brokering links and federation settings you actually use, and confirm which of them can be exported as data and which must be recreated by hand.

The harder items are the ones users never see. Password hashes may not transfer, or may only transfer in a format the target accepts, which can force a password reset or a just-in-time migration step at first login. Multi-factor enrollments, passkeys and session behavior often do not move with the user record. Zitadel documents migration guides from Keycloak and other systems, including just-in-time migration, but whether your credential types, custom attributes and client settings carry over is a question to test against a copy of your own data set, not something to assume from the guide. Audit history is the other gap: Zitadel's event-sourced store keeps an audit trail of changes, but that history stays in the original system when you leave it, and your compliance evidence may need to be retained there.

Plan for a parallel run before any cutover. Keep the old provider authoritative for a defined set of applications, move a pilot group, and verify token claims, group mappings and logout behavior for each relying party. Ask any implementation partner or vendor to state in writing which objects migrate automatically, which need scripting, and which must be rebuilt, and to price the parallel run separately from the export work.