The reason to accept two databases instead of one is the graph: "what depends on this" and "what else did this person touch" are traversals, not similarity queries. The cost is real — Neo4j and Qdrant both have to be running, and ingestion needs an OpenAI key — so this suits a vault you query often, not one you dip into occasionally.
A retrieval system for Obsidian vaults that layers several kinds of context: vector similarity, a Graphiti-backed knowledge graph in Neo4j, link traversal over the vault's own wiki-links, recency, and domain specialisation. Notes become entities with typed relationships rather than a flat pile of embeddings.
- `ingest_vault` reads the Markdown files from a vault path
- `query_rag` answers a question using the layered retrieval, with a query type such as technical or research
- `search_knowledge_graph` finds entities in the graph; `get_entity_context` returns rich context for one
- `get_related_entities` follows the relationships out from an entity
- `get_system_status` reports database connections and system health
- The graph carries 27+ entity types (concepts, people, organisations, technologies, methodologies) and 40+ relationship types (implements, uses, depends_on, extends, similar_to)
- A command-line interface mirrors the same operations for ingest, query and graph search
Python 3.9+, Docker and Docker Compose, and an `OPENAI_API_KEY` for the embeddings. Two databases are needed and the setup scripts start both: Qdrant on port 6333 and Neo4j on 7474 and 7687, configured through `NEO4J_URI`, `NEO4J_USER`, `NEO4J_PASSWORD`, `QDRANT_HOST` and `QDRANT_PORT`. The README's install line names `obsidian-elite-rag-mcp`, which PyPI does not have. Installed from source, the CLI's setup, start-databases, ingest and server steps run in that order.