Pluteus compared
The same library, the same machine, four servers: Pluteus, Ubooquity, Komga and Kavita. Image size, memory, scan time, disk use and browsing speed, measured, with the method and where Pluteus loses.
The short version
- Pluteus is the lightest by a wide margin. Its Docker image is 215 MB against 371 to 900 MB, and it idles at 29 MB against 169 to 615 MB. On the 12,000-file library its peak while browsing was 63 MB; Ubooquity peaked at 277 MB and Komga at 852 MB.
- It has no scan. Pluteus answers the first request about one second after it starts. On 12,000 files Ubooquity and Komga spent 12 and 14 minutes indexing before the whole library was browsable, and Kavita had not finished the EPUBs after 10.
- The price is the first look at a comic folder. Pluteus reads each comic's page list when you first open a folder, where the others did that work during their scan. In our crawl the median first request took about 700 ms, and 80 ms the second time. Ubooquity answered in about 15 ms and Komga in 200 to 340 ms.
- The others do more. Komga and Kavita have covers, metadata editing, reading lists, collections and richer user management. Pluteus deliberately has none of that. If you want those, it is not the tool.
12,000 files
6,000 CBZ comics (60 series, each with a ComicInfo.xml) and 6,000 EPUBs (400 authors, with series metadata), 284 MB in all. All files are invented.
| Pluteus 0.4.0 | Ubooquity 3.1.0 | Komga 26.04 | Kavita | |
|---|---|---|---|---|
| Docker image | 215 MB | 371 MB | 809 MB | 900 MB |
| Server answers after | 1.1 s | not timed | 11.9 s | 16.9 s |
| Whole library browsable after | at once | 12 min (721 s) | 14 min (827 s) | cancelled after about 10 min comics indexed in 3.5 to 5.7 min; the EPUB library had not appeared |
| Memory at rest, no library yet | 29 MB | not measurable it scans at launch | 605 MB | 339 MB |
| Memory at rest, library loaded | 29 MB | 203 MB | 833 MB | – |
| Peak memory while an app browses | 63 MB | 277 MB | 852 MB | – |
| State kept on disk | 7 MB | 31 MB | 48 MB | 111 MB comics only |
| OPDS browsing, first pass median / 95th percentile | 695 ms / 2.5 s | 16 ms / 46 ms | 197 ms / 346 ms | – |
| OPDS browsing, second pass | 83 ms / 250 ms | 13 ms / 22 ms | 191 ms / 326 ms | – |
3,000 files
The same layout with a quarter of the files: 1,500 comics and 1,500 EPUBs, 71 MB. Run to see what changes when the library is smaller.
| Pluteus 0.4.0 | Ubooquity 3.1.0 | Komga 26.04 | Kavita | |
|---|---|---|---|---|
| Server answers after | 1.2 s | 2.7 s | 12.4 s | 17.5 s |
| Whole library browsable after | at once | 3 min (173 s) | 1.6 min (95 s) to list; busy for 19 min after that | cancelled after 15 min comics indexed; the EPUB library had not appeared |
| Memory at rest, no library yet | 29 MB | not measurable it scans at launch | 615 MB | 360 MB |
| Memory at rest, library loaded | 29 MB | 169 MB | 839 MB | 338 MB comics only |
| Peak memory while an app browses | 39 MB | 187 MB | 875 MB | – |
| State kept on disk | 5 MB | 10 MB | 37 MB | – |
| OPDS browsing, first pass median / 95th percentile | 737 ms / 1.6 s | 20 ms / 66 ms | 332 ms / 510 ms | – |
| OPDS browsing, second pass | 85 ms / 134 ms | 13 ms / 24 ms | 342 ms / 591 ms | – |
Memory barely moves with library size: Pluteus went from 29 to 63 MB peak and Ubooquity from 187 to 277 MB when the library quadrupled, while Komga stayed near 850 MB either way. What grows is scan time for the products that scan, and Pluteus does not scan.
Why Pluteus is slow on a first visit
Pluteus keeps no index. When you open a folder of comics it reads each archive's page list so that reader apps can stream pages, and it caches the answer. The other products read every file once during their scan, then answer from a database. So Pluteus pays at the first visit what they pay up front, spread over the folders you actually open. It is a fair trade for a library of tens of terabytes you mostly never browse in full, and a worse one if you want everything fast from the first tap. The numbers above show both sides: the first pass is slow, the second is not.
How this was measured
- Machine: a Windows laptop running Docker Desktop (16 CPUs and 15.4 GB visible to Docker). The libraries were bind-mounted read-only from the Windows disk, which goes through Docker Desktop's slower file-sharing layer. Every product paid that equally.
- Images: Pluteus 0.4.0 built from its Dockerfile;
linuxserver/ubooquity3.1.0-ls95;gotson/komga26.04;jvmilazz0/kavita(the latest tag, built 2 September 2026). Default settings throughout, no memory limits, one product running at a time, each from a fresh container. - Memory is what
docker statsreports for the container, sampled once a second while a reader app crawled the catalogue. Java products (Ubooquity, Komga, Kavita's .NET runtime) take whatever their runtime grabs by default, which is what a real user gets. - Browsing is a script that does what a reader app does: it starts at the OPDS root and follows the catalogue links, 8 requests at a time, up to 600 requests. The feeds differ between products, so the number of requests differs too (Pluteus 536 and 170, Komga 541 and 470, Ubooquity 332 and 100). Treat the latencies as rough.
- One run each. A shared laptop is noisy: Komga's median browsing time was 197 ms in one run and 332 ms in the other. Differences of a few tens of percent mean nothing; differences of several times do.
- Small files. The comics are about 50 KB and the EPUBs about 5 KB. Real libraries have bigger files, which slows every scanning product, and not Pluteus's start-up.
What went wrong, and what we left out
- Kavita: we could not get its EPUB library indexed. After its comics were scanned (60 series, 6,000 files in 3.5 to 5.7 minutes) the book library stayed empty, and we stopped after about 10 minutes on the larger library and 15 on the smaller. That may be our setup: Kavita queued one scan at a time and the book library needed an explicit scan request, so we treat the Kavita column as incomplete, not as a verdict on the product. Its image size, memory at rest and comics-only figures are real.
- Ubooquity: OPDS is off by default, so we switched it on in its config file. Its "library loaded" memory is after that restart and a second, quiet scan.
- Komga kept working for a long time after every book was listed (thumbnails and similar). The "browsable" line gives the time to list; the settling time was 15 minutes at 12,000 files and 19 at 3,000.
- Not measured: a real library of your own files, a Linux host without Docker Desktop's file layer, many people using it at once, and the time to render pages in a browser.
Measured on 12 October 2026. The raw results are in the Pluteus repository, under docs/benchmark.