Open WebUI 0.11.0
A chat front-end that grew retrieval features, deployed and measured against the same corpus as every other platform here.
In one paragraph
Deployed from its published image, Open WebUI runs 1 container and held 980.7 MB at peak during ingestion. It retained 46% of the facts planted in the corpus and answered 73% of the retrieval questions correctly.
Measured
| Measurement | Result | How |
|---|---|---|
| Time to first served request | 18 s | Includes image pull, from a clean host |
| Containers | 1 | Running after the stack settles |
| Idle memory | 664.3 MB | Sum across containers, 60s after ready |
| Peak memory during ingestion | 980.7 MB | Sampled every 5s across the whole corpus |
| Documents ingested | 36/36 | Failures counted, not excluded |
| Chunks stored | 5,060 | Across the whole corpus |
| Parsing fidelity | 46% | Approximate: no chunk-listing API, measured by exhaustive retrieval |
| Retrieval accuracy | 73% | Answer present in top-5 context, 93 questions |
| Retrieval latency | 271.7 / 305.8 ms | p50 / p95, CPU embedding |
| Licence | Open WebUI License (BSD-3-Clause with branding conditions) | Permits offering it as a service |
What it does well
- A single container, second only to AnythingLLM on footprint
- Signup returns a usable token immediately, making it the least ceremonious platform to automate
- Strong chat experience if a knowledge base is a supporting feature rather than the point
Where it falls short
- Retrieval is a feature of a chat product rather than the product, and the knowledge APIs are correspondingly thinner
- Embedding configuration is global rather than per knowledge base, so every collection shares one model whether that suits it or not
- Uploading a file and attaching it to a collection are separate steps, and attaching before text extraction finishes is rejected with a message about empty content rather than a retryable status
- Signup is open by default and the first account silently becomes an administrator
- Exposes no API listing a document's stored chunks, so parsing fidelity here can only be approximated through retrieval
Choose it when
- Teams that primarily want a chat interface and will use retrieval occasionally
- Deployments already standardised on Ollama
Choose something else when
- Knowledge-base-first workloads where chunking and retrieval need tuning per collection
- Anything exposed publicly without closing signup first
Deployment notes
The upstream compose builds from a Dockerfile and bundles its own Ollama. For a comparison where every platform must use the same embedding model, that is not usable as published, so the compose here pins the released image and points at the shared embedding service instead. The file says so at the top.
Why its parsing figure carries a tilde
Like AnythingLLM, there is no route listing a document’s stored chunks. The parsing measurement is taken by sweeping retrieval, which can only under-report — a missing fact means not observed, not dropped.