I forked an archived graph database and started dreaming about healthcare AI

I Took an Archived Graph Database, Added Vector Search and LLM Embeddings – Here’s Why It Could Power Healthcare AI

I took an archived graph database, added vector search, LLM embeddings, and a full GDS suite – now I’m aiming to make it the central engine for healthcare AI. Here’s the architecture, the roadmap, and why I believe this is the right foundation for clinical analytics.

1. The Genesis

A month ago, I found Kùzu – an embedded analytical graph database that had been archived. I was curious, so I forked it and started poking around. I didn’t build this from scratch; I’m standing on the shoulders of the original authors, who did the heavy lifting of the core engine. My contributions so far are modest: a few C++ API extensions, some parser tweaks, and a handful of extensions that I thought might be useful.

This is very much a learning project. I’m not a database expert – I’m a software engineer who enjoys building systems and is fascinated by the intersection of graphs, AI, and healthcare. This post is my attempt to document what I’ve understood so far, where I see potential, and what I’m still struggling with.

2. What I’ve Actually Done (Honestly)

Let me be upfront: I did not write a database engine. The Kùzu team spent years building the columnar storage, the OpenCypher query processor, the ACID transaction manager, and the vectorized execution engine. That’s PhD-level work, and I respect it deeply.

Here’s what I actually contributed to Gorgonzola (my fork):

C/C++ API Extensions

• uint128_t support – Added full 128-bit unsigned integer types alongside int128_t and uuid, with arithmetic, comparison, and cast operators.
• gorgonzola_value_get_blob_with_size – The original get_blob truncated binary data at the first \0. This API returns the full buffer and its byte length. A small fix, but critical for binary data.
• Parser tweaks – Modified the Cypher grammar to accept leading zeros in numeric literals (00123 is now valid). Standardized vector function signatures across the board.

Wrapped Existing Algorithms into Extensions

• PageRank
• Betweenness Centrality
• WCC, SCC
• Louvain
• K-Core Decomposition
• Spanning Forest

Most of these algorithm implementations were already in the codebase or are standard textbook material. I just integrated them into the extension system.

Integrated Third-Party Libraries

• HNSW vector index (using an existing library) for approximate nearest-neighbor search.
• LLM embedding generation – calls external APIs (OpenAI, Google Gemini, Vertex AI, Amazon Bedrock, Voyage AI, Ollama) and stores results as float arrays.
• Connectors to DuckDB, Iceberg, Delta Lake, and PostgreSQL – thin layers over existing libraries, not deep integrations.

Things I Absolutely Did Not Write

• The core graph engine, columnar storage, OpenCypher query processor, transaction manager, compression subsystem, or extension loading framework.

I’m the guy who dusted off a dormant project, added some glue, and gave it a new name. I’m okay with that.

3. How I Use AI to Move Faster (Transparency)

I use AI assistants extensively. I’m not a C++ expert, and the codebase is large – hundreds of thousands of lines.

Here’s what AI does for me:

1. Scaffolding – When I need to register a new GDS algorithm or add an extension, there’s a mountain of boilerplate (CMake files, function registration, bind/exec patterns). I generate the skeleton with AI and fill in the logic myself.

2. Repetitive code – Serializers, copy constructors, test stubs, configuration structs. Mind-numbing but necessary. AI handles it well.

3. Refactoring suggestions – When I don’t understand a messy part of the codebase, I ask the AI to explain it and suggest improvements. Sometimes it’s right, sometimes it’s hallucinating – but it always accelerates my learning.

4. Documentation and examples – Writing example Cypher queries and usage docs is quick with AI, and I iterate on them.

Critical rule: I never blindly commit AI-generated code. Every line is reviewed, tested, and understood before it lands. The AI is my junior pair programmer – it does the grunt work, and I handle the architecture, correctness, and “does this actually make sense?” decisions.

This approach has been transformative. What would have taken weeks of reading header files, I can now do in days. And paradoxically, I’ve learned more about the codebase because I have to verify every suggestion the AI makes.

4. The Vision – Why Healthcare Needs a “Computable Medical Record”

At some point, I started thinking bigger. Healthcare data is fundamentally a graph.

• Patients have Encounters.
• Encounters have Diagnoses, Medications, and Observations.
• Providers form referral networks.

