GraphNews

I'm excited to announce that DeepGraph AI is open-sourcing GraphLite—the first fully open-source embedded graph database implementing the ISO GQL standard (ISO/IEC 39075:2024) in Rust.

As I’ve been diving deep into Graph RAG, one of my colleagues asked me to compare different graph databases. That got me thinking — it’s…

The world of graph technology is vast and evolving. We're here to help you make sense of the key trends and players.

Learn more about how the latest release of G.V() now supports RDF triplestores and the SPARQL query language with autocomplete, visualization, and more.

After seeing yet another Graph RAG demo using Neo4j with no ontology, I decided to show what real semantic Graph RAG looks like. The Problem with Most Graph RAG Demos: Everyone's building Graph RAG with LPG databases (Neo4j, TigerGraph, Arrango etc.) and calling it "knowledge graphs." But here's the thing: Without formal ontologies, you don't have a knowledge graph—you just have a graph database. The difference? ❌ LPG: Nodes and edges are just strings. No semantics. No reasoning. No standards. ✅ RDF/SPARQL: Formal ontologies (RDFS/OWL) that define domain knowledge. Machine-readable semantics. W3C standards. Built-in reasoning. So I Built a Real Semantic Graph RAG Using: - Microsoft Agent Framework - AI orchestration - Formal ontologies - RDFS/OWL knowledge representation - Ontotext GraphDB - RDF triple store - SPARQL - semantic querying - GPT-5 - ontology-aware extraction It's all on github, a simple template as boilerplate for you project: The "Jaguar problem": What does "Yesterday I was hit by a Jaguar" really mean? It is impossible to know without concept awareness. To demonstrate why ontologies matter, I created a corpus with mixed content: 🐆 Wildlife jaguars (Panthera onca) 🚗 Jaguar cars (E-Type, XK-E) 🎸 Fender Jaguar guitars I fed this to GPT-5 along with a jaguar conservation ontology. The result? The LLM automatically extracted ONLY wildlife-related entities—filtering out cars and guitars—because it understood the semantic domain from the ontology. No post-processing. No manual cleanup. Just intelligent, concept-aware extraction. This is impossible with LPG databases because they lack formal semantic structure. Labels like (:Jaguar) are just strings—the LLM has no way to know if you mean the animal, car, or guitar. Knowledge Graphs = "Data for AI" LLMs don't need more data—they need structured, semantic data they can reason over. That's what formal ontologies provide: ✅ Domain context ✅ Class hierarchies ✅ Property definitions ✅ Relationship semantics ✅ Reasoning rules This transforms Graph RAG from keyword matching into true semantic retrieval. Check Out the Full Implementation, the repo includes: Complete Graph RAG implementation with Microsoft Agent Framework Working jaguar conservation knowledge graph Jupyter notebook: ontology-aware extraction from mixed-content text https://lnkd.in/dmf5HDRm And if you have gotten this far, you realize that most of this post is written by Cursor ... That goes for the code too. 😁 Your Turn: I know this is a contentious topic. Many teams are heavily invested in LPG-based Graph RAG. What are your thoughts on RDF vs. LPG for Graph RAG? Drop a comment below! #GraphRAG #KnowledgeGraphs #SemanticWeb #RDF #SPARQL #AI #MachineLearning #LLM #Ontology #KnowledgeRepresentation #OpenSource #neo4j #graphdb #agentic-framework #ontotext #agenticai | 148 comments on LinkedIn

Why graph databases aren’t the silver bullet some hoped for, and where the technology is heading next.

One of the most critical decisions when building a new graph database is the query language. It’s the primary interface for developers, and…

Since I'm not at #ISWC2025, it's more easy for me to speak up. There are ginormous issues with QLever and the associated Sparqloscope benchmark by Hannah Bast and colleagues. The main results table already shows something that's too good to be true. And while I'm sure that table is technically true, the tacit implication that this table has any bearing on real-world performance, is false. QLever is faster than the state of the art… at COUNTing. That's it. QLever can count faster. The implication is that this would mean QLever can also produce results faster. Yet we have zero reason to assume it can—until there's proof. In the real world, query engines rarely compute all results at once. They stream those results. The Sparqloscope benchmark is designed to trick established query engines into actually producing the result set and counting items. And you know what? Sometimes, the established engines are even faster at that than QLever, which seems to be purposefully designed to count fast. Yes—I'm sure QLever is a fast counter. But what on earth does that have to do with real-world streaming query performance? And did I mention that Virtuoso supports SPARQL UPDATE? How can you tell, just from the table? Well, Virtuoso is faster than QLever for just about anything that doesn't rely on pure counting. QLever does “Regex: prefix” or “Filter: English literals” in the ridiculously fast 0.01s? The only rational explanation is that it has a great structure for specifically this kind of counting (again, not results, just count). But Virtuoso is faster for “strbefore”? Well, there you see the real QLever performance when it cannot just count. And only one of those strategies has impact on the real world. So what if a query engine can count faster than any other to 65,099,859,287 (real result BTW). Call me when you can produce 65,099,859,287 results faster, then we'll have something to talk about. In the first place, it's a major failure of peer review that a benchmark based on COUNT was accepted. And I'd be very happy to be proven wrong: let's release the benchmark results for all engines, but without COUNT this time. Then we'll continue the conversation. https://lnkd.in/eT5XrR2k | 19 comments on LinkedIn

