issue: Updating large chats is slow #4924

New Issue

2025-11-11T16:06:41-06:00

GiteaMirror commented

2025-11-11 16:06:41 -06:00

Originally created by @crizCraig on GitHub (Apr 21, 2025).

Check Existing Issues

I have searched the existing issues and discussions.
I am using the latest version of Open WebUI.

Installation Method

Git Clone

Open WebUI Version

0.5.20

Ollama Version (if applicable)

No response

Operating System

macOS Sonoma

Browser (if applicable)

No response

Confirmation

I have read and followed all instructions in README.md.
I am using the latest version of both Open WebUI and Ollama.
I have included the browser console logs.
I have included the Docker container logs.
I have listed steps to reproduce the bug in detail.

Expected Behavior

Chat updates should be partial consisting of just the edited messages, especially for large chats. This will keep the database and CPU resources free to serve other requests and maintain app snapiness.

We could use jsonb_set which would lead to much less network i/o and scan time. Here's a link to my most frequent slow queries, of which the top four are all chat updates / inserts that could be optimized with jsonb operations.

Since postgres always writes an entirely new row for updates, it may be best to normalize chats into multiple chat_messages. This will save disk i/o as well as network i/o and reduce vacuum pressure from huge inserts. It may also be worth considering using the STORAGE_PROVIDER for super large chats (treating them as files like claude does).

Actual Behavior

We currently update the entire JSON chat.chat object for every message (I'm using PostGres)

Steps to Reproduce

Ask a model for a long story
Send a follow up message about the store and note the time to update the chat in the DB

This query is useful for me to find slow operations

-- CREATE EXTENSION pg_stat_statements;
SELECT
    query,
    calls,
    total_exec_time / calls as avg_time,
    min_exec_time,
    max_exec_time
FROM pg_stat_statements
ORDER BY calls DESC
LIMIT 50;

Logs & Screenshots

Sheet referenced earlier with slow queries
https://docs.google.com/spreadsheets/d/1KdZw7Chu6rki1oVbQ3Y-cFjGe2Q5GRNA5I6_4TSXeO0/edit?gid=125432246#gid=125432246

Additional Information

No response

Originally created by @crizCraig on GitHub (Apr 21, 2025). ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Git Clone ### Open WebUI Version 0.5.20 ### Ollama Version (if applicable) _No response_ ### Operating System macOS Sonoma ### Browser (if applicable) _No response_ ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have listed steps to reproduce the bug in detail. ### Expected Behavior Chat updates should be partial consisting of just the edited messages, especially for large chats. This will keep the database and CPU resources free to serve other requests and maintain app snapiness. We could use `jsonb_set` which would lead to much less network i/o and scan time. Here's a [link](https://docs.google.com/spreadsheets/d/1KdZw7Chu6rki1oVbQ3Y-cFjGe2Q5GRNA5I6_4TSXeO0/edit?gid=125432246#gid=125432246) to my most frequent slow queries, of which the top four are all chat updates / inserts that could be optimized with jsonb operations. Since postgres always writes an entirely new row for updates, it may be best to normalize chats into multiple `chat_messages`. This will save disk i/o as well as network i/o and reduce vacuum pressure from huge inserts. It may also be worth considering using the `STORAGE_PROVIDER` for super large chats (treating them as files like claude does). ### Actual Behavior We currently update the entire JSON `chat.chat` object for every message (I'm using PostGres) ### Steps to Reproduce 1. Ask a model for a long story 2. Send a follow up message about the store and note the time to update the chat in the DB This query is useful for me to find slow operations ```sql -- CREATE EXTENSION pg_stat_statements; SELECT query, calls, total_exec_time / calls as avg_time, min_exec_time, max_exec_time FROM pg_stat_statements ORDER BY calls DESC LIMIT 50; ``` ### Logs & Screenshots Sheet referenced earlier with slow queries https://docs.google.com/spreadsheets/d/1KdZw7Chu6rki1oVbQ3Y-cFjGe2Q5GRNA5I6_4TSXeO0/edit?gid=125432246#gid=125432246 ### Additional Information _No response_

GiteaMirror added the bug label 2025-11-11 16:06:41 -06:00

GiteaMirror closed this issue

2025-11-11 16:06:41 -06:00

GiteaMirror referenced this issue

2025-11-11 17:52:26 -06:00

[PR #4924] [MERGED] fix: stop system prompt being duplicated #8382

GiteaMirror referenced this issue

2026-04-20 03:35:53 -05:00

[PR #4924] [MERGED] fix: stop system prompt being duplicated #21586

GiteaMirror referenced this issue

2026-04-25 10:47:22 -05:00

[PR #4924] [MERGED] fix: stop system prompt being duplicated #37216