What does RAGFlow's DOC_ENGINE setting select, and what does switching it cost?

## What the setting is `DOC_ENGINE` is an environment variable in `docker/.env`, the file that parameterises RAGFlow's Compose stack. On container start the entrypoint renders `service_conf.yaml` from its template, substituting environment values, and the rendered config tells the backend which document-engine block to use. Compose also uses the value to decide which engine container to bring up, so setting it changes both the client and the server side in one place. The accepted values are `elasticsearch` (the default) and `infinity`; recent builds have added further options, so read the `.env` comments for your tag rather than trusting a list from memory. ## What the engine actually stores This is the crux. The document engine is where a parsed document *ends up*: one record per chunk, containing the chunk text, its embedding vector, and the fields used for keyword matching. Every retrieval call — the retrieval-testing panel, a chat assistant answering a question, an agent's retrieval step — queries this store. MySQL knows a document exists and what state it is in; MinIO has the original bytes; but the searchable content only exists in the document engine. That is why the switch is destructive. The two engines have entirely different on-disk formats and indices. Nothing copies your Elasticsearch indices into Infinity. ## Why the two options exist Elasticsearch is mature, ubiquitous, and gives RAGFlow a well-understood hybrid of BM25 keyword scoring and vector similarity. Its cost is memory: it is the heaviest container in the stack, it wants gigabytes of heap, and on Linux the host must have `vm.max_map_count` at 262144 or higher or the node refuses to boot. Infinity is InfiniFlow's own database, built for exactly this workload — dense vectors plus sparse/full-text retrieval in one engine — and its pitch is lower resource consumption and faster hybrid queries. The tradeoff is maturity and reach: it is a younger project, platform support is narrower, and features occasionally land on the Elasticsearch path first. For a production deployment, "Elasticsearch unless you have measured a reason" is a defensible default; for a laptop demo or a memory-constrained VM, Infinity is a real win. ## The switching procedure and its cost The documented sequence is: stop the stack; remove the volumes so the old engine's data and the stale references to it are gone; change `DOC_ENGINE`; start again. `docker compose down -v` is the command usually cited, and the `-v` is the dangerous half — it removes MySQL and MinIO volumes too, so you lose datasets, documents, assistants and users, not just the index. That is worth stating plainly in an interview, because the cost is not the downtime. It is the **re-parse**. RAGFlow's value proposition is layout-aware DeepDoc parsing with OCR and table-structure recognition; running that over a corpus of thousands of PDFs is hours of CPU, and if you are calling a hosted embedding API it is a real bill as well. So the engine choice is effectively a one-way door for a populated instance. ## Operational implications A few things follow: - **Decide early.** Make the engine choice part of the initial deployment decision, alongside the image variant and the embedding model — the other two settings that are also painful to change after ingestion. - **Keep the originals.** Because a re-parse is your recovery path for any doc-engine loss, MinIO's contents are the thing that actually makes the corpus reconstructible. Back it up even if you consider the index disposable. - **Don't treat the index as disposable in practice.** "It's derived data, we can rebuild it" is true and useless if rebuilding takes eight hours and blocks the product. - **Separate the config change from the data wipe.** If you are experimenting, run a second stack with its own project name and volumes rather than flipping the value on the instance that holds real data. - **Verify after the switch.** After re-parsing, use the retrieval-testing panel to confirm hybrid retrieval behaves as it did before; scoring characteristics between two different engines are not identical, so previously tuned thresholds may need revisiting. ## The interview signal A weak answer treats `DOC_ENGINE` as a swappable driver. A strong one identifies it as a storage-format commitment, names re-parsing as the true cost, and notes that `docker compose down -v` takes the rest of the stack with it — plus the instinct to make this decision before the first real ingest rather than after.