Azure Cosmos DB is a multi-model database service that supports various data models, including key-value, column-family, document, and…

🚀 From MSFT earnings call yesterday: Cosmos DB business grew 50% YoY in FY26 Q1! Deeply grateful for our customer's trust.❤️ Proud for Cosmos DB team to be recognized in Satya's earnings call yesterday. Also excited for our sister database SQL Hyperscale for landing nearly 75% YoY growth! Hard work leads to great results - congrats teams! Keep at it! 💪 🎉 https://lnkd.in/gGNfJtMb

We are thrilled to be the new stewards of Dgraph at Istari Digital! looking forward to building the next data platform for digital engineering.

Learn how TypeDB combines graph semantics with strong schema and reasoning to model complex domains.

Facebook, one of the world's largest social media platforms, fundamentally organizes its billions of users and their interactions as a vast social network. At the heart of this organization lies the concept of a graph—a mathematical structure consisting of nodes (or vertices) connected by edges (or

Calling all Graph Explorers! 📣 I'm excited to share that open-source Graph Explorer v2.4.0 is now released, and it includes a new SPARQL editor! Release notes: https://lnkd.in/ePhwPQ5W This means that in addition to being a powerful no-code exploration tool, you can now start your visualization and exploration by writing queries directly in SPARQL. (Gremlin & openCypher too for Property Graph workloads). This makes Graph Explorer an ideal companion for Amazon Neptune, as it supports connections via all three query languages, but you can connect to other graph databases that support these languages too. 🔹 Run it anywhere (it's open source): https://lnkd.in/ehbErxMV 🔹 Access through the AWS console in a Neptune graph notebook: https://lnkd.in/gZ7CJT8D Special thanks go to Kris McGinnes for his efforts. #AWS #AmazonNeptune #GraphExplorer #SPARQL #Gremlin #openCypher #KnowledgeGraph #OpenSource #RDF #LPG

Explore the latest insights and updates from RyuGraph

A first look at TypeDB 3 benchmarks, showing great performance at scale, real-world OLTP workloads, and comparisons to previous versions, and Neo4j.

An open-source Text2SQL tool that transforms natural language into SQL using graph-powered schema understanding. Ask your database questions in plain English, QueryWeaver handles the weaving. - Fal...

DuckDB community extension that adds support for SQL/PGQ and graph algorithms

Explore an iterative verification and correction refinement process aimed at improving Text2Cypher performance.

Graph database implementing the RDF and SPARQL standards. Very fast and scales to hundreds of billions of triples on a single commodity machine. - ad-freiburg/qlever

When we present QLever, people often ask "how is this possible" as our speed and scale is on another dimension. We now have a page in the wiki that goes into a bit more detail on why and how this is possible. In short: • Purpose built for large scale graph data, not retrofitted • Indexing optimized for fast queries without full in-memory loading • Designed in C++ for efficiency and low overhead • Integrated full text and spatial search in the same engine • Fast interactive queries even on hundreds of billions of triples Link to the wiki page in the comments.

Qlever: graph database implementing the RDF and SPARQL standards. Very fast and scales to hundreds of billions of triples on a single commodity machine. Sounds to good to be true, anyone tested this out? https://lnkd.in/esXKt79J #GraphDatbase #ontology #RDF | 14 comments on LinkedIn

Discover how LMPG transforms graph databases by treating properties as first-class citizens rather than simple node attributes. This comprehensive technical guide explores RushDB's groundbreaking architecture that enables automatic schema evolution, property-first queries, and cross-domain analytics impossible in traditional property graphs or RDF systems.

: Users left wondering whether to fork it or forget it as another FOSS project bites the dust

It's with deep gratitude for the amazing product the #KuzuDB team created, and a mix of necessity and excitement, that I announce the launch of Ladybug. This is a new open-source project and a community-driven fork of the popular embedded graph database.