And yet, most healthcare pipelines export data from relational databases, reconstruct the graph in memory using Python, run their analysis, and throw it away. Furthermore, modern Clinical Trials and Big Pharma have strict compliance rules: data cannot leave the local network, and AI cannot be trusted to make deterministic clinical decisions.

The Architectural Shift

My vision for Gorgonzola is not to build a monolithic database, but to build the engine for a “Computable Medical Record.”

What if the graph database was the deterministic execution engine?

Instead of pushing raw patient data to Cloud LLMs (a privacy nightmare), the architecture should look like this:

1. The Transactional Layer: A robust standard like HAPI FHIR (Java) handles standard REST ingestion.

2. The Edge AI Layer: Small, local, quantized LLMs (like BioMistral) read unstructured clinical notes and extract entities without the data ever leaving the server.

3. The Analytical Core (Gorgonzola): The extracted data is written into the graph via strict Model Context Protocol (MCP) tools. Gorgonzola then acts as the deterministic engine—running clinical guidelines, evaluating temporal patient states, and identifying trial cohorts natively using OpenCypher and GDS algorithms.

Compute-to-data beats data-to-compute. Gorgonzola is my attempt to build that local, high-performance compute layer.

5. What Works Today (Honestly)

Works (to some extent)

Capability Status OpenCypher queries with graph traversals ✅ Solid – inherited from Kùzu Graph Algorithms (PageRank, Leiden, WCC, etc.) ✅ Standard textbook implementations, integrated Vector search via HNSW index ✅ Using an existing library Edge AI Integration ✅ Setup for local LLM embeddings (bypassing external Cloud APIs for privacy) Connectors to DuckDB, Iceberg, PostgreSQL ✅ Thin wrappers, functional Full-text search with stemming ✅ Built-in FTS extension

Doesn’t Work (Yet) / Architectural Gaps

Gap Status Native HAPI FHIR Gateway Integration ❌ Working on a Java-to-C++ bridge to separate OLTP ingestion from OLAP graph analysis. Medical terminology Subsumption Engine ❌ Have crosswalk CSVs, but need native SNOMED/LOINC graph traversal. Bi-temporal clinical state evaluation ❌ Crucial for tracking disease progression over time; currently just ideas on paper. Model Context Protocol (MCP) Server ❌ Working on exposing Gorgonzola strictly via MCP tools to prevent LLM hallucinations.

This is a proof of concept and a learning project – not a replacement for Neo4j. But for local, secure clinical analytics, it has teeth.

6. The Roadmap (Reality Check)

Here’s the aspirational roadmap. I want to stress: this is a wishlist, not a commitment. I am moving away from the “God Database” idea and focusing on embedding Gorgonzola into a secure, event-driven enterprise architecture.

Phase Focus What it unlocks 1 (current) Graph analytics + HNSW vector search + Local Embeddings Basic clinical graph analytics without data egress. 2 MCP Bridge & HAPI FHIR Integration Connecting a Java FHIR gateway to Gorgonzola for structured, standard-compliant ingestion. 3 Deterministic Rule Engine (CQL) Executing Clinical Quality Language (CQL) directly against the graph for cohort discovery and trial matching. 4 Terminology Subsumption (SNOMED/LOINC) Native graph traversals for complex medical hierarchies (e.g., automatically matching a specific drug to its parent class). 5 Bi-Temporal Graph Queries True clinical AI: patient trajectory modeling, survival analysis, and tracking state changes over time.

7. What I’d Love Help With

If you’ve read this far and any of the following sounds interesting – let’s talk.

• System Architects & Java Devs: I need help bridging the transactional world of HAPI FHIR with the analytical world of an embedded C++ graph database.

• Clinical Informatics / Trial Managers: Help me understand your strictest cohort selection rules so I can model them natively in Cypher.

• Edge AI & MCP Hackers: Let’s figure out the most robust way to use Model Context Protocol to write structured data from local BioMistral into the graph.

• Graph algorithm researchers: Especially anyone who has implemented temporal graph algorithms or bi-temporal logic in C++.

8. Get Involved

• GitHub: github.com/gorgonzola-graph-db/gorgonzola
• Email: [email protected]

If this resonates – star the repo, open an issue, or just drop me a message. I reply to everyone.