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:
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 ...483,718calls98.66M mstotal execution time203.96 msmean execution time73.55%of total SQL time in the sample window
-
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:
- move session storage from PostgreSQL to Redis-backed storage, or another non-relational Rails-supported backend,
- 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?
- Zammad is exhausting resources
- Schedule Clear all session
- Trouble with performance tuning (high reported user count and RAM usage)
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 sessionsstatements 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_statementsoutput, EXPLAIN ANALYZEfor the main query patterns,- checkpoint/WAL observations,
- request-path samples with all identifiers removed.
Thank you for considering this.