Why authentik slows down and where to look first
When users report slow sign-ins or a sluggish admin interface on a running authentik, start by assuming the database is involved. Since the 2025.10 release, PostgreSQL is the shared dependency for caching, tasks, sessions and WebSocket functions, so a slowdown usually traces either to slow or congested queries against the database itself or to background work queued behind it. This page is organized diagnosis first and fixes second, so you can confirm which of those two problems you have before changing connection settings, adding infrastructure or resizing containers.
The removal of Redis in the 2025.10 release is the most common reason connection counts changed on existing deployments. The release notes warn of roughly 50% more PostgreSQL connections after upgrading, because the work Redis used to absorb now lands on PostgreSQL. Compare your current connection count and the database's connection limit against the period before the upgrade, and check whether the increase lines up with the slowdown you are seeing. Your team should also confirm the database host's memory and CPU headroom and whether a connection pooler is already in front of it, since those determine how much of that extra load the database can absorb.
Work through the checks in order: confirm the database is the bottleneck, identify the slow queries, then review worker backlog and event retention before changing the topology. Each of those steps points to a different fix, and the authentik documentation on troubleshooting slow PostgreSQL queries is the natural starting point for the query step. Record the version you run, because the 2026.5 release changed worker connection counts, and that change affects how you read the numbers.
Five places slowness usually starts
Slow logins and a sluggish admin interface usually trace back to a small set of places: the database, its connections, the worker queue, growing event tables, and the host itself. Since authentik 2025.10 moved caching, tasks, sessions and WebSockets into PostgreSQL, these suspects share one database, so a problem in one often shows up as a symptom in another.
Slow PostgreSQL queries
The symptom is a page or login that stalls while the database is busy, often on the admin list views or the flow executor. Start in PostgreSQL by checking for long-running statements and their wait states, then match them to the authentik views or tasks that issued them. Because authentik now stores caching and sessions in the same database, a slow query can affect logins even when the server container looks healthy. Work through the slow query guide before changing any indexes or settings.
Rising connection counts
The symptom is intermittent connection errors or timeouts that appear after an upgrade, especially one to 2025.10 or later. The 2025.10 release notes expect roughly 50% more PostgreSQL connections because Redis is gone. Count connections per database user, compare them with the server's configured limit, and check how many server and worker containers each connect. Ask whether a connection pooler such as PgBouncer sits in front of the database and whether it is in the path for all clients.
Worker backlog from background tasks
The symptom is delayed emails, late directory syncs, or events that appear in the UI minutes after they happened. Background work runs in the worker container and, since 2025.10, its queue lives in PostgreSQL. Check the worker logs for repeated failures or long-running tasks, and look at how many tasks are waiting. A backlog often means workers are short on concurrency, are blocked by a slow query, or have lost their database connection.
Event and log tables without retention
The symptom is a gradual slowdown over weeks, with admin event lists taking longer to load and disk usage climbing. Audit events are stored in PostgreSQL, so tables grow with every login and configuration change unless retention is applied. Check the row counts of the event and task tables, the age of the oldest rows, and whether a cleanup task is running. Confirm the retention settings in your version before deleting anything, and take a backup first.
Undersized host or database
The symptom is steady high CPU, memory pressure or swapping that worsens with user count, rather than a single bad query. The Docker Compose guide starts at 2 CPU cores and 2 GB of RAM and positions Compose for test and small production setups. The Kubernetes guide recommends a separately managed PostgreSQL for production instead of the bundled demonstration database. Compare host metrics against the load you see at peak logins before adding capacity, and ask your database team what memory and I/O the instance is sized for.
Why connection counts rose after the Redis removal
The first thing to know is that authentik 2025.10 stopped using Redis entirely. Caching, background tasks, sessions and WebSocket functions moved into PostgreSQL, so the database now carries work that used to sit in a separate service. The 2025.10 release notes warn of roughly 50% more PostgreSQL connections after the upgrade. If your connection count jumped at that point, the cause is usually the architecture change, not a bad query. Before you open a slow query investigation, compare the current number of connections from the authentik server and worker containers with the connection limits configured on your database and any pooler in front of it. Check the server-side max_connections setting and the pool size your deployment passes to authentik. If usage sits close to the ceiling, connection exhaustion can look like slow logins even when every query is fast.
Worker count and worker entrypoint both shape that budget. Each worker container opens its own connections, so adding workers to clear a task backlog also adds connection load on PostgreSQL. The authentik 2026.5 release notes describe a Rust worker entrypoint that uses about 200 MB less memory per worker container and one fewer PostgreSQL connection per worker. Those savings are per container, so a fleet of workers can change the total meaningfully. Confirm which entrypoint your running version uses and whether your deployment has opted into it, because a Docker Compose file or Helm values set for an earlier release may still start the older worker. Record the worker count, the entrypoint and the database connection total together before and after any change so you can tell whether a scaling decision helped or simply moved the pressure onto the database.
Which fix matches which bottleneck
This table pairs each common slow-authentik bottleneck with the signal that points to it, the fix that addresses it and the trade-off to weigh before changing anything. Read it after you have confirmed which bottleneck the database and worker metrics actually show, since several rows can look alike from the login page.
| Bottleneck | Signal | Fix | Trade-off |
|---|---|---|---|
| Slow individual queries | A small number of statements dominate query time in PostgreSQL statistics or the slow-query log, often on event or session tables | Query and index work on the database, guided by authentik's slow-query troubleshooting steps | Changes need careful testing, and tuning tied to specific queries can break when authentik versions change |
| Connection exhaustion | Connection counts sit near the configured limit, and logins fail or stall after upgrading to 2025.10 or later, which expects roughly 50% more connections | A connection pooler such as PgBouncer between authentik and PostgreSQL | Pooling mode must be compatible with how authentik uses connections, so confirm this with the authentik and PgBouncer documentation before switching |
| Read load on the primary | The primary's CPU or I/O is high from read-only queries while writes are modest | A hot standby replica to serve read-only queries | authentik writes still go to the primary, and PostgreSQL does not detect primary failure or fail over on its own, so external failover tooling is needed |
| Worker backlog | Background tasks queue up, and notifications, syncs or email arrive late while the server looks healthy | More worker containers or better-sized workers, with the 2026.5 Rust worker entrypoint as one option to evaluate | Each worker adds PostgreSQL connections, so raise the connection budget and pooler capacity together |
| Event table growth | The events table grows steadily, and queries that read it slow down over time | Event retention and pruning settings, reviewed against your log and SIEM forwarding | Pruned events are gone from the database, so export them to your log store or SIEM first if you need audit history |
How to find the slow query before changing settings
This sequence moves from version and connection checks to a confirmed slow query and its plan, so the fix targets the actual cause rather than a guessed setting.
Take a database backup first
Before you change any setting or run any diagnostic that alters state, take a full PostgreSQL backup of the authentik database and confirm it restores. Whoever owns the database (usually the platform or DBA team) runs this step, and the done check is a backup file you have test-restored to a separate host. Keep the backup until the fix is verified in production.
Confirm the authentik version and upgrade history
Record the running authentik version from the admin interface or the server container image tag, then note the date of the last upgrade. Releases are named by year and month, so the version tells you how far back to look. If you upgraded across 2025.10, the release notes for that version say authentik moved caching, tasks, sessions and WebSockets from Redis into PostgreSQL and expects roughly 50% more database connections. A slowdown that began right after that upgrade points you toward connection pressure first. Done when you have the version, the upgrade date and a yes or no answer on whether the 2025.10 change falls within your timeline.
Compare current connections with the configured limit
Ask the database for its maximum connection setting and count the connections in use, grouped by client and state. Include the server and worker containers, and any pooler, since each worker and server opens its own pool. The authentik 2026.5 release notes say the Rust worker entrypoint uses one fewer PostgreSQL connection per worker, so the worker version affects this count. Done when you know the headroom between active connections and the limit, and whether connections sit idle or waiting.
Enable slow-query logging and reproduce the slow login
Follow the logging steps in the authentik slow-queries guide to turn on PostgreSQL slow-statement logging with a threshold you choose. Then reproduce one slow login or admin page load while someone watches the timing. Note the time and the user or flow involved so you can match log lines to the request. Done when the PostgreSQL log contains statements from that window that exceed the threshold, and you have saved a copy of the log excerpt.
Identify the query and read its plan
Find the repeated or longest statement in the log excerpt and run EXPLAIN ANALYZE on it in a non-production copy with similar data. Look for sequential scans on large tables, nested loops over many rows and estimates far from actual row counts. Check whether the table is an authentik event or audit table. Done when you can name the table and the operation that dominates the time, and you can state whether the problem is a single expensive query or many small ones.
Check the worker backlog and event table size
Open the authentik admin interface's task view to see whether background tasks are queued or failing, and check the worker container logs for the same period. Then measure the size of the largest event-related tables and the retention settings that govern them. A growing backlog or very large event tables suggests the slowdown comes from housekeeping rather than from login logic. Done when you have a queue state (clear, growing or stuck) and table sizes recorded alongside the event retention setting.
Choose the fix from the options table
Only now select a change from the options table, matching it to the cause you confirmed: connection limits or pooling for connection pressure, a query or index change for a specific slow statement, worker capacity for a backlog, or event retention for large tables. Apply one change at a time in a test environment, repeat the reproduction step and compare the timing and connection counts with your baseline. Done when the reproduced login is faster and the metrics you recorded have moved in the expected direction.
Fixes by deployment: Compose, Kubernetes and managed PostgreSQL
The authentik Docker Compose guide positions Compose for test setups and small-scale production, and it calls for a host with at least 2 CPU cores and 2 GB of RAM. On a host that tight, the server, worker and PostgreSQL containers compete for the same CPU and memory, so slowness often comes from the host rather than from a single query. Confirm first whether PostgreSQL runs on the same host as authentik and whether the host has headroom under load.
- Host resources: Check CPU and memory use during a slow login. If the host is swapping or pinned at full CPU, the database and workers are starved regardless of query quality.
- Shared database container: Confirm whether the PostgreSQL container uses a volume on the same disk as the rest of the stack. Shared disk I/O can slow every write, including session and task writes that PostgreSQL now handles.
- Container limits: Look for memory or CPU limits in the Compose file that throttle the database container.
- Worker count: Confirm how many worker containers run. Each one holds PostgreSQL connections, so adding workers on a small host can make the database the bottleneck.
- Split point: If the host is too small, the usual fix is a larger host or a separate database host, not tuning queries alone.
Confirm the host size against the current Compose guide before you resize, and record the baseline so you can compare after the change.
The authentik Kubernetes guide installs with Helm and states that the PostgreSQL bundled with the chart is for demonstration and test environments. It recommends a separately managed PostgreSQL for production. The first question in a slow cluster is therefore whether the database is the chart's bundled instance or an external service, because the tuning options, storage and failure behavior differ.
- Database origin: Check the values file for the database settings and confirm whether the bundled instance is still in use.
- Storage class: For a bundled database, confirm the persistent volume type and its IOPS, since slow storage shows up as slow logins.
- Replica count: Confirm how many server and worker pods run. Each pod opens database connections, so scaling pods can raise the connection count sharply after the 2025.10 change.
- Resource requests and limits: Check whether the database and worker pods are throttled by CPU limits, which can cause latency that looks like a query problem.
- Network path: For an external database, confirm the pods reach it over a stable route and that no proxy or network policy adds latency.
If the database is still the bundled instance in a production cluster, plan the move to a managed or separately operated PostgreSQL before tuning further.
A separately managed or cloud PostgreSQL moves the database out of the authentik host or cluster. Performance then depends on instance sizing, connection limits, storage and any pooler placed in front. Most slowness here comes from connection exhaustion or an undersized instance rather than from authentik itself, so ask the provider or your database team for these values before changing authentik settings.
- Instance size: Confirm CPU and memory of the instance and whether it is shared with other applications.
- Connection limit: Compare the provider's maximum connection setting with the total connections from all authentik servers and workers, since the 2025.10 release expects roughly 50% more connections than before.
- Storage performance: Confirm the storage type and provisioned throughput, because session, cache and task writes now go through PostgreSQL.
- Pooler placement: Check whether a pooler such as PgBouncer sits in front of the instance, and whether it runs in a mode that suits authentik's connection use.
- Monitoring access: Confirm you can read slow query logs and connection metrics from the provider console, so you can verify each change.
Before changing any setting, confirm which team owns the database, its maintenance windows and its backup policy.
Keeping the database safe while tuning
Back up before you change anything in the database, and test every schema or index change on a copy first. authentik keeps all configuration and data in PostgreSQL except uploaded files, so a poorly considered index, a manual update to a table or a failed migration can affect logins for every application. Take a verified backup, confirm you can restore it, and make changes through authentik's own interfaces, blueprints or supported commands rather than editing its tables by hand. Ask your team to name who may run ad hoc SQL against the production database, and log those sessions.
Treat minor and major PostgreSQL upgrades as different kinds of work. Minor releases do not change the internal storage format, so applying one means replacing executables and restarting the server, which is a routine patch. Major upgrades need a dump and restore, pg_upgrade, or logical replication. The PostgreSQL upgrading documentation describes logical replication as allowing a major upgrade with only several seconds of downtime, which is why it is worth planning on a standby before you need it. Confirm which PostgreSQL major version your authentik release supports before you schedule that work.
Do not let a tuning change block security patching. authentik's security policy lists 2026.5.x and 2026.8.x as the supported versions receiving security fixes, and the project announces security releases at least 24 hours in advance. Keep the upgrade path open by recording every database change in your change log so it can be reverted or reapplied during a patch window. If a tuning experiment needs a database restart or a long-running index build, schedule it outside the window you would need for an emergency update, and confirm your on-call team can apply an authentik release within that announced notice period.
What to confirm in your environment
Most slow-login problems trace back to limits that sit outside authentik itself: how your connection pooler behaves, where reads and writes go, how your database platform handles failover, and how long event data is kept. Confirm each of these with the team that owns the database before you change any settings.
Pooler compatibility with authentik
A connection pooler such as PgBouncer can cut the number of server connections authentik opens, but it changes how sessions and transactions are handed out. Ask your database team which pooling mode is planned and whether it has been tested against authentik's connection and transaction behavior. Confirm the approach with the authentik documentation and with your own test results before routing production traffic through it.
Replica lag and write routing
A hot standby can serve read-only queries, but replication is not instant, so a read sent to a replica may return data that is slightly behind the primary. Ask your team how much lag is normal and whether any monitoring alerts on it. Confirm with authentik that all writes, including sessions and tasks, still reach the primary, because a read-only replica cannot accept them.
No built-in automatic failover
PostgreSQL does not detect a failed primary or promote a standby on its own, so a database outage can stop logins until someone or some tool intervenes. Ask your platform team which external tool or managed service performs failover, how long promotion takes in your environment, and whether authentik reconnects cleanly afterward. Test this during a planned window rather than during an incident.
PostgreSQL support window
Each PostgreSQL major version receives support for a fixed period, and the version your authentik database runs sets when you must upgrade. Version 14 is supported until November 12, 2026, while version 18 is supported until November 14, 2030. Ask your database team which major version is running, when it leaves support, and how the planned upgrade will be tested against authentik before the cutoff.
Event retention and audit needs
Authentik stores audit events in the database, and the retention period controls how much history is available when a slow query or a compliance question arrives. Shortening retention can reduce table size and speed up cleanup, but it can also remove evidence your audit or incident process needs. Ask your security and compliance leads how long events must be kept, where they are forwarded, and whether the forwarded copy is complete before local data is trimmed.
Managed PostgreSQL limits
A managed PostgreSQL service can cap connections, restrict certain extensions, or apply its own maintenance windows and failover behavior. These limits can conflict with the connection count you need after the Redis removal in authentik 2025.10. Ask your platform team for the connection ceiling on the plan you will use, which extensions are available, how minor and major upgrades are scheduled, and whether the provider's failover is compatible with your recovery targets.
Common questions about slow authentik performance
How much does it cost to get a slow authentik diagnosed?
The fee follows from the written scope, and DeployOpen does not publish a price list. The main cost drivers are how much access the work needs (the authentik server and worker logs, metrics, and the PostgreSQL instance), how much database time is required, and how many fixes are in scope. A diagnosis-only engagement costs less than one that also tunes indexes, adds a pooler, or changes worker settings across several environments. Ask for a quote that separates the diagnosis from each fix, states what access is assumed, and names what happens if the root cause sits outside authentik, such as in the network or the database host. Diagnosis is usually a one-time cost, while any retainer for monitoring or upgrades recurs.
How long does it take to find and fix slow logins?
Duration depends on three things: how quickly the team can get read access to logs and metrics, how reliably the slowdown can be reproduced, and how large the fix is. A missing index or a worker backlog caused by a retention setting is usually smaller work than a change to connection handling or database topology. Because no duration is supplied for this work, ask for the timeline in the written scope, with a stated start point (access granted), the reproduction step, and the change window needed for the fix. Confirm early whether a test copy of the database is available, since reproducing load on production data is often the slowest step.
Can our own team diagnose slow authentik without a partner?
Yes, if the team has database access and can run the diagnostic steps in the authentik troubleshooting guide for slow PostgreSQL queries. Start by checking the PostgreSQL slow query log and active connections, then compare connection counts against the database connection limit, and review worker task backlog and event table size. Teams without a PostgreSQL administrator often find the query plans and lock waits the hardest part, so a partner can help there. Many organizations keep the diagnosis in-house and bring in outside help only for the fixes that touch the database layout or the deployment.
What does the work need from our team?
Plan for four inputs. First, read access to authentik and PostgreSQL logs and to any metrics you already collect. Second, time from a database administrator who can run queries, check configuration, and approve index or connection changes. Third, a test copy of the database, ideally restored from a recent backup, so that fixes can be measured without risking production logins. Fourth, a change window for the fix itself, since some database and deployment changes need a restart. Ask the provider to list these inputs in the scope so the schedule depends on items you control.
Does authentik still need Redis for better performance?
No. authentik no longer uses Redis. The 2025.10 release moved caching, tasks, sessions and WebSocket functions to PostgreSQL, and the release notes warned of roughly 50% more PostgreSQL connections after upgrading. That means slowness after the upgrade is often a database connection or query issue, not a missing cache. Do not add Redis back as a fix. Instead, review the connection count, the worker configuration, and the slow query log, and confirm the change against the authentik 2025.10 release notes for your version path.
Is a read replica or connection pooler always required?
No. A replica or pooler helps only when the diagnosis shows a matching bottleneck. A pooler such as PgBouncer can reduce the cost of many idle connections, while a hot standby can take read-only queries away from the primary. Neither fixes a missing index, a long-running query, or a worker backlog caused by event retention. Replicas also add operational work, including replication monitoring and a plan for failover, because PostgreSQL does not detect primary failure on its own. Decide after the diagnosis, and confirm with authentik's architecture and deployment guides which connections a pooler can safely sit between.
How DeployOpen scopes and delivers authentik performance work
DeployOpen approaches slow authentik and PostgreSQL performance as a scoped investigation: we agree what is measured, what changes and what is handed back before work starts. The work runs inside your own infrastructure, so the database, workers and logs stay under your control throughout.
How we scope
- Agree in writing which slow logins or admin pages are in scope and what counts as fixed.
- Confirm the authentik version, PostgreSQL version and whether a pooler or replica already exists.
- Define the evidence to collect, such as slow query logs, connection counts and worker queue depth.
How we build
- Reproduce the slow path and capture slow query data before changing any configuration.
- Test connection limits, pooling and event retention changes in a staging copy of your deployment first.
- Review each change against the authentik release notes for the version you run.
How we hand over
- Deliver a written findings report with the query evidence, the changes made and their rollback steps.
- Document the settings, retention values and monitoring signals your team should watch after handover.
- Walk your platform and database owners through the runbook so they can repeat the diagnosis.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer for changing workloads.
- Ask any quote to separate the one-time investigation from recurring support and retainer effort.
