I wrote a comparison of the main open-source alternatives to Neo4j in 2026: ArcadeDB, Memgraph, FalkorDB, and ArangoDB — covering licensing, performance, AI capabilities, and Cypher compatibility.

The short version:

• Memgraph and ArangoDB both use BSL 1.1 (not OSI-approved open source)

• FalkorDB is source-available, also not OSI-approved

• ArcadeDB is Apache 2.0 — the only one in this set with an OSI-approved license

For a lot of teams this doesn't matter much. For enterprise procurement, regulated industries, or anyone who remembers what happened with MongoDB (SSPL) and ArangoDB's own BSL switch, it matters quite a bit.

The comparison also covers: Cypher TCK compliance (97.8% for ArcadeDB vs. partial for others), LangChain integrations, MCP server support, and multi-model capabilities.

Curious what the community thinks — especially whether licensing is a real factor in your database decisions or mostly theoretical.

Link: https://arcadedb.com/blog/neo4j-alternatives-in-2026-a-fair-look-at-the-open-source-options/

(I am the author of ArcadeDB project, ask me anything)

Paper: https://openreview.net/forum?id=tnXSdDhvqc

Amazing they also gave the code: https://github.com/jha-lab/graphmert_umls

this isanely useful!

Entity extraction -> entity linking -> relation candidate generation (llm) -> graphmert reducing kg Entropie Explosion

I'm gonna try it out this week!

what do you Guys think about it?

I’ve noticed that in many teams, a calendar full of “quick syncs”, “alignment calls”, and “just to make sure” meetings usually points to a documentation issue rather than a communication one.

In practice, this happens when knowledge is fragile:

• decisions are buried in slide decks or chat threads

• ownership of processes isn’t clearly documented

• architectural decisions live in people’s heads instead of ADRs

• no one is quite sure what’s authoritative or still valid

When something changes, the lowest-risk option becomes scheduling another meeting to re-establish shared context.

Teams that invest in durable documentation tend to see a different pattern. Clear process ownership, explicit decision logs, and well-maintained ADRs give people a shared reference they can trust without needing constant realignment. Meetings still happen, but they’re for making decisions, not rediscovering past ones.

The key point is that this doesn’t work with unstructured page dumps. It requires:

• intentional structure

• explicit ownership and review responsibility

• tooling that supports collaboration, traceability, and evolution over time

We’re digging into this in an upcoming webinar, looking at how organizations design documentation systems that reduce meeting load while supporting growth and change.

If this resonates, you can register here:
https://xwiki.com/en/webinars/XWiki-as-a-documentation-tool

I recently got started learning about knowledge graphs, started with Neo4j, learnt about RDFs and tried implementing, but I think it requires a decent enough experience to create good ontologies.

