Knowledge-Graph Tools — Multi-Option Analysis
Comparison of 8 knowledge-graph approaches for IKA: Graphify · Microsoft GraphRAG · Neo4j · Memgraph · TerminusDB · pgvector + ltree · LangChain Knowledge Graph · Logseq/Obsidian/Mem (consumer notes). Recommendation per IKA layer (codebase vs user-content). Compiled 2026-04-26. Companion to /ika-pro-architecture.
TL;DR
Wrong tool for the user-content graph. Right tool for the codebase-context graph + token reduction. Adopt narrowly.
Graphify is a Claude-Code-specific skill that builds a knowledge graph FROM A CODEBASE (code + docs + PDFs + images), not from arbitrary user content. Open-source MIT, 3.7k stars, by Safi Shamsi. Tree-sitter + LLM semantic extraction + NetworkX + Leiden community detection. Outputs interactive graph.html + queryable graph.json + GRAPH_REPORT.md. Ships as /graphify skill commands.
Not a knowledge graph for end-user notes/projects/people (which is what we\'d need for Operations entity discovery). Could be confused with that but it\'s a developer-facing tool.
Adopt narrowly: install Graphify in our Engineering / Architecture neuron as a Skill (per the v19.5 catalog). Use it during v3.0 + v3.5 builds for cross-file architecture understanding + the documented 71.5× token reduction on codebase Q&A. Add as Layer 6 of the token-optimizer stack from /tokens. Don\'t use for the per-IKA user-content graph — that needs a different shape (Microsoft GraphRAG-style or per-tenant pgvector + relationships layer).
What Graphify is
| Property | Value |
| What it is | Multi-modal knowledge graph builder for AI coding assistants — turns a codebase + docs + papers + diagrams into an interactive graph |
| Author | Safi Shamsi |
| License | MIT |
| Maturity | 3.7k+ GitHub stars · active project |
| Runtime | Python 3.10+; ships as graphifyy on PyPI; CLI command is graphify |
| Dependencies | NetworkX (graph) · Tree-sitter (AST static analysis) · LLM API (semantic extraction) · vision models (diagrams) |
| Pipeline | detect (collect files) → extract (AST + LLM) → build (NetworkX) → cluster (Leiden communities) → analyze (god nodes + surprises) → report (GRAPH_REPORT.md) → export (HTML / JSON / Obsidian) |
| Outputs | graph.html (interactive) · graph.json (queryable) · GRAPH_REPORT.md (audit report) · Obsidian export |
| Skill commands | /graphify, /graphify query, /graphify path, /graphify explain |
| MCP support | Yes — serve.py exposes graph as an MCP service |
| Token reduction | 71.5× claimed (vs full-context dump) |
| Hosting | Self-hosted CLI; runs locally |
| Supported clients | Claude Code · OpenAI Codex · OpenCode |
| Distinctive | NO vector embeddings required (uses Leiden community detection on the graph instead) · no service subscription · pure algorithmic |
What it does NOT do
- Doesn\'t graph user-generated content (notes / projects / tasks / people) — only code + technical docs
- Doesn\'t multi-tenant — single user, single repo at a time
- Doesn\'t SaaS — local CLI only
- Doesn\'t replace pgvector / Postgres for runtime entity queries — outputs a static snapshot graph
- Doesn\'t auto-update on every edit — you re-run
/graphify when the codebase changes (though watch.py does live updates per their docs)
Where it fits in IKA — narrow adoption
Use case 1 — Engineering neuron skill
| Aspect | Detail |
| Where | Install in main / Engineering / Architecture neuron (per v19.5 Skills) for the IKA team\'s use during v3.0 + v3.5 development |
| Why | Lets Claude (me) and Codex understand cross-file dependencies in the 270KB+ vanilla msp index.html, the Paperclip fork, the React+Vite app, etc. |
| Vetting tier | Community-vetted — confirm-on-install (3.7k stars + MIT + named author = good signal; passes our standard vetting checks) |
| Concrete value | "What other parts of msp index.html call openBrand?" → graph query in seconds vs grepping a 22k-line file |
Use case 2 — Layer 6 of the token-optimizer stack
| Layer | What it adds vs the existing /tokens 5-layer stack |
| Layer 6 (NEW) | Graph-based context selection on the codebase. Instead of grepping or dumping whole files into context, agents query the Graphify-built graph for relevant nodes + neighborhood. 71.5× reduction on codebase Q&A workloads. Composes with the existing 5 layers (RTK still filters shell output below; Layer 1 prompt caching still discounts the cached portion above; etc.). |
Combined-stack effect: ~50–70% reduction from the 5 layers + an additional multiplicative reduction on codebase-touching queries from Graphify. Most relevant for the Builder + dev-agent workloads, not for prosumer Operations queries.
What we DON\'T use Graphify for
| Not for | Why | What we use instead |
| Per-IKA user-content graph (entities, relationships, sharing) | Graphify is single-user single-repo + code-specific; not designed for prosumer entity graphs | Per-IKA Postgres + the v15 ACL + the v8 drag-drop matrix gives us the relationship layer for free; for natural-language Q&A over user content we use Microsoft GraphRAG-style or a custom pgvector + relationship adapter |
| Operations agent reasoning over a tenant\'s data | Tenant data is in our Postgres (rows, ACL-filtered), not in a NetworkX file | Agents query Postgres directly via the Paperclip API + permissions enforced at query time |
| Multi-tenant deploy | Graphify\'s build process assumes a single working directory | If we ever wanted per-tenant code graphs, we\'d run a Graphify instance per tenant in a container — overkill for v0 |
Comparison vs alternatives we\'d consider for the IKA user-content graph
| Tool | Domain | Multi-tenant | Real-time | License | Fit for IKA user content |
| Graphify | Code + docs | Single-user | Re-run or watch.py | MIT | Wrong domain — adopt for codebase only |
| Microsoft GraphRAG | Any text corpus | Per-corpus | Re-build periodic | MIT | Promising for content Q&A; needs adaptation for per-IKA isolation |
| Neo4j / Memgraph | Any (general graph DB) | Yes (multi-DB) | Real-time | GPL / Commercial | Heavy infra; we\'d use Postgres relationships + pgvector instead unless we hit query patterns Postgres can\'t handle |
| pgvector + ltree | Any (Postgres extension) | Yes (per-IKA DB) | Real-time | PostgreSQL | Best fit for IKA — already in our infra (per the v15+ schema), supports semantic search + tree relationships |
| Logseq / Obsidian / Roam | Personal notes | Per-vault | Real-time (local) | Mixed (LGPL / commercial / proprietary) | User-app territory — IKA Operations is the product, not these |
| Mem.ai | Personal AI notes | Per-user | Real-time | Proprietary SaaS | Competitor space — we\'re building IKA Concierge to BE this category |
Recommended adoption
Action plan — two parallel tracks
Track 1 — Codebase graph (Graphify)
- Install Graphify in main/Engineering/Architecture neuron as a Skill (community-vetted tier; confirm-on-install per v19.5). 1 hour.
- Run
/graphify on the v2 Flutter codebase as part of the Timeline-port spike — surfaces cross-file relationships before we lift code.
- Run
/graphify on the v3.0 hybrid codebase as it grows — keeps Claude oriented in the React+vanilla bridge.
- Add as Layer 6 of the token-optimizer stack in /tokens — graph-based context selection for codebase Q&A.
- Document in /ika-pro-architecture Skills section + token stack section.
Track 2 — User-content graph (pgvector + ltree + GraphRAG patterns)
- Enable
pgvector + ltree extensions on each per-IKA Postgres database (~1 hour per DB).
- Schema additions:
path ltree column on neurons; embedding vector(1536) on notes/projects/tasks/docs/forms.
- Background embedding job (Anthropic's embedding endpoint or self-hosted) — populates and refreshes on entity edit.
- Query layer in Paperclip combining ACL + ltree path + pgvector similarity + Postgres GIN full-text.
- Borrow Microsoft GraphRAG's entity-extraction + community-detection pipeline (don't adopt their codebase wholesale; lift the pattern, implement against our schema).
- Document as the v3 Operations content-graph layer in /ika-pro-architecture.
Effort summary
| Track | Effort | Risk |
| 1 (Graphify codebase skill) | ~1 day total (install + initial runs + Layer 6 wiring) | Low — single tool, isolated to Engineering neuron, well-scoped |
| 2 (User-content graph) | ~2 weeks total (extensions + schema + embedding job + query layer + GraphRAG patterns) | Medium — touches multiple per-IKA databases; embedding job needs cost monitoring; query-layer changes affect every Operations agent |
Open questions
- Greenlight Graphify install in Engineering neuron + add as Layer 6 token-stack?
- For the user-content graph — should we evaluate Microsoft GraphRAG separately, or commit to the pgvector + relationship adapter approach for v0?
- Graphify\'s 71.5× reduction is impressive but unverified by us — worth a 1-day benchmark on the actual msp/main vanilla codebase before committing to it as a Layer 6 element?
Sources: graphify.net · github.com/microsoft/graphrag · pgvector docs · ltree docs · Neo4j · Memgraph · TerminusDB. On-disk at build/web/bi/main/graph/index.html (the earlier /graphify/ path remains as legacy mirror). Companion: /tokens, /gstack, /ika-pro-architecture.