# EdgeQuake: A Rust GraphRAG Stack You Install With Docker > EdgeQuake turns documents into knowledge graphs for retrieval and generation, ships a Docker quickstart that needs no Rust or Node.js, and treats database schema changes as an explicit operator step. Here is what the repository actually documents, and where it will bite you. **raphaelmansuy/edgequake** — EdegQuake 🌋 High-performance GraphRAG inspired from LightRag written in Rust; Transform documents into intelligent knowledge graphs for superior retrieval and generation - Repository: https://github.com/raphaelmansuy/edgequake - Website: https://edgequake.com - Stars: 2,096 · Forks: 244 - Language: Rust - License: Apache-2.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/raphaelmansuy-edgequake ## The problem EdgeQuake solves, and who it is aimed at Plain vector search retrieves chunks that look similar to a query. It does not know that two chunks mention the same entity under different names, or that a third document connects them. EdgeQuake is built around the other approach: extract entities and relations from documents into a knowledge graph, then retrieve over that graph. The README states the goal directly, describing the project as a "High-Performance Graph-RAG Framework in Rust" that will "Transform documents into intelligent knowledge graphs for superior retrieval and generation". The intended user is an engineer who already believes graph-based retrieval is worth the ingestion cost and wants a runnable stack rather than a library to assemble. The quickstart is explicit that you need neither Rust nor Node.js nor a build step, only Docker. That is a deliberate choice: the core is Rust, but the entry point is a shell wizard. The repository topics (graphrag, knowledge-graph, lightrag, rag) confirm the lineage. The description says the design is "inspired from LightRag", so anyone who has used LightRAG will recognise the shape of the pipeline even though the implementation language differs. What you get is not a single binary but a system: a REST API, a web UI, a Postgres-backed graph layer, and a set of provider integrations. The top-level repository layout shows `crates/`, `sdks/`, `migrations/`, `docker/`, `deploy/`, `mcp/`, `specifications/` and `edgequake_webui/`, which tells you this is a platform with its own release cadence rather than a crate you drop into an existing service. ## How the ingestion and retrieval path is put together The pipeline starts with documents and ends with a graph plus vectors. PDF handling is a first-class concern: the environment template documents `edgequake-pdf2md`, described as a PDF-to-Markdown conversion step that "Uses a vision-capable model to extract structured Markdown from PDF page images." That is a meaningful design decision. Instead of parsing PDF layout with heuristics, EdgeQuake sends page images to a vision model and takes structured Markdown back, then feeds that Markdown into the graph pipeline. It costs model calls per page, and it means a vision-capable provider is effectively required for PDF-heavy corpora. Configuration is explicit by design. The environment template warns in capitals to "ALWAYS SET THESE to avoid auto-detection behavior" and lists canonical variables: `EDGEQUAKE_DEFAULT_LLM_PROVIDER`, `EDGEQUAKE_DEFAULT_LLM_MODEL`, `EDGEQUAKE_DEFAULT_EMBEDDING_PROVIDER`, `EDGEQUAKE_DEFAULT_EMBEDDING_MODEL` and `EDGEQUAKE_DEFAULT_EMBEDDING_DIMENSION`. LightRAG-style aliases such as `MODEL_PROVIDER`, `CHAT_MODEL` and `EMBEDDING_DIMENSION` are accepted, but the template states the canonical EdgeQuake names take precedence. If you migrate an existing env file and both sets are present, the EdgeQuake names win, which is worth knowing before you debug a provider mismatch. Storage sits behind a Postgres layer with an AGE graph. The 0.24.0 notes describe a `VECTOR_BACKEND` setting whose unknown values are rejected, and a `StorageInspector` that uses `workspace_id` with a Postgres AGE graph as the source of truth. Vectors and key-value state are separate stores with their own migrations, which is why some schema steps are described as irreversible drops rather than additive changes. ## Installing EdgeQuake with the Docker quickstart The fastest documented path is a single curl into a shell. The README says the wizard walks you through provider selection (OpenAI or Ollama), model choice, and then starts the full stack. ```bash curl -fsSL https://raw.githubusercontent.com/raphaelmansuy/edgequake/edgequake-main/quickstart.sh | sh ``` When it finishes, the README says to open http://localhost:3000 and that no login is required because the quickstart runs with `EDGEQUAKE_DEV_MODE=true`. Note the port difference: Docker quickstart maps the web UI to 3000, while a local `make dev` defaults to 3010 to avoid collisions with other stacks. The REST API is on 8080 under Docker and on a free port starting at 8090 under `make dev`. Run `make status` to see which ports were actually bound. If you prefer to skip the wizard, the README gives the compose route and a headless variant for CI. For a local Ollama on the host, the example sets four variables: ```bash EDGEQUAKE_LLM_PROVIDER=ollama \ EDGEQUAKE_LLM_MODEL=gemma4:e4b \ EDGEQUAKE_EMBEDDING_PROVIDER=ollama \ OLLAMA_EMBEDDING_MODEL=embeddinggemma \ docker compose -f docker-compose.quickstart.yml up -d ``` The README also shows how to pin a version rather than tracking the branch: `EDGEQUAKE_VERSION=0.26.5 sh quickstart.sh`. Verify the stack is up before ingesting anything, using the health endpoint the README provides: ```bash curl -s http://localhost:8080/health | python3 -m json.tool ``` For a fresh install the migration table is unambiguous: run `edgequake migrate` once, then start the API, and `make dev` does that for you. If the server exits with code 78, the README says the schema is behind or newer than the binary, so run migrate and restart. ## The migration model is the sharpest edge in the project The 0.24.0 notes state it plainly: "The API never migrates the database. Schema changes are an explicit operator step." That is a defensible choice for a system where some migrations drop data, but it shifts real work onto whoever runs the deployment. The upgrade path from v0.22.0 or earlier is a sequence, not a command: back up, run `migrate dry-run`, run `migrate`, run `migrate --confirm-drop`, then `migrate` again to apply the deferred migration 142, and only then start the API. The notes name three irreversible drops (125 for key-value, 126 and 131 for vectors) that require `--confirm-drop` and a backup, and they say rollback after that is restore-only. Migration 142 asserts empty leftovers and aborts if rows remain, and it stays deferred while residue exists. There is no documented rollback command. The README points at restore, which means your backup discipline is the rollback plan. If your team cannot take and test a database backup before an upgrade window, this project's upgrade story is a poor fit. The release notes also show how fast the surface moves: 0.26.1 through 0.26.5 all landed within roughly a month, and 0.26.1 explicitly warns not to stay on the 0.26.0 image because it "still has the old CLI". Pinning a tag is therefore not optional in practice, it is the only way to know which migrate behaviour you are running. ## Where EdgeQuake is the wrong tool Graph extraction is expensive. Every document goes through an LLM to produce entities and relations, and if the corpus is PDF-heavy it also goes through a vision model for Markdown conversion. For a workload where keyword or embedding search already answers the question, you are paying two model passes per document for structure you never query. The README does not publish ingestion cost figures, so budget on your own provider pricing before assuming the graph pays for itself. Operational complexity is the second mismatch. A single-binary retrieval library has no schema to migrate. EdgeQuake has a Postgres graph, a vector store, a key-value store and numbered migrations, and the project's own notes describe mid-upgrade deferral states where the system soft-exits while residue remains. If you want a component you can upgrade by swapping a container tag, this is more machinery than you asked for. Finally, the documentation has gaps you should notice before adopting. The README does not document rollback beyond restore, does not publish benchmark numbers, and the release notes carry internal SPEC identifiers (SPEC-104, SPEC-124, SPEC-135) that assume familiarity with the project's own specification tree. The `specifications/` directory exists in the repository, so the detail is there, but the README alone is not a complete operator manual. ## How this differs from running LightRAG directly The description says EdgeQuake is "inspired from LightRag", so the honest comparison is against LightRAG itself. The retrieval idea is the same: build a graph from documents, then use it at query time. The differences are in packaging and operational surface. LightRAG is a Python project you import and wire into your own service. EdgeQuake is a deployed stack: a Rust core, a REST API with Swagger at `/swagger-ui`, a web UI, published SDKs for Rust, Python, TypeScript, Java and Kotlin (the Makefile defines build, publish and version targets for each), and a Docker compose file. If your team is Python-native and wants to embed graph retrieval inside an existing application, LightRAG's shape is closer to that. If you want an HTTP service with a UI and client SDKs, EdgeQuake's shape is closer. The trade-off is that EdgeQuake inherits the operational burden of everything it bundles. You get a migration system, a vector backend setting, and a release cadence measured in weeks. You also get the compatibility aliases in the environment template, which exist precisely because people arrive with LightRAG-style configuration. That is a pragmatic touch, and it is also a hint that the project expects migration traffic from exactly that direction. ## Licence, maintenance and what an upgrade actually costs EdgeQuake is Apache-2.0, which permits commercial use and modification with the usual notice and patent terms. That is a permissive choice and it matters here because you are deploying a service, not linking a library. Check the LICENSE file for the exact terms, and note that the project talks to external model providers whose own terms apply to the data you send them. Nothing in the repository changes those obligations. The repository is not archived, and the last push was on 2026-09-10. Releases have been frequent: 0.26.3, 0.26.4 and 0.26.5 arrived between 2026-08-28 and 2026-09-02. Frequent patch releases are good for fixes and bad for stability expectations. The 0.26.x notes repeatedly say "No new migration (schema stays 149)", which is the signal to look for: a patch that keeps the schema at 149 is a container swap, while a release that bumps the migration number is an operator task with a backup in front of it. Upgrade cost therefore splits in two. Image updates are cheap if you pin tags and read the release note for the migration number. Schema updates are the expensive part, because they require a dry run, a backup, and for the irreversible drops, an explicit `--confirm-drop` flag. The README also notes the quickstart runs with `EDGEQUAKE_DEV_MODE=true` and no login, so anything beyond local evaluation needs that setting reconsidered before the stack is reachable by anyone else. ## Conclusion Adopt EdgeQuake if you want a GraphRAG pipeline you can stand up from a shell script and you accept that schema migrations are your job: run `edgequake migrate` before the API, and back up before any `--confirm-drop`. Do not adopt it if you need a managed service, a stable schema across releases, or a documented rollback path, because the README describes irreversible drops as restore-only. Before committing, verify the migration guide for your current version, the exact `EDGEQUAKE_*` variables your provider needs, and whether the pinned image tag you plan to run is the one the release notes tell you to pull. ## FAQ ### Do I need Rust or Node.js installed to run EdgeQuake? No. The README's quickstart states "No Rust, no Node.js, no build. Just Docker." The shell wizard handles provider selection and starts the full stack, and the web UI is then reachable on http://localhost:3000. ### Which ports does EdgeQuake use for the web UI and API? Under the Docker quickstart the web UI is on http://localhost:3000 and the REST API on http://localhost:8080, with Swagger at /swagger-ui and a health endpoint at /health. A local `make dev` instead defaults to 3010 for the UI and picks a free API port starting at 8090; `make status` reports the bound ports. ### Does EdgeQuake migrate its database automatically on startup? No. The 0.24.0 release notes state that the API never migrates the database and that schema changes are an explicit operator step. For a fresh install you run `edgequake migrate` once before starting the API, and a server exit code of 78 means the schema is behind or newer than the binary. ## Sources - [License: Apache-2.0](https://github.com/raphaelmansuy/edgequake/blob/edgequake-main/LICENSE) - [Project website](https://edgequake.com) - [raphaelmansuy/edgequake on GitHub](https://github.com/raphaelmansuy/edgequake) - [README](https://github.com/raphaelmansuy/edgequake/blob/edgequake-main/README.md) - [Releases](https://github.com/raphaelmansuy/edgequake/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/raphaelmansuy-edgequake