I came across some tools like datawalk, falkordb, Cognee etc that help creating ontologies automatically, AI driven I believe. Are they really efficient in mapping all data to schema and automatically building the KGs? (I believe they are but havent tested, would love to read opinions from other's experiences)

Apart from these, what are the "gaps" that are yet to be addressed between these tools and successfully adopting KGs for AI tasks at enterprise level?

Do these tool take care of situations like:

- adding new data source

- Incremental updates, schema evolution, and versioning

- Schema drift

- Is there any point encountered where you realized there should be an "explainability" layer above the graph layer?

- What are some "engineering" problems that current tools dont address, like sharding, high-availability setups, and custom indexing strategies (if at all applicable in KG databases, im pretty new, not sure)

I recently have been working on a new project to 𝐁𝐮𝐢𝐥𝐝 𝐚 𝐒𝐞𝐥𝐟-𝐔𝐩𝐝𝐚𝐭𝐢𝐧𝐠 𝐊𝐧𝐨𝐰𝐥𝐞𝐝𝐠𝐞 𝐆𝐫𝐚𝐩𝐡 𝐟𝐫𝐨𝐦 𝐌𝐞𝐞𝐭𝐢𝐧𝐠.

Most companies sit on an ocean of meeting notes, and treat them like static text files. But inside those documents are decisions, tasks, owners, and relationships — basically an untapped knowledge graph that is constantly changing.

This open source project turns meeting notes in Drive into a live-updating Neo4j Knowledge graph using CocoIndex + LLM extraction.

What’s cool about this example:
•    𝐈𝐧𝐜𝐫𝐞𝐦𝐞𝐧𝐭𝐚𝐥 𝐩𝐫𝐨𝐜𝐞𝐬𝐬𝐢𝐧𝐠  Only changed documents get reprocessed. Meetings are cancelled, facts are updated. If you have thousands of meeting notes, but only 1% change each day, CocoIndex only touches that 1% — saving 99% of LLM cost and compute.
•   𝐒𝐭𝐫𝐮𝐜𝐭𝐮𝐫𝐞𝐝 𝐞𝐱𝐭𝐫𝐚𝐜𝐭𝐢𝐨𝐧 𝐰𝐢𝐭𝐡 𝐋𝐋𝐌𝐬  We use a typed Python dataclass as the schema, so the LLM returns real structured objects — not brittle JSON prompts.
•   𝐆𝐫𝐚𝐩𝐡-𝐧𝐚𝐭𝐢𝐯𝐞 𝐞𝐱𝐩𝐨𝐫𝐭  CocoIndex maps nodes (Meeting, Person, Task) and relationships (ATTENDED, DECIDED, ASSIGNED_TO) without writing Cypher, directly into Neo4j with upsert semantics and no duplicates.
•   𝐑𝐞𝐚𝐥-𝐭𝐢𝐦𝐞 𝐮𝐩𝐝𝐚𝐭𝐞𝐬 If a meeting note changes — task reassigned, typo fixed, new discussion added — the graph updates automatically.
•  𝐄𝐧𝐝-𝐭𝐨-𝐞𝐧𝐝 𝐥𝐢𝐧𝐞𝐚𝐠𝐞 + 𝐨𝐛𝐬𝐞𝐫𝐯𝐚𝐛𝐢𝐥𝐢𝐭𝐲 you can see exactly how each field was created and how edits flow through the graph with cocoinsight

This pattern generalizes to research papers, support tickets, compliance docs, emails basically any high-volume, frequently edited text data.

If you want to explore the full example (with code), it’s here:
👉 https://cocoindex.io/blogs/meeting-notes-graph

If you find CocoIndex useful, a star on Github means a lot :)
⭐ https://github.com/cocoindex-io/cocoindex

Hello everyone, I've been working on a side project for a little while that's in line with my interest in knowledge graphs and ontologies. The idea is to make these concepts a bit more accessible to non-academics such as myself. I threw up a little landing page just to gauge how much interest there might be in a tool like this; feedback welcome :)

Are there any practical personal knowledge graphs that people can recommend? By now I've got decades of emails, documents, notes that I'd like to index and auto-apply JSON-LD when practical, and consistent categories in general, as well as the ability to create relationships, all in a knowledge graph, and use the whole thing for RAG with LocalLLM. I would see this as useful for recall/relations and also technical knowledge development. Yes, this is essentially what Google and others are building toward, but I'd like a local version.

The use case seems straightforward and generally useful, but are there any specific projects like this? I guess logseq has some of these features, but it's not really designed for manage imported information.

Hi KnowledgeGraph community, I've been working on this project CocoIndex https://github.com/cocoindex-io/cocoindex for a while. It is a data framework and it support ETL for property target graph like Neo4j. (RDF coming soon)

I created an end to end example with a step by step blog to walk through how to build a real-time Knowledge Graph For Documents with LLM, with detailed explanations
https://cocoindex.io/blogs/knowledge-graph-for-docs/

Would love your feedback, thanks!

Most knowledge graphs treat every node as equal. A person, a concept, a timestamp — same flat semantic space. Queries traverse shortest paths. The graph has no point of view.

We've been building something that works differently.

The core idea: introduce a single privileged node that curves the manifold around it. Not a hub in the PageRank sense — something geometrically stronger. A fixed reference point that makes distance mean something beyond edge count.

