Open Source Knowledge Graph Tools for Web Data

Open source knowledge graph tools split into four separate jobs, and treating them like one job causes most of the confusion in this space. Storage, extraction, retrieval, and memory each solve a different problem, and the tool that wins at one does nothing for the others. Reports from late 2025 suggested that a notable share of AI adopters had a knowledge graph in production, only marginally higher than the prior year. What shifted was earlier-stage activity, with fewer teams moving through initial exploration phases.

The bottleneck in most pipelines is rarely the graph database itself. The mess tends to live in prepping and assembling inputs before the graph gets built. Most teams get this backwards. They pick whatever product has the most stars on GitHub instead of asking which stage of their own pipeline is actually broken, and a graph database won't fix bad extraction any more than a nicer filing cabinet fixes bad handwriting. A GraphRAG framework won't fix a graph with no sense of time, either. Below is a map of where each tool earns its keep, and where the money and attention should go first. Spoiler: not storage.

Graph databases: the storage and query layer every pipeline eventually needs

This layer has one job: store nodes and relationships durably, traverse them fast, and answer queries from whatever agent or app sits downstream. It just holds the structure and answers questions about it, which sounds dull right up until the queries start timing out at 2am and someone's pager goes off.

Neo4j is the one most people have heard of, and the reputation is earned. Over 12,000 GitHub stars, a native graph model built down to the storage layer, and the Cypher query language for traversal. It supports ACID transactions, runtime failover, and cluster deployments, with drivers for Python, JavaScript, and.NET, the same languages most AI teams already write in. AuraDB is the managed cloud version for anyone who'd rather not run graph infrastructure themselves. Call it the safe default: mature, well documented, and unlikely to surprise anyone.

ArangoDB takes a different bet. With over 13,000 GitHub stars, it combines native graph storage with JSON documents and integrated search under one query language. That matters for pipelines that need to traverse relationships and pull document content without running two separate databases side by side, a burden most teams would rather skip.

Dgraph is built for scale from the ground up: over 19,000 GitHub stars, distributed architecture, native GraphQL support, geo and full-text search included. The intended audience is teams sitting on graph workloads big enough to outgrow a single machine fast, and not many teams actually are, no matter what the pitch deck says.

OrientDB spreads across graph, document, full-text, and geospatial models without needing runtime JOINs. Call it the generalist pick: good for projects that need flexibility across data shapes, even if that flexibility costs a bit of graph-native speed.

FalkorDB solves a narrower problem: latency. Its architecture is optimized for fast query execution, the gap between an agent that feels instant and one that feels like it's chewing on a question a toddler could answer in half a second. It's also the default backend for Graphiti MCP deployments, which comes up again in the temporal graph section below.

Apache Jena follows a different set of rules than property graphs. It runs on RDF triples and SPARQL queries instead, with reasoning built in over formal ontologies. Anyone required to conform to W3C standards, or needing to stitch together scattered semantic web sources, ends up here whether they wanted to or not.

Memgraph keeps the whole dataset in memory, which makes both analytical and transactional queries fast, and it plugs into Apache Kafka, MySQL, JSON, and CSV sources. Streaming pipelines where fresh data has to be queryable within seconds, not minutes, are the natural fit here.

JanusGraph is the workhorse for anyone already running Elasticsearch or Solr. It handles multithreading and horizontal scale, built for datasets too large to sit comfortably on one node.

Skip the popularity contest. Picking among these comes down to four questions: how much data, how fast the queries need to return, whether infrastructure gets self-hosted or handed to a cloud provider, and which query language the team already knows cold. Answer those first, then go pick a favorite logo.

Getting web content into a graph: entity extraction tools and the LLMs that power them

Extraction means finding entities, sorting out which mentions refer to the same thing, labeling how they relate, and outputting something structured (JSON, RDF, triples) that a graph database can load. This is where most of the mess from the adoption numbers above actually lives, and it's the part almost nobody budgets enough time for.

Raw HTML makes the job harder than it needs to be. A page that fits in roughly five thousand tokens as clean Markdown can balloon to ten times that as raw HTML, and all that extra markup just confuses extraction downstream. So before any entity gets pulled out of anything, the content has to arrive clean, and that's a separate job from extraction itself, one people routinely skip.