Kuzu is no more The project was archived last night with one last major release. The communication has not been very clear, but I can bet Semih Salihoğlu is under a lot of pressure and I am looking forward to hearing the full story someday. We liked the product and will fork it and continue supporting it as a way for our users to run local memory workloads on their machines. We'll not support it in production anymore though, since we are not database developers and don't plan to be. You can only get that far without the need to grow a mighty Unix beard. Instead, we'll be going with Neo4j for larger loads and our partner Qdrant for embeddings + extend our FalkorDB and Postgres support. It does feel a bit strange when your default DB disappears overnight. That is why cognee is database agnostic and all features that were Kuzu specific will be migrated in about 2 weeks. This time we were just too fast for our own good. | 47 comments on LinkedIn

Last week, the Kùzu Inc team announced that they will no longer actively support the open-source KuzuDB project. I've been a fan of KuzuDB and think its discontinuation leaves a big gap in the graph ecosystem. This is especially the case for open-source solutions – over the last few years, many open-source graph database systems were forked, relicensed or discontinued. Currently, users looking for an OSS graph database are left to pick from: - community editions of systems with enterprise/cloud offerings (Neo4j, Dgraph) - variants of a heavily-forked system (ArcadeDB / YouTrackDB, HugeGraph) - projects under non-OSI approved licenses - experimental systems (e.g., DuckPGQ) I'm wondering whether this trends continues or someone steps up to maintain KuzuDB or create a new OSS system.

For years, I considered graph databases “interesting but niche.” Relevant commercially for social networks, supply chain and academically for biotech, maybe some knowledge management. Basically, not something most companies would ever need. I stand corrected. With AI, they’re having a very big moment! Working with graphs the first time feels unusual but also just right. The best analogy I have is that feeling we get when we try to visualize a higher dimension when all we have ever known are three (+ time for the purists). (or is it just me?) Two use-cases that I have been riffing on: * Knowledge management: For me it started as a personal project for personal knowledge management. For enterprises, this is where RAG shines. But I also wonder if there are other applications within Enterprise Knowledge Management that we aren’t thinking of yet.  * Master Data Management (MDM): Potentially a subset of above, but explicitly about attributes and relationships that columnar databases might handle too rigidly. I am a lifetime subscriber for relational and SQL till they exist. Not saying they will go away. Graphs still feel intuitive and unusual at the same time. They are still complex to build (although companies like Neo4j simplify them really well), and difficult to traverse / interpret. I believe there is a stronger convergence of these 2 systems coming. Graphs will augment relational before replacing in some of these use-cases. But they have to be way more simplified first for greater adoption. Would love to hear more from graph experts and/or from those who share this feeling of “just right” for graphs. Are you seeing use-cases where graph databases are picking up? #AI #DataStrategy #Graphs #KnowledgeManagement #MDM | 37 comments on LinkedIn

Let's chat a bit about the use of graph databases in retrieval-augmented generation (RAG). One problem in GenAI is that while the LLMs are fed a lot of text during training, perhaps a model isn't fed the specific information the user is asking about, which could be in a private corporate document. Since the dawn of GenAI, pipelines have existed to store private documents in a vector database and search for text relevant to the user's question in the database. This text is then fed to the LLM for use in generating the answer to the user query. One problem in such pipelines is that the document search may retrieve a lot of text containing terms similar to those in the user query which still isn't relevant to answering the query. At this point, many folks say, "knowledge graphs to the rescue!" Knowledge graphs after all can store information about entities mentioned in private documents, so can't they help disambiguate user questions? Graph DBs have been used in RAG for some time now; I started with them in 2021, before ChatGPT existed. There are various problems with using graph data in RAG. First off, the knowledge graphs we are trying to leverage are themselves generated by machine learning. But what are the guarantees that ML engineers are training their models or agents to produce useful KGs? Are we even using the right kind of statistical learning, never mind agent architectures? After all, if you are going to build a KG based on information in natural language, then you are parsing out conceptual relations from natural language, which are dependent on syntax. So perhaps we should be utilizing machine learning in the syntactic parsing problem, so that we ensure a relation isn't added to the graph if the syntax expresses the negation of the relation, for instance. To graph data modelers, again I maintain that methods for extracting information from syntax have more bearing on the use of graph data in RAG than existing modeling techniques that fail to factor in natural language syntax just like most ML inference fails here. And perhaps graph databases aren't even the right target for storing extracted conceptual relations; I switched to logic databases after a month of working with graphs. The use of KGs and logic bases in RAG needs to be tackled through innovations in syntax parsing like semantic grammars, and through better techniques for performant inference engines than graph query, such as GPU-native parallel inference engines. This isn't a problem I expect to be solved through Kaggle competitions or corporate R&D leveraging recently minted ML engineers.

A sophisticated knowledge graph memory system that stores interconnected information with rich semantic structure using Neo4j. - shuruheel/mcp-neo4j-shan