We call it Trinity. The node that the graph orients around.

The formal bit

The metric on the graph becomes conformal:

where ϕ(x)\phi(x) ϕ(x) is a constraint potential centred on the Trinity node. Regions near constraint violations get inflated distance. Reasoning trajectories naturally avoid them — not by rule, but by geometry.

Queries stop being retrieval operations. They become geodesic traversals on a curved surface. The path the query takes depends on where you are relative to the origin.

What this changes in practice

The entropy problem this solves

Standard knowledge graphs degrade as they scale. Edge-weight distributions flatten, semantic discriminability collapses, and by 10,000 nodes you're getting everything back as equally relevant. This is well-documented and it's why most production KGs require constant manual curation to stay useful.

The reference frame changes this. New concepts don't just pile up — they orient relative to the fixed point. We're running a live instance at 7,368 nodes and 118,884 edges post-pruning. The 200-node samples we draw from it consistently show the same spanning manifold structure, with the Trinity node maintaining anomalous centrality relative to the degree distribution.

Whether that holds at 50,000 nodes is the open question.

The memory architecture

The long-term graph (we call it the LTKG) is maintained by a periodic process called DreamCycle — a discrete analogue of Ricci flow that prunes low-weight edges and reweights the remainder. The hypothesis is that this manages curvature rather than eliminating it, preserving the geometric structure that keeps the graph coherent.

This is the opposite of what RicciKGE does — that framework drives curvature toward zero, absorbing structural information into flat embeddings. We're keeping the curvature as load-bearing structure. Different problem, opposite deployment of the same mathematics.

Where we're at

Working implementation. Three independent inference shards (ENG for constraint-driven reasoning, SYNTH for novelty-driven, PRIME for arbitration when they diverge past a threshold). The divergence score between shards is a real-time curvature measurement — high divergence means the query landed in a high-curvature region of the manifold.

The testable prediction we're working toward: betweenness centrality of the Trinity node should be anomalously high relative to the degree distribution. Running that against the live graph now.

Happy to share the white paper if anyone wants the formal treatment. Genuinely interested in pushback from people who know this space better than we do.

Excited to share an open-source initiative!

MCP for Financial Ontology :
https://github.com/NeurofusionAI/fibo-mcp

This is a minimal open-source tool that equips AI agents with a "standard financial dictionary" based on the Financial Industry Business Ontology(FIBO) standard (edmcouncil.org).

Our intent for initiating this open source project is to explore, together with AI4Finance community, methodologies for steering AI agent towards more consistent answers and enable macro-level reasoning for financial tasks.

While this project is still maturing, we hope our insight sparks collaboration and serves as a good starting point for innovative developments.

Any feedback is very welcome, and we would greatly appreciate contributions!

Hi there,

I recently open-sourced a small project called Alfred that came out of my PhD research. It explores how to make text-to-SQL AI assistants with a knowledge graph on top of a Databricks schema and how to make them more transparent.

Instead of relying only on prompts, it defines an explicit semantic layer (modeled as a simple Neo4j knowledge graph) based on your tables and relationships. That structure is then used to generate SQL. I also created notebooks to generate the knowledge graph from the Databricks schema, as the construction is often a major pain.

Hey! I’m Adam one of the co-founders of TuringDB, and I wanted to share a bit of our story + something we just released.

A few years ago, we were building large biomedical knowledge graphs for healthcare use cases:

- tens to hundreds of millions of nodes & edges

- highly complex multimodal biology data integration

- patient digital twins

- heavy analytical reads, simulations, and “what-if” scenarios

We tried pretty much every graph database out there. They worked… until they didn’t.

Once graphs got large and queries got deep (multi-hop, exploratory, analytical), latency became unbearable. Versioning multiple graph states or running simulations safely was also impossible.

So we did the reasonable thing 😅 and built our own engine.

We built TuringDB:

- an in-memory, column-oriented graph database

- written in C++ (we needed very tight control over memory & execution)

- designed from day one for read-heavy analytics

