EdgeQuake: A Rust GraphRAG Stack Where the Database Migration Is an Operator Step
EdegQuake 🌋 High-performance GraphRAG inspired from LightRag written in Rust; Transform documents into intelligent knowledge graphs for superior retrieval and generation
At a glance
- What is it?
- EdgeQuake turns documents into a knowledge graph for retrieval and generation, ships as a Docker quickstart, and treats schema changes as an explicit operator action rather than something the API does on boot. The interesting decision is that last part, and it is also the one that will trip up a casual deployment.
- Who is it for?
- Adopt EdgeQuake if you want a self-hosted graph-plus-vector retrieval stack in Rust and you are willing to own a PostgreSQL schema with numbered migrations, because the API will not run them for you. Do not adopt it if you want a managed retrieval service or if your corpus is small enough that a single embedding index answers your queries.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem EdgeQuake is aimed at, and the shape of the team that needs it
Plain vector search retrieves passages that resemble a question. It does not know that two passages describe the same entity, and it cannot answer a question whose evidence is spread across three documents that never share vocabulary. GraphRAG addresses that by extracting entities and relations during ingestion, storing them as a graph, and using the graph at query time to pull in material that embedding similarity alone would miss. EdgeQuake is a Rust implementation of that pipeline, and the README describes it as inspired by LightRAG. The intended user is a team that already runs PostgreSQL and wants graph-augmented retrieval inside its own infrastructure, rather than calling a hosted retrieval API. The Docker-first quickstart is a deliberate signal about who that is: the README states plainly, no Rust, no Node.js, no build, just Docker. If you are evaluating retrieval quality on a laptop, the install path is a single curl pipe into sh, and the wizard walks through provider selection between OpenAI and Ollama. If you are the person who has to keep it alive in production, the same repository hands you a numbered migration system, a set of runbooks under docs/operations, and a schema version you now have to track.
How ingestion and retrieval actually flow through the system
The repository layout and the release notes together describe a split architecture rather than a single binary. There is a REST API, a separate web frontend, a PostgreSQL instance that holds both relational tables and an Apache AGE graph, and a vector backend. Release notes for 0.24.0 mention StorageInspector using workspace_id with PostgresConfig as the AGE graph source of truth, and mention an unknown VECTOR_BACKEND value resolving to a typed error, which tells you the vector store is selectable at configuration time rather than fixed. Ingestion is not a single pass: the 0.26.0 notes list PDF pack-to-budget and manuscript page-as-unit conversion, and 0.25.0 lists a structure-aware markdown pack, so documents are converted, chunked to a token budget, and only then sent through entity and relation extraction. Multi-tenancy is present in the data model through workspace_id, and the 0.24.0 notes describe tenant creation returning 201, 200 or 409, which is the ordinary created, already-exists, conflict triple. Observability is opt-in: 0.26.0 describes a Langfuse dev sibling, and 0.26.3 describes isolated OTLP stacks for Langfuse 3.22 and 3.225. What the material does not give is any measured retrieval quality, latency figure or throughput number, so treat the performance framing in the tagline as a design goal rather than something you can plan capacity against.
Getting it running: two paths and the ports they bind
The README gives a wizard install and a direct compose install. The wizard is one command, curl -fsSL https://raw.githubusercontent.com/raphaelmansuy/edgequake/edgequake-main/quickstart.sh | sh, and it selects a provider and model before starting the stack. The direct path downloads docker-compose.quickstart.yml and runs docker compose -f docker-compose.quickstart.yml up -d. For non-interactive environments the README shows environment variables doing the work instead of the wizard: EDGEQUAKE_LLM_PROVIDER=openai with OPENAI_API_KEY, or EDGEQUAKE_LLM_PROVIDER=ollama with EDGEQUAKE_LLM_MODEL, EDGEQUAKE_EMBEDDING_PROVIDER and OLLAMA_EMBEDDING_MODEL. Ports differ between the two install modes and this is the first thing that wastes an afternoon. The Docker quickstart serves the UI on 3000 and the API on 8080, with Swagger at /swagger-ui and a health endpoint at /health. A local make dev run starts at 3010 for the UI and 8090 for the API, picking free ports upward from there, and make status reports what was actually bound. The README notes that quickstart runs with EDGEQUAKE_DEV_MODE=true and needs no login, which is convenient on a laptop and is exactly the setting you must not carry into anything reachable from a network. Version pinning works through EDGEQUAKE_VERSION, for example EDGEQUAKE_VERSION=0.26.5 sh quickstart.sh. Verification is a single curl against /health piped into python3 -m json.tool.
The migration model is the real adoption cost
This is the part of EdgeQuake that deserves the most attention before you install it. The 0.24.0 release notes state that the API never migrates the database and that schema changes are an explicit operator step. A fresh install runs edgequake migrate once and then starts the API, and make dev is documented as doing that for you. Upgrades are more involved. From v0.22.0 or earlier the documented sequence is backup, then migrate dry-run, then migrate, then migrate --confirm-drop, then migrate again to apply the deferred migration 142, and only then start the API. If the server exits with code 78, the schema is either behind or ahead of the binary, and the fix is to run migrate and restart. Migrations 125, 126 and 131 drop data and are described as irreversible, requiring --confirm-drop and a backup, with rollback being restore-only after that point. Migration 142 aborts if rows remain and is deferred while residue exists. Patch releases in the 0.26.x line repeatedly state no new migration and schema stays 149, which is a useful signal: the maintainers are distinguishing schema-stable patches from schema-changing minors. The cost this imposes is that you cannot treat EdgeQuake as a container you pull and restart. You need a migration step in your deploy pipeline and a tested restore path, and you need to read the upgrade document for the specific version you are moving to, because 0.26.1 notes that the 0.26.0 image still carried the old CLI.
Where EdgeQuake is the wrong tool
Three cases stand out. The first is a corpus where retrieval is genuinely a similarity problem: support macros, a single product manual, a set of policy PDFs that never reference each other. Entity and relation extraction costs tokens and wall-clock time per document, and the graph buys you nothing if the answer always lives in one chunk. The second is a team without PostgreSQL operational experience. EdgeQuake is not a single static binary you drop on a box; it wants a relational store, an AGE graph extension, a vector backend, and a migration discipline. The third is anyone who needs a managed service with a support contract. The README documents self-hosting paths and a Kubernetes Helm and kind path appears in the 0.26.2 notes, but the material describes no hosted offering. There is also a subtler failure mode in the release history itself. The 0.26.1 notes warn not to stay on 0.26.0 because of a leftover DROP OLD copy, and 0.26.3 says do not stay on 0.26.1 for the same reason. Those are honest notes, and they are also a warning that skipping patch releases in this project is not neutral. If your policy is to upgrade quarterly, this is a project where you should read every intermediate upgrade document rather than jumping to the latest tag.
The comparison that matters: graph retrieval versus a plain vector index
The honest alternative is a vector store with an embedding model in front of it, whether that is pgvector in the PostgreSQL you already run or a dedicated index. The difference is not quality in the abstract, it is where the work happens. A vector index does one thing at write time, embed the chunk, and one thing at read time, find the nearest chunks. EdgeQuake adds an extraction stage between those: documents are converted, packed to a token budget, passed through an LLM to produce entities and relations, and written into both a graph and a vector store. That extra stage is what lets a query traverse from a named entity to related entities that share no surface vocabulary with the question. It is also what makes ingestion cost proportional to LLM calls rather than to embedding calls, and what makes the PostgreSQL schema non-trivial. If your questions are of the form find the paragraph that says X, the vector index wins on cost and on operational surface. If your questions are of the form how are A, B and C connected across these forty documents, the graph is doing work the vector index cannot. EdgeQuake also sits in a different place from LightRAG, which the README names as the inspiration: the distinguishing choice here is the Rust implementation and the operator-owned migration model, not the retrieval concept.
Licence, upgrade cadence and what the release notes imply about maintenance
EdgeQuake is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. That is a permissive licence, and it means the constraint on your deployment is operational rather than legal. This is not legal advice; read the LICENSE file for the terms that bind you. On cadence, the release list shows 0.26.3, 0.26.4 and 0.26.5 landing within roughly two weeks of each other, and the notes for each name specific specifications and issue numbers. Several of those notes are security-adjacent: 0.26.4 describes a Next.js 16.3.3 bump covering August critical RCEs and a move to a distroless API image. A project that patches a frontend framework for remote code execution within days is doing the work, but it also means the upgrade documents under docs/operations are load-bearing artifacts rather than nice-to-haves, and that pinning EDGEQUAKE_VERSION to a specific tag is the right default. The published crates, edgequake-llm, edgequake-pdf2md and edgequake-sdk, are versioned separately from the application, so a library bump does not necessarily require an application upgrade. What the material does not tell you is how long any given release stays supported, or whether there is a long-term support line. Until that is documented, budget for staying close to the newest patch rather than trailing it.
Editorial conclusion
Adopt EdgeQuake if you want a self-hosted graph-plus-vector retrieval stack in Rust and you are willing to own a PostgreSQL schema with numbered migrations, because the API will not run them for you. Do not adopt it if you want a managed retrieval service or if your corpus is small enough that a single embedding index answers your queries. Before committing, verify three things: that edgequake migrate runs cleanly against your PostgreSQL version, that your chosen LLM provider is reachable from inside the container network rather than only from the host, and that you can restore a backup, since migrations 125, 126 and 131 drop data irreversibly once you pass --confirm-drop.
Community notes