That's where web scraping tools do their quiet, unglamorous work. Firecrawl's open-source core renders JavaScript, crawls full sites, and hands back clean Markdown. It respects robots.txt and manages its own requests along the way. ScrapeGraphAI flips the usual scraping model: instead of writing CSS or XPath selectors, someone describes in plain language what data to pull, and the tool adapts on its own when a site's structure changes underneath it. It also released a dataset of roughly 93,695 real-world structured extraction examples, drawn from millions of user events, open on Hugging Face. Crawl4AI is another option for teams that want control over their own crawl logic instead of trusting a black box.

Once clean text is in hand, LLMs do the actual entity extraction, and few-shot prompting with a capable model now gets accuracy roughly in line with fully supervised traditional models, without needing a mountain of labeled training data first. DeepSeek-R1 runs a very large number of parameters in a Mixture-of-Experts setup with a 164K context window, built for complex, multi-hop relationship extraction across long documents. Qwen3-235B-A22B activates a small fraction of its total parameters, supports a 131K context window and over 100 languages, and switches between thinking and non-thinking modes, useful for multilingual graphs and pipelines that lean on automated tool-calling. GLM-4.5, also a very large MoE model, was built explicitly with agent applications in mind, so it fits workflows that need to call tools without a human sitting in the loop.

Neo4j's LLM Knowledge Graph Builder shows all of this stitched together in one working pipeline. Open-sourced and hosted since June 2024, it imports documents, splits them into chunks, extracts entities and relationships through a configurable LLM, and loads the result straight into Neo4j. It's now the fourth most popular source of user interaction on AuraDB Free, has closed over 400 GitHub issues, and has picked up more than 2,800 stars. It supports GPT-4o, Gemini 1.5 and 2.0, Qwen 2.5, Amazon Nova, Groq, Llama 3.x, Ollama models, and Claude 3.5 Sonnet, and swapping the model changes both extraction quality and cost, sometimes by a lot. It also accepts an optional graph schema that constrains which entity and relationship types the LLM can output, which matters a great deal once the graph grows past a toy dataset.

For teams that don't want to build an ontology from scratch, KBpedia offers a ready-made knowledge structure combining several public knowledge bases into one upper ontology, a shortcut for research work that needs fast interoperability rather than a custom schema built from zero.

One cost caveat runs across every LLM-based extractor here, and it's the one people forget until the bill lands: every document ingested costs at least one LLM call, and LLMs hallucinate. A graph can end up full of confident-looking facts that are simply wrong, tidy in a node-and-edge diagram right up until someone checks the source. Schema constraints and validation steps are the only thing standing between a clean graph and a very expensive game of telephone.

GraphRAG frameworks: answering questions over large document collections without rebuilding the graph each time

GraphRAG's job is retrieval. At query time, it uses the graph's own structure (clusters, community summaries, entity relationships) to pull better context than plain vector search would find, then generates an answer from it.

Microsoft GraphRAG is the reference implementation, though reference doesn't always mean practical. It builds a graph-based index with an LLM, derives the knowledge graph from source documents, and pre-generates community summaries using the Leiden clustering algorithm. At query time, it aggregates partial answers across related community summaries into one final response. It calls an LLM often, both during indexing and during retrieval, making it expensive and slow for a lot of production use cases. Stick with it only if the team is already committed to the Microsoft ecosystem and can absorb that token bill without flinching. Most teams can't, and shouldn't try.

LightRAG answers the high cost of running GraphRAG head-on. Built by researchers at the University of Hong Kong and Beijing University of Posts and Telecommunications, published at EMNLP 2025, and with over 28,000 GitHub stars in early 2026, it uses dual-level retrieval to match Microsoft GraphRAG's accuracy while cutting token usage by roughly an order of magnitude. For teams processing large volumes of documents every month, that drop in token usage adds up to real savings without giving up production-quality output. Published benchmarks also show it beating naive RAG, HyDE, and Microsoft GraphRAG on both retrieval accuracy and response quality. It keeps moving fast, too: As of March 2026 it had picked up RAGAS evaluation support, multimodal support, OpenSearch integration, and a setup wizard. Anyone who wants a research-backed GraphRAG baseline without paying Microsoft's token tax should start here, full stop.

