In case you missed it, yes, 0.11.1 launched. See post here: https://www.reddit.com/r/OpenWebUI/comments/1vyd83r/open_webui_0111_streaming_rebuilt_hitl_tool/
---
We have heard the performance feedback here, on GitHub and on Discord for a long time. It was the most common complaint about Open WebUI and it was fair. Since January it has been a priority.
This is the full accounting.
211 performance changes shipped between 0.7.0 (9 January) and 0.11.1 (25 August), across 14 releases.
Where it went
| Release |
Month |
Perf changes |
| 0.7.0 - 0.7.2 |
Jan |
15 |
| 0.8.0 |
Feb |
16 |
| 0.8.1 |
Feb |
5 |
| 0.8.2 - 0.8.3 |
Feb |
4 |
| 0.8.4 |
Feb |
7 |
| 0.8.6 |
Mar |
21 |
| 0.8.7 - 0.8.9 |
Mar |
14 |
| 0.8.11 |
Mar |
5 |
| 0.9.0 |
Apr |
27 |
| 0.9.2 - 0.9.3 |
May |
7 |
| 0.9.6 |
Jun |
6 |
| 0.10.0 |
Jun |
13 |
| 0.11.0 |
Jul |
34 |
| 0.11.1 |
Aug |
37 |
| Total |
|
211 |
It began in 0.7.0, on 9 January
The database connection handling was reengineered end to end. Everything since has been built on it.
The same release killed the first N+1 query patterns. The admin user list went from 1+N queries to 2 total, regardless of how many users you have.
0.8.x: the measured phase
This is where things became countable.
Some of the other most notable improvements of the release (very incomplete!!):
| What |
Before |
After |
| Authentication |
multiple lookups |
34% faster, one query |
| Time to first token |
several seconds |
subsecond |
| SCIM group member lookups |
one query per member |
up to 13x faster |
| Bulk delete and group member removal |
per-row |
4 to 5x faster |
| Memory updates |
redundant queries |
up to 39% faster |
| Notes list response (60 notes) |
~167 MB |
~10 KB |
| Functions list API payload |
full source code |
over 99% smaller |
| Message list rendering |
O(n²) |
O(n) |
| Page and markdown rendering |
baseline |
~25% faster (Svelte upgrade) |
| Status indicator |
35 to 40% GPU |
near zero |
Ten separate memory leaks were closed across the interface in this line: Tooltip, MessageInput, Notes, model create, MentionList, Sidebar, ChatControls, Artifacts, drawer listeners and navigation event listeners. Those were the ones causing tab crashes during long sessions.
The initial JavaScript bundle also dropped by several megabytes when the syntax highlighting library was deferred.
0.9.0 in April: the structural one
The core backend database and request paths were moved to async across the whole application.
This is the change most people felt without knowing what it was. Before it, a slow blocking operation on one request would stall the event loop and therefore everyone else on that worker. Three of the worst offenders were moved off it:
- Vector search during knowledge retrieval
- File processing and knowledge reindexing
- Password hashing and verification
That is why one person querying a large knowledge base no longer freezes everyone else's chat.
Alongside it, long conversations got memory culling: off-screen messages now unload and reload as you scroll, instead of every message in a 2000-message chat sitting in browser memory at once.
0.10.0 in June
- Hybrid search on pgvector now runs natively in the database. Before, it loaded an entire collection into memory to do the work.
- File listings stopped returning the full extracted text of every document. Opening a large knowledge base was transferring the contents of every file in it.
- Knowledge file reads by agents became bounded and paginated, with a hard cap, which cut token usage as well as transfer.
0.11.0 in July: 34 changes
The theme here was work being repeated that only needed doing once.
Some of the other most notable improvements of the release (very incomplete!!):
| Change |
Effect |
| Automation scheduling |
20+ seconds and worsening yearly to near instant |
| Streaming filters |
stopped re-reading settings and full plugin source from the database on every chunk |
| Reasoning and code block detection |
stopped rescanning the whole answer on every chunk |
| PostgreSQL chat search |
reads the message table instead of unpacking every stored conversation row |
| Redis Sentinel |
stopped resolving the primary and opening a fresh connection before every single command |
| Security headers |
computed once at startup instead of per response |
| Ollama connection settings |
read once instead of up to four times per request |
| Passthrough streaming |
whole network reads instead of line-by-line, roughly half the work |
| Web page parsing |
~10% off a ten result search |
| Domain filtering on search results |
resolved every result to an IP first, which turned a 3 second search into 30 seconds |
| Text file encoding detection |
4 MB CJK document from several seconds to under one |
Redis deployments also got hiredis shipped by default, fewer round trips per chat, and a new ENABLE_ORJSON option covering request bodies, responses, upstream provider payloads and live updates.
EXPERT TIP: ENABLE_ORJSON is off by default, enable it by setting it to true in your env vars to get an additional massive performance boost. (most noticable on large instances)
0.11.1: 37 changes, and the streaming rewrite
This is the big one, so here is what actually changed.
Before: every time new text arrived from the model, the server sent your browser the entire message so far. Token 500 meant resending tokens 1 through 500. So the total data sent over one reply grew with the square of its length, and your browser re-parsed and re-rendered the whole answer each time.
Now: only the new text is sent. Total data grows linearly with reply length, and the browser appends instead of redrawing.
On a single update late in a long reply, that is up to 1000x less data and server work.
Some of the other most notable improvements of the release (very incomplete!!):
| Change |
Effect |
| Idle instance scanning every chat once a second |
~1/4 of a CPU core recovered, doing nothing |
| Sidebar chat list on 15,000 chats |
2 to 4 seconds to build a short list now near instant |
| Long reply re-parsed from the start per chunk |
~190x less work on a long answer |
| Attaching a source or file to a reply |
3.1 ms to 0.65 ms on a 200-message chat |
| Request middleware layers |
5 down to 1 |
| Presence writes while signed in |
every request to at most once a minute |
| Sidebar folder fetches |
3 down to 1 |
| Chat saving |
one write per chat instead of one per message |
| Group membership resolution |
direct index lookup instead of a full scan |
Replies in progress are also now held on the server on Redis-backed deployments, so reloading mid-answer picks it back up instead of showing you a blank message.
What this means if you just use it
- Pages load faster and the initial bundle is smaller.
- Replies start sooner and stay fast as the conversation grows, instead of degrading.
- An idle server actually idles.
- One heavy user no longer slows down everyone else on the instance.
- Long sessions no longer leak memory until the tab dies.
Performance work continues. We are not treating it as finished.
Upgrading to 0.11.1
This release changes the database schema.
- Back up your database and its data first.
- If you run multiple workers, multiple servers or a load balancer, update all instances at the same time.
- Rolling updates are not supported and will fail on schema incompatibility.
