authentik is an open source Identity Provider that unifies your identity needs into a single platform, replacing Okta, Keycloak, and Ping. Authentik Security is a public benefit company building on top of the open source authentik project.

---

In our 2025.10 release, we removed Redis as a required database. In this blog, we’ll go over why we made that decision, why we wanted Redis in the first place, and how we went about removing Redis and instead relying fully on PostgreSQL.

In the software world, databases are often the unsung heroes, and decisions about their usage, schemas, and data storage practices are important, so we want to share our thinking behind this decision.

Why Redis originally?​

Redis has for a long while been the obvious choice for frequently accessed data for performance reasons. After it’s introduction in 2009, the Redis in-memory database became the standard for managing frequently accessed data. It’s an in-memory database, so it’s very fast at storing and retrieving small data objects temporarily in cache or as ephemeral real-time state with low-latency on returns. Because Redis stores data in RAM, it can serve requests in sub-millisecond time.

Speed is important in any user-facing application. When you log in through authentik, the server can transact with multiple back-end data sources and the need to store and access information quickly, during a single authentik flow, made Redis the natural choice when we first began.

Why remove Redis now?​

It’s not just us. While our move away from Redis was driven by technical reasons, many major cloud providers have also done so, primarily in response to the 2024 licensing changes, as well as concerns over the high costs for larger datasets.

While neither of those were our concerns, we did start to think about what future changes might be coming from Redis… and decided to move off now and not wait to find out. Even after Redis back-pedaled and introduced an open-source license, the fragmentation and loss of trust caused by the initial change caused cloud providers to continue to use Valkey, the open source version that was started after the 2024 license change.

Additionally, our customers are very keen on high availability cross-region access and stability. Redis’ HA setup is challenging, and requires customization. We also have a polyglot product, so we had to configure multiple methods, in multiple languages, to connect Redis to both Go and Python. Plus different libraries for HA sharding. It was a lot.

Moving off Redis simplified our architecture; one fewer piece to manage.

We keep the fact that authentik is self-hosted top-of-mind. Specifically and intentionally, we have fewer dependencies and less complexity so that our home labbers (and all customers!) don’t have to support an overly large stack. Our goal is to simplify, not support complexity, so that we can focus on providing a reliable self-hosting stack for our users and customers.

What was the process of removal?​

We actually started the process of removing Redis way back in our 2024.6 release (Yes, over a year ago), when we switched to using PostgreSQL advisory locks instead of Redis locks.

Then in 2025, we did a little more in each release, starting with our 2025.4 release (April), and completed the work in our 2025.10 (October). So it took us four releases total; something that major should not be rushed.

The Redis —> PostgreSQL migration process, spread over the releases, looked like this:

• Started using PostgreSQL locks (2024.6)
• Moved session storage to database, not cache (2025.4)
• Revamped the authentik worker and background tasks for better observability and configurability of scheduled tasks (2025.8)
• Migrated caching, the embedded outpost, and WebSocket inter-process communication to PostgreSQL, fully removing the need for Redis (2025.10)

Any downsides?​

Not many so far, only two worth noting:

RAC provider: there was a hit to our RAC (Remote Access Control) provider performance, because the latency (the overhead of moving the data through the stack) is slightly higher with PostgreSQL. (This is a strength of Redis, yes.) We anticipated this and, frankly, it just means that we now plan to accelerate some related work that we want to do to improve RAC speed.

Websockets: we actually lost some performance here. Our RAC remote access was impacted because the amount of data going through PostgreSQL and the increased disk usage, but we were willing to do this for all the other benefits. (PostgreSQL was not built for this; Redis PubSub was purpose built for it). It’s interesting to note that others with heavy use of websockets have moved away from PostgreSQL TO Redis, because of the increased disk usage. One is example is Immich, as detailed in this pull request: “PostgreSQL NOTIFY is cursed”.

How is authentik managing the data now?​

So now everything is stored in PostgreSQL, same as before, except media files which were never stored in Redis anyway. Our data and security policies remain the same as ever. Data management for a self-hosted IdP solution is, in our minds, a clear case of “simple is better”.

As we stated in the 2025.10 Release Notes, if your PostgreSQL instance requires a TLS connection, authentik now requires TLS 1.3 or the Extended Master Secret extension to connect to PostgreSQL.

What about performance, or other benefits?​

Even though we can’t claim huge wins across the board strictly in performance, there are several points where performance has improved, and others where there are other benefits that add to a collective improvement.

User sessions: this is an area where we saw definite improved performance. We joined specific rows to obtain more relations in memory, for faster processing later. These joins save 2 to 3 queries per request, and fewer queries means faster processing because we avoid several round-trips to the database.

Background tasks: moving these to PostgreSQL wasn’t about performance, but does provide us better insight and observability of these tasks, and better configurability of scheduled tasks.

Locks: switching to using PostgreSQL advisory locks (used to manage access to application-defined resources) though this is not a performance issue it is an interesting detail worth knowing, we think.

Caching: we use caching only for expensive computations; though we have always done this, even when we used Redis, famous for caching. Because we are not caching API responses or database queries, authentik is still more performant with its cache stored in PostgreSQL than without any caching at all.

Let us know your thoughts​

We always want to hear feedback on our decisions and directions; let us know what you think about authentik moving to only PostgreSQL. Does it impact your setup? Add any benefits beyond those that we discussed above?

The authentik community is the most valuable part of authentik, we believe, so with every move we make (especially big ones like this) we think of what’s best for our community and users.