PostgreSQL holds the graph and the matching passages
If a document answer depends on who supplies whom, EdgeQuake can store that relationship alongside the passages that describe it. The README explains a LightRAG-based Rust server that extracts entities and relationships, then combines graph traversal with vector search. Its documented PostgreSQL stack uses pgvector and Apache AGE. This suits document collections where linked facts matter, provided someone can operate the database and check the model's extractions.
Our checkout contained 11,263 files and roughly 988,472 source lines, occupying 408.1 MB before installation. The Rust project lives under ./edgequake/. That is a substantial repository for anyone expecting a small library to drop into an existing app. EdgeQuake includes a web interface, an API, and MCP access, so much of its value comes from adopting an application and its operating conventions.
What happened when we ran it
Our sandbox installed commit da1831c in 32 seconds, adding 693 packages, then built it successfully in 495 seconds. We ran it on October 13, 2026, with 3 CPUs and 12 GB of RAM in an unprivileged Debian container using lab-rust:1. The container had no secrets. The build completed without a reported failure, giving prospective contributors a concrete starting point for the source route.
Cargo tests succeeded in 288 seconds: 84 passed and 0 failed out of 84. Our scan found 24 CI workflow files and a tests directory, without a Dockerfile. That Dockerfile result describes the lab scan, while upstream separately offers prebuilt container images. The supplied measurement does not establish that we launched those images, ingested a PDF, connected a paid model, or checked a database upgrade.
The 495-second build is a meaningful wait when working from source. Prebuilt images offer another adoption path, but our run provides no timing for it. Likewise, the 84 passing tests support the code path we exercised without proving retrieval accuracy, tenant isolation, or migration safety on an existing deployment. Those questions need the intended provider, a representative document collection, and the database state you will actually operate.
The Docker wizard still needs a model service
The README's quickstart uses Docker and binds exposed ports to loopback. Its wizard can detect local model servers or accept hosted-provider credentials. A useful deployment needs PostgreSQL plus reachable language-model and embedding services. Each workspace can assign separate models to extraction, answering, and other roles. A cloud model with local embeddings is supported, though that arrangement still sends extraction or question content to the cloud service you select.
Our 693-package source installation does not include a measured model-serving setup. With Ollama, the README warns that the first run downloads model assets. The Compose configuration also explains that a container's localhost points inside that container, so a host-side model server needs the appropriate host address. That is an easy configuration error to make when everything appears to be on the same laptop.
Quickstart authentication is disabled for the demo
The authentication guide says the quickstart Compose file turns login off. Production setup requires deliberate authentication settings, a strong JWT secret, allowed browser origins, and an admin bootstrap password. The guide also requires a Compose override to pass the CORS setting. Loopback binding helps keep the initial demo local, but publishing that demo to a shared network requires more work.
The 84 passing tests do not answer whether your deployed route requires a login or exposes the intended tenant data. MCP access deserves the same attention as the browser interface because agents can interact with stored documents. Use the documented provider checks and inspect the running security posture before admitting private files. I would choose EdgeQuake only with a named operator responsible for these settings and the PostgreSQL backup.
v0.35.0 has open dashboard and graph regressions
Issue 479 reports a v0.35.0 dashboard connection error when the UI and API use different origins, despite successful direct API calls. The report says putting both behind one origin restores the interface. This is a concrete deployment concern for teams separating frontend and backend domains. A green API indicator alone would miss the failure the user sees.
Our successful 288-second test run did not reproduce that browser layout. Issue 477 separately reports newly ingested graph data becoming invisible on upgraded AGE installations because writes and reads use different stores. Issue 478 reports per-document graph requests failing on a large AGE graph. The linked fixes remained open when checked. Existing AGE operators should verify the release path before upgrading valuable data.
October activity comes with documentation version drift
The last push was October 14, 2026, and GitHub listed 62 open issues and PRs with 2,243 stars. Release v0.35.0 appeared on October 12, while the default-branch README still advertised v0.34.0 and the fetched architecture guide described an older version scope. Recent regression reports and proposed fixes show active maintenance. They also mean operators must match instructions to the image and branch they deploy.
The upgrade guide assigns schema changes to edgequake migrate, separate from the serving API. That makes backups and migration review part of ownership. Compare LightRAG if you prefer working with the underlying Python project, Microsoft GraphRAG for its research pipeline while accepting its stated maintenance mode, or RAGFlow for a different document application. EdgeQuake earns a controlled pilot from its 84 passing tests. For an existing AGE database, make successful ingestion and visible graph reads the acceptance criteria before switching traffic.