A handful of lighter, more experimental frameworks exist for teams with tighter budgets or a need to iterate fast. fast-graphrag is a hackable, stripped-down GraphRAG baseline built for tinkering. KET-RAG pairs a sparse knowledge graph skeleton with a text-keyword bipartite graph, allowing retrieval at multiple levels of detail without the cost of building a full graph, useful exactly when a complete graph is too expensive to justify. MiniRAG unifies text and entity indexing into one semantically aware graph using lightweight topology-enhanced search, aimed at deployments where compute is genuinely scarce.

Neo4j's LLM Knowledge Graph Builder also ships a community summaries feature that acts as the practical middle ground between building nothing and building Microsoft's full pipeline. It runs Leiden clustering on the extracted entity graph, generates summary nodes at several levels of the hierarchy, and uses a global retriever to answer broad questions spanning many documents at once. Same GraphRAG idea, just wired directly into the graph store instead of living as a separate system. LightRAG's October 2025 update specifically improved extraction accuracy for open-source models like Qwen3-30B-A3B, which matters for teams trying to dodge proprietary model costs at the extraction stage, not just at query time.

The tradeoff running through this whole category is retrieval quality against token cost. Heavier frameworks that call the LLM constantly tend to produce better answers, no argument there. But lighter frameworks trade some of that accuracy for a bill that doesn't make finance ask questions, and for most production workloads, that's the trade worth making.

Temporal knowledge graphs: tracking facts that change and giving agents memory that persists

Standard knowledge graphs treat every fact as permanently true, and that breaks down fast because web data doesn't work that way. What was accurate last quarter can be dead wrong today, and an agent running across many sessions needs to update what it knows without throwing away everything it learned before.

Temporal knowledge graphs answer two questions a static graph simply can't: what was true on a specific date, and how has a given relationship changed over time. That framing is why slapping a timestamp column onto an existing graph never actually solves the problem.

Graphiti, built by Zep AI and open source, is the leading implementation of this idea, and it's not particularly close. It has accumulated a substantial GitHub following as a purpose-built temporal knowledge graph library for agent memory. It builds bi-temporal context graphs, tracking both valid time (when a fact was actually true in the real world, say, someone preferred a certain brand from September 2024 until March 2026) and transaction time (when the system learned that fact, and from what source). These context graphs get built automatically from structured and unstructured input alike, and Graphiti handles relationships that change while still keeping the full history behind them, rather than overwriting the old fact with the new one.

Retrieval combines semantic embeddings, BM25 keyword search, and direct graph traversal, with no LLM calls happening during retrieval itself, which keeps P95 latency around 300 milliseconds. A paper (arXiv:2501.13956) found Zep's implementation beat MemGPT on the Deep Memory Retrieval benchmark, 94.8% against 93.4%, a gap that looks small on paper but becomes visible the moment an agent has to recall something from three sessions ago and either nails it or doesn't. Multi-tenancy runs through group IDs, keeping one user's data from leaking into another's, a detail that starts mattering the second a product has more than one customer. Graphiti runs on Neo4j, FalkorDB, or Amazon Neptune (paired with OpenSearch Serverless), with Kuzu support now deprecated. It works with OpenAI, Azure OpenAI, Google Gemini, Anthropic, Groq, and local models through Ollama, and connects to Claude, Cursor, and other MCP-compatible clients through its own MCP server.

The same cost caveat from the extraction section applies here too: every episode Graphiti ingests needs an LLM call to pull entities out of it. Retrieval itself stays free of any model calls, though, so once the memory is built, querying it stays fast and the cost doesn't creep up over time. Expensive to build, cheap to query: that split is the whole point.

FalkorDB's part in this story traces back to the slow queries mentioned in the graph database section. Graphiti needs sub-second responses to feel usable inside an agent's conversation loop, so pairing it with a graph database built specifically for millisecond queries isn't a coincidence; it's the entire design decision. That's the reason FalkorDB exists as a default option.