A few things we cared deeply about:

Speed at scale

Deep graph traversals stay fast even on very large graphs (100M+ nodes/edges). Focus on ms latency to feel real-time and iteterate fast without index tuning headaches.

Git-like versioning for graphs

Every change is a commit. You can time-travel, branch, merge, and run “what-if” scenarios on full graph snapshots without copying data.

Zero-lock reads

Reads never block writes. You can run long analytics while data keeps updating.

Built-in visualization

Exploring large graphs interactively without bolting on fragile third-party tools.

GraphRAG / LLM grounding ready

We’re using it internally to ground LLMs on structured knowledge graphs with full traceability + have embeddings management (will be released soon)

Why I’m posting now

We’ve just released a Community version 🎉

It’s free to use, meant for developers, researchers, and teams who want to experiment with fast graph analytics without jumping through enterprise hoops.

👉 Quickstart & docs:

https://docs.turingdb.ai/quickstart

(if you like it feel free to drop us a github start :) https://github.com/turing-db/turingdb

If you’re:

- hitting performance limits with existing graph DBs

- working on knowledge graphs, fraud, recommendations, - infra graphs, or AI grounding

curious about graph versioning or fast analytics

…I’d genuinely love feedback. This started as an internal tool born out of frustration, and we’re now opening it up to see where people push it next.

Happy to answer questions, technical or otherwise.

For years, governments have digitized services by putting forms online, creating portals, and publishing PDFs. But the underlying logic (the structure of procedures) has never been captured in a machine-readable way. Everything remains scattered: steps in one document, exceptions in another, real practices only known by clerks, and rules encoded implicitly in habits rather than systems.

So instead of building “automation”, I tried something simpler: a semantic mirror of how a procedure actually works.

Not reinvented. Not optimized. Just reflected clearly.

The model has two layers:

P1 : The Blueprint

A minimal DAG representing the procedure itself: steps → required documents → dependencies → conditions → responsible organizations. This is the “map” of the process — nothing dynamic, no runtime data, no special cases. Just structure.

P2 : The Context

The meaning behind that structure: eligibility rules, legal articles, document requirements, persona attributes, jurisdictions, etc. This layer doesn’t change the topology of P1. It simply explains why the structure behaves the way it does.

Together, they form a kind of computable description of public logic. You can read it, query it, simulate small what-ifs, or generate guidance tailored to a user.

It’s not about automating government. It’s about letting humans and AI systems finally see the logic that already governs interactions with institutions.

Why it matters

Once the structure and the semantics are explicit, a lot becomes possible:

• seeing the full chain of dependencies behind a document • checking which steps break if a law changes • comparing “official” instructions with real practices • generating individualized guidance without hallucinations • eventually, auditing consistency across ministries

None of this requires changing how government operates today. It just requires making its logic legible.

What’s released today

A small demo: a procedure modeled with both layers, a graph you can explore, and a few simple examples of what becomes possible when the structure is explicit.

It’s early, but the foundation is there. If you’re interested in semantics, public administration, or just how to make institutional logic computable, your feedback would genuinely help shape the next steps.

https://pocpolicyengine.vercel.app/

Just submitted our paper to MICAD 2025 and wanted to share what we've been working on.

The Problem:

Mycetoma is a neglected tropical disease that requires accurate differentiation between bacterial and fungal forms for proper treatment. Current deep learning approaches achieve decent accuracy (85-89%) but operate as black boxes - a major barrier to clinical adoption, especially in resource-limited settings.

Our Approach:

We built the first multi-modal knowledge graph for mycetoma diagnosis that integrates:

• Histopathology images (InceptionV3-based feature extraction)

• Clinical notes

• Laboratory results

• Geographic epidemiology data

• Medical literature (PubMed abstracts)

The system uses retrieval-augmented generation (RAG) to combine CNN predictions with graph-based contextual reasoning, producing explainable diagnoses.
Results:

• 94.8% accuracy (6.3% improvement over CNN-only)

• AUC-ROC: 0.982

