# Evaluate moving Rails session storage off PostgreSQL for high-concurrency deployments **URL:** \ **Category:** Development\ **Created:** [April 22, 2026, 3:08pm UTC](https://community.zammad.org/t/evaluate-moving-rails-session-storage-off-postgresql-for-high-concurrency-deployments/20115 "2026-04-22T15:08:08Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![UdoLlorens](https://community.zammad.org/user_avatar/community.zammad.org/udollorens/32/11819_2.png) [@UdoLlorens](https://community.zammad.org/u/UdoLlorens)\ **Post date:** [April 22, 2026, 3:08pm UTC](https://community.zammad.org/t/evaluate-moving-rails-session-storage-off-postgresql-for-high-concurrency-deployments/20115/1 "2026-04-22T15:08:08Z")
Hello Zammad team, We would like to share an anonymized production finding and ask you to evaluate whether session handling can be improved for write-heavy environments. In one of our production systems, PostgreSQL session writes dominate SQL time. The main statement in `pg_stat_statements` is: ```sql UPDATE "sessions" SET "data" = $1, "updated_at" = $2 WHERE "sessions"."id" = $3 ``` In our workload, this statement accounts for roughly `75%` of total SQL execution time. That makes it the clearest database hotspot we found. **Anonymized evidence** - `UPDATE sessions ...` - Other expensive patterns exist too, mainly around ticket lists, tags, and taskbars, but session writes are the dominant cost. We also validated that this is not a missing-index problem: - primary-key reads are fast, - common ticket filters already use indexes, - the issue is the frequency and cost of repeated session writes. **Why we are raising this** Zammad is a Rails application, and Rails supports multiple session storage strategies. For high-concurrency or UI-heavy deployments, PostgreSQL-backed sessions may create unnecessary write amplification. Because of that, we would like you to evaluate one of these directions: 1. move session storage from PostgreSQL to Redis-backed storage, or another non-relational Rails-supported backend, 2. if that is not appropriate for the architecture, reduce or eliminate redundant session writes when the session payload has not materially changed. **Why we think this matters** - It would remove a high-frequency write path from the primary database. - It could reduce latency under heavy UI usage. - It would lower write pressure on PostgreSQL, which is already handling the ticket workload. - It would be especially useful for installations with many concurrent agents and many short UI requests. **What we would like you to review** - Can the session store be moved away from PostgreSQL in a safe, supportable way? - If not, can Zammad avoid writing the session record on every request when nothing material changed? - Are taskbar, websocket, or notification flows indirectly increasing session churn? - Is there a better Rails-native approach for sessions in Zammad’s deployment model? **Related community threads** We looked for prior reports before posting and found adjacent discussions, but not an exact match for this write-amplification pattern: - [How is session and user connected?](https://community.zammad.org/t/how-is-session-and-user-connected/14091) - [Zammad is exhausting resources](https://community.zammad.org/t/zammad-is-exhausting-resources/5616) - [Schedule Clear all session](https://community.zammad.org/t/schedule-clear-all-session/6298) - [Trouble with performance tuning (high reported user count and RAM usage)](https://community.zammad.org/t/trouble-with-performance-tuning-high-reported-user-count-and-ram-usage/17577) These threads suggest sessions are already a known operational topic, but we did not find a prior discussion that specifically addresses `sessions` writes dominating SQL time in a busy production workload. **Acceptance criteria** - Fewer `UPDATE sessions` statements in normal usage. - No regression in login, logout, invalidation, or security behavior. - Lower PostgreSQL write pressure under concurrent operator traffic. - Clear documentation of the chosen approach and its tradeoffs. **Additional note** We are happy to share more anonymized details if helpful, including: - aggregated `pg_stat_statements` output, - `EXPLAIN ANALYZE` for the main query patterns, - checkpoint/WAL observations, - request-path samples with all identifiers removed. Thank you for considering this. ---
**Author:** ![dominikklein](https://community.zammad.org/user_avatar/community.zammad.org/dominikklein/32/8144_2.png) [@dominikklein](https://community.zammad.org/u/dominikklein)\ **Post date:** [April 22, 2026, 5:27pm UTC](https://community.zammad.org/t/evaluate-moving-rails-session-storage-off-postgresql-for-high-concurrency-deployments/20115/2 "2026-04-22T17:27:21Z")
How many concurrent users are working on the system in your case? I think we should maybe check in which situations the session is updated, maybe this could be an first step of improvement, before going deeper in the bigger picture of having a alternative session management. ---
**Author:** ![UdoLlorens](https://community.zammad.org/user_avatar/community.zammad.org/udollorens/32/11819_2.png) [@UdoLlorens](https://community.zammad.org/u/UdoLlorens)\ **Post date:** [April 22, 2026, 9:28pm UTC](https://community.zammad.org/t/evaluate-moving-rails-session-storage-off-postgresql-for-high-concurrency-deployments/20115/3 "2026-04-22T21:28:13Z")
We measured our concurrency for last week and current week and the numbers are as follows and stable: - total users: 20 - average concurrency: 9.65 - median: 10 - p95: 16 - peak: 19 - unique IPs seen: 67 - API requests counted: 107,125 Happy to collect different kind of metrics, perhaps more controlled on non-prod hours with single users and actions to correlate. If you could provide some guidance as to what can be meaninful to the team I’m happy to accomodate if it’s within our grasp. ---
**Author:** ![dominikklein](https://community.zammad.org/user_avatar/community.zammad.org/dominikklein/32/8144_2.png) [@dominikklein](https://community.zammad.org/u/dominikklein)\ **Post date:** [April 23, 2026, 5:46am UTC](https://community.zammad.org/t/evaluate-moving-rails-session-storage-off-postgresql-for-high-concurrency-deployments/20115/4 "2026-04-23T05:46:17Z")
Ok, this is not much in the end.