RAGFlow 0.26.4
A document-understanding-first platform built around deep parsing, deployed and measured against the same corpus as every other platform here.
In one paragraph
Deployed from its published image, RAGFlow runs 5 containers and held 9,959.6 MB at peak during ingestion. It retained 99% of the facts planted in the corpus and answered 73% of the retrieval questions correctly.
Measured
| Measurement | Result | How |
|---|---|---|
| Time to first served request | 511 s | Includes image pull, from a clean host |
| Containers | 5 | Running after the stack settles |
| Idle memory | 8,517.3 MB | Sum across containers, 60s after ready |
| Peak memory during ingestion | 9,959.6 MB | Sampled every 5s across the whole corpus |
| Documents ingested | 36/36 | Failures counted, not excluded |
| Chunks stored | 477 | Across the whole corpus |
| Parsing fidelity | 99% | Planted facts found in stored chunks |
| Retrieval accuracy | 73% | Answer present in top-5 context, 93 questions |
| Retrieval latency | 414.7 / 464.4 ms | p50 / p95, CPU embedding |
| Licence | Apache-2.0 | Permits offering it as a service |
What it does well
- The most permissive licence of any platform measured — Apache 2.0, with no restriction on offering it as a service
- The fewest containers of the three purpose-built platforms, at five
- Validates a model endpoint at the moment it is registered, so a misconfiguration surfaces immediately rather than at first use
Where it falls short
- By far the heaviest memory footprint measured, driven by a bundled Elasticsearch that alone holds over four gigabytes at idle
- Uploading a document does not start parsing; that is a separate call, and a client that only uploads waits forever for chunks that were never going to be produced
- Answers HTTP 200 with a small non-zero status code on failure, so a client trusting the transport status will read a rejected call as a success
- The login password must be RSA-encrypted with a public key hard-coded in the web frontend, which is not documented for API clients
- Version 0.26 moved every route onto a new prefix, so paths from older documentation return 404
Choose it when
- Anyone who needs to redistribute or resell the deployment — the licence is the least restrictive here
- Document sets where parsing quality matters more than memory cost
Choose something else when
- Memory-constrained hosts; the Elasticsearch requirement is not optional in the default deployment
- Teams wanting the shortest path from container start to a working knowledge base
Deployment notes
Five containers is the smallest count among the purpose-built platforms, and it is also the most memory-hungry deployment measured — the two figures point in opposite directions and both are worth knowing. Elasticsearch is the reason.
Driving it
Three surfaces have to be understood before anything works: an RSA-encrypted login, a provider-then-instance model registration flow that replaced the older single call, and a two-step ingestion where upload and parse are separate. None of that is difficult once known, but none of it is discoverable from the API documentation alone.