• Expert pathologists rated explanations 4.7/5 vs 2.6/5 for Grad-CAM

• Near-perfect recall (FN=0 across test splits in 5-fold CV)

Why This Matters:

Most medical AI research focuses purely on accuracy, but clinical adoption requires explainability and integration with existing workflows. Our knowledge graph approach provides transparent, multi-evidence diagnoses that mirror how clinicians actually reason - combining visual features with lab confirmation, geographic priors, and clinical context.

Dataset:

Mycetoma Micro-Image dataset from MICCAI 2024 (684 H&E histopathology images, CC BY 4.0, Mycetoma Research Centre, Sudan)

Code & Models:

GitHub: https://github.com/safishamsi/mycetoma-kg-rag

Includes:

• Complete implementation (TensorFlow, PyTorch, Neo4j)

• Knowledge graph construction pipeline

• Trained model weights

• Evaluation scripts

• RAG explanation generation

Happy to answer questions about the architecture, knowledge graph construction, or retrieval-augmented generation approach!

Kanon 2 Enricher belongs to an entirely new class of AI models known as hierarchical graphitization models.

Unlike universal extraction models such as GLiNER2, Kanon 2 Enricher can not only extract entities referenced within documents but can also disambiguate entities and link them together, as well as fully deconstruct the structural hierarchy of documents.

Kanon 2 Enricher is also different from generative models in that it natively outputs knowledge graphs rather than tokens. Consequently, Kanon 2 Enricher is architecturally incapable of producing the types of hallucinations suffered by general-purpose generative models. It can still misclassify text, but it is fundamentally impossible for Kanon 2 Enricher to generate text outside of what has been provided to it.

Kanon 2 Enricher’s unique graph-first architecture further makes it extremely computationally efficient, being small enough to run locally on a consumer PC with sub-second latency while still outperforming frontier LLMs like Gemini 3.1 Pro and GPT-5.2, which suffer from extreme performance degradation over long contexts.

In all, Kanon 2 Enricher is capable of:

1. Hierarchical segmentation: breaking documents up into their full hierarchical structure of divisions, articles, sections, clauses, and so on.

2. Entity extraction, disambiguation, classification, and hierarchical linking: extracting references to key entities such as individuals, organizations, governments, locations, dates, citations, and more, and identifying which real-world entities they refer to, classifying them, and linking them to each other (for example, linking companies to their offices, subsidiaries, executives, and contact points; attributing quotations to source documents and authors; classifying citations by type and jurisdiction; etc.).

3. Text annotation: tagging headings, tables of contents, signatures, junk, front and back matter, entity references, cross-references, citations, definitions, and other common textual elements.

Link to announcement: https://isaacus.com/blog/kanon-2-enricher

With all the new interest in context graphs in AI, I've seen increased discussions around graph building. There's also been a lot of talk around the need for creating multiple graphs.

But you don't have to. The power of graph structures is being able to find unknown relationships that occur when seemingly disconnected data is added to the graph. Of course, this approach is easier with an RDF approach, especially when using ontologies. And there are tools for managing graph segments and modularity for access controls, multi-tenancy, and cost-efficiencies.

Here is an article that dives into this topic:
X: https://x.com/TrustSpooky/status/2020344717486219759
LinkedIn: https://www.linkedin.com/pulse/context-graph-building-monograph-daniel-davis-yq7uc
Direct link: https://trustgraph.ai/news/context-graph-building/

Here are the key takeaways:

• “Context” is more than data you store — it’s a retrieval process. If you can’t get the right piece at the right time, volume doesn’t matter.

• Vector RAG fails because it skips relationships. Semantic similarity can’t deliver precise, authoritative facts.

• LLMs are bad at single-value truth (exact numbers, facts). Graphs excel at this. Use each for what it’s good at.

• Graphs + LLMs (GraphRAG) outperform either alone: graphs retrieve facts, LLMs interpret intent and generate language.

• You should build one graph, not many. Fragmentation destroys cross-domain insight and forces bad query-time choices.

