# Keycloak Performance Benchmarks: A Deep Dive into Scaling and Sizing (26.4)

DevFeed: [Keycloak Performance Benchmarks: A Deep Dive into Scaling and Sizing (26.4)](<https://devfeed.tech/articles/keycloak-performance-benchmarks-a-deep-dive-into-scaling-and-sizing-26-4-31729.md>)

Original publisher: [Read original article](<https://www.keycloak.org/2025/10/keycloak-benchmark>)

Author: Pedro Ruivo

Published: 2025-10-01T00:00:00Z

Content type: article

Language: en

Sources: [Keycloak Blog](<https://devfeed.tech/sources/keycloak-blog.md>)

Topics: [Keycloak](<https://devfeed.tech/topics/keycloak.md>), [Benchmark](<https://devfeed.tech/topics/benchmark.md>), [Availability](<https://devfeed.tech/topics/availability.md>), [Databases](<https://devfeed.tech/topics/databases.md>), [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [Amazon Web Services](<https://devfeed.tech/topics/aws.md>)

Tags: [amazon-aurora](<https://devfeed.tech/tags/amazon-aurora.md>), [availability](<https://devfeed.tech/tags/availability.md>), [aws](<https://devfeed.tech/tags/aws.md>), [benchmarks](<https://devfeed.tech/tags/benchmarks.md>), [idm](<https://devfeed.tech/tags/idm.md>), [kerberos](<https://devfeed.tech/tags/kerberos.md>), [keycloak](<https://devfeed.tech/tags/keycloak.md>), [ldap](<https://devfeed.tech/tags/ldap.md>), [openid-connect](<https://devfeed.tech/tags/openid-connect.md>), [openshift](<https://devfeed.tech/tags/openshift.md>), [performance](<https://devfeed.tech/tags/performance.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [saml](<https://devfeed.tech/tags/saml.md>), [sso](<https://devfeed.tech/tags/sso.md>)

## AI overview

This article presents Keycloak 26.4 benchmark results covering scaling under increasing login and refresh-token load, resource sizing, high availability, artificial network latency, and caching for database usage. In the tested range, Keycloak scaled almost linearly when scaled vertically.

## Source excerpt

When deploying a mission-critical component like Keycloak, performance is a top concern. Questions about resource requirements, high availability, and network latency are crucial for a successful and stable production environment. To provide a clear, data-driven perspective on these topics, we conducted a series of benchmarks on the latest Keycloak version 26.4. In this post, we'll share our findings on how Keycloak scales with increasing load, performs under artificial network latency, and leverages caching to optimize database usage. Share your feedback about this blog post in our forum! Environment OpenShift 4.17 deployed across three availability zones in eu-west-1. Provisioned using Red Hat OpenShift Service on AWS (ROSA), with ROSA HCP. At least one worker node in each availability zone. Amazon Aurora PostgreSQL 17.5 database. Configured for high availability, with a primary DB instance in one availability zone and synchronously replicated readers in the other availability zones. Database populated with 100,000 users. Keycloak Benchmark as the load generator. The benchmark ran on 20 to 50 t4g.small AWS instances in the same region. Scaling Keycloak One of the most common questions when deploying Keycloak is: how many resources do I need? The answer, as you may have guessed, is that it depends on your specific use case. For this test, we scaled only the login and refresh token requests. Based on Keycloak's Concepts for sizing CPU and memory resources documentation, we determined that you need 1 vCPU to handle 15 logins per second and an additional 1 vCPU to handle 120 refresh token requests per second. After computing the total number of vCPUs required, we divided the value by the desired number of Pods, which was three in this case (one for each availability zone). We allocated slightly more vCPU to each Pod than the calculated value to account for JVM background tasks like compilations and garbage collection. Because our test used a constant load, we did not