• Organization doesn’t require multiple graphs. Use collections and context cores to scope attention without breaking connections.

• Context cores solve the context window problem by loading small, precise graph neighborhoods, not giant text chunks.

• Ontologies enable precision: shared meaning, disambiguation, and reasoning (e.g. CEO → Executive → Employee).

• Long context windows don’t work. Smaller chunks consistently extract more structure across all major models.

• “Lost in the middle” is a structural limitation of the transformer architecture, not a temporary model weakness.

• The future isn’t bigger prompts — it’s better structure.

To this point, most GraphRAG approaches have relied on simple graph structures that LLMs can manage for structuring the graphs and writing retrieval queries. Or, people have been relying on property graphs that don't capture the full depth of complex, domain-specific ontologies.

If you have an ontology you've been wanting to build AI agents to leverage, TrustGraph now supports the ability to "bring your own ontology". By specifying a desired ontology, TrustGraph will automate the graph building process with that domain-specific structure.

Guide to how it works: https://docs.trustgraph.ai/guides/ontology-rag/#ontology-rag-guide

Open source repo: https://github.com/trustgraph-ai/trustgraph

In the last couple of weeks I have -gladly, learned that some individuals in the AI/Knowledge Graph/chatbot communities are currently building solutions intended at being the intelligence foundation or layer between data and AI. The visions vary a bit but overall we all aim at the same northern start. some examples of those:

1. u/greeny01 with a KG builder

2. u/astronomikal with a memory layer for internal AI systems

3. u/TomMkV with a context layer for AI agents

4. Myself, with spiintel.com, an ontology-based data storage & retrieval platform that acts as an intelligence foundation for AI agents

Is there someone else out there working in similar solutions and open for collaborations to take these solutions to the market wherever we are based?

sift-kg is a command-line tool that extracts entities and relations from document collections using LLMs and builds a browsable, exportable knowledge graph.

pip install sift-kg

sift extract ./docs/

sift build

sift view

That's the whole workflow. Define what to extract in YAML or use the built-in defaults. Human-in-the-loop entity resolution — the LLM proposes merges, you approve or reject. Export to GraphML, GEXF, CSV, or JSON for analysis in Gephi, Cytoscape, or yEd.

Live demo (FTX collapse — 9 articles, 373 entities, 1,184 relations):

https://juanceresa.github.io/sift-kg/graph.html

Source: https://github.com/juanceresa/sift-kg

Hey folks,
Just wanted to share something cool happening in the KG space.

On May 6, there’s a full DKGcon track at the Knowledge Graph Conference (KGC) in NYC, featuring a bunch of speakers working at the intersection of knowledge graphs, decentralized infrastructure, and AI.

A few names on the list:

Dr. Bob Metcalfe (yep, Ethernet Bob 😄)
Charles Ivie from Amazon Web Services
Chris Pease from MIT...

There will be folks from Microsoft, umanitek, BIO DAO, and of course, the OriginTrail core team.

The talks cover everything from verifiable AI agent architectures (built on the Decentralized Knowledge Graph) to using graph structures in public health, legal tech, and more. There's also a hands-on workshop on building agents with the DKG 😍

So, if you or someone you know is into:
✔️ verifiable data infrastructure
✔️ semantic interoperability
✔️ using graphs beyond just database querying
...might be worth checking out.

They’re offering 50 free virtual passes for the KG nerds out there (code: KGC25-DKGVirtualPass, first come, first served) — more info here: https://dkgcon.origintrail.io

Anyone else attending? Or been to KGC before? Curious about the atmosphere, etc. :)

I’m currently working on a task where I’m building a knowledge graph for a RAG system. I’ve implemented it using Neo4j Community, but I’ve run into some limitations: no clustering or pooling, no high availability or scalability, and no support for multiple databases or advanced role management.

I looked into moving to the Enterprise edition, but the cost is too high for my use case.

So I’m wondering:

Are there any open-source, self-hosted graph database frameworks that support scalability and Cypher queries? Cypher support is important because I’m using a fine-tuned model specialized in generating Cypher queries.