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

#ai #graphdatabase #machinelearning #opensource

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.

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 (the actual code I wrote):

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:

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.
Repetitive code – Serializers, copy constructors, test stubs, configuration structs. Mind-numbing but necessary. AI handles it well.
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.
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?

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

Patients have Encounters.
Encounters have Diagnoses, Medications, Observations, Procedures.
Providers and Organizations form referral networks.
Drug-disease interactions, comorbidity patterns, and disease pathways are all networks.

Every patient journey is a temporal graph. And yet, most healthcare analytics pipelines export data from relational databases to Python, reconstruct the graph in memory, run analysis, and throw it away.

What if the graph database was the analytics engine?

What if you could run PageRank on a provider referral network, generate LLM embeddings of clinical notes, search for similar patients by vector similarity, and traverse treatment pathways – all within the same database, without exporting?

Gorgonzola can already do bits of this today. But I'm fully aware that a single person cannot build a production-grade healthcare platform. The roadmap I've sketched (FHIR parsers, medical terminologies, GNN inference, temporal queries) is aspirational. It would take a team and years of sustained effort.

Still, the architecture feels compelling. Compute-to-data beats data-to-compute when you're dealing with millions of patients and billions of events. So I'm sharing this vision not as a finished product, but as a starting point.

5. What Works Today (Honestly)

Works (to some extent):

Capability	Status
OpenCypher queries with graph traversals	✅ Solid – inherited from Kùzu
PageRank, Betweenness, Leiden, Louvain, WCC, SCC	✅ Standard implementations, integrated
Shortest paths (single, all, weighted)	✅ Multiple variants available
K-Core decomposition, Spanning Forest	✅ Built-in
Vector search via HNSW index	✅ Using an existing library
Cosine similarity, distance, inner product	✅ Built-in array math functions
LLM embedding generation (OpenAI, Gemini, Ollama, etc.)	✅ Calls external APIs, returns float arrays
Querying DuckDB tables from Cypher	✅ Thin wrapper, functional
CSV/Parquet import/export	✅ Standard bulk loading
Full-text search with stemming	✅ FTS extension
Connectors to PostgreSQL, Iceberg, Delta Lake, S3	✅ Thin wrappers, functional

Doesn't work (yet):

Gap	Status
Native FHIR/HL7 parsing	❌ Experimenting – no C++ ecosystem exists
Medical terminology (ICD, SNOMED, LOINC, RxNorm)	❌ Have crosswalk CSVs, no built-in ontology engine
Similarity metrics (Jaccard, Adamic-Adar, SimRank)	❌ Not implemented
Graph embeddings (Node2Vec, DeepWalk)	❌ Algorithmically understood, needs random walk infrastructure
GNN training/inference inside the database	❌ Far off – requires embedded ML runtime
Temporal graph queries	❌ Just ideas on paper
Survival analysis	❌ Not started
RDF/SPARQL support	❌ Not started – huge scope
Subgraph isomorphism (VF2)	❌ Not started

This is a proof of concept and a learning project – not a replacement for Neo4j or TigerGraph.

6. The Roadmap (Reality Check)

Here's the aspirational roadmap. I want to stress: this is a wishlist, not a commitment.

Phase	Focus	What it unlocks
1 (current)	Graph analytics + vector search + LLM embeddings	Basic clinical graph analytics, hybrid structured/unstructured queries
2	Similarity metrics (Jaccard, Adamic-Adar, Personalized PageRank), Node2Vec, DeepWalk, VF2	Link prediction, biomedical pathway matching
3	Native FHIR parser, terminology bundles (SNOMED, LOINC, RxNorm), RDF/SPARQL bridge	Zero-ETL healthcare ingestion, knowledge graph interoperability
4	In-database GNN inference (GraphSAGE, GAT, GIN), link prediction, node classification	Risk scores computed inside the graph, no data export
5	Temporal graph queries, survival analysis, causal inference, explainability (GNNExplainer)	Clinical AI: patient trajectory modeling, interpretable predictions

The biggest differentiator for healthcare wouldn't be adding one more GNN. It would be making Gorgonzola a graph-native clinical analytics platform – one where you can ingest a FHIR bundle, map it to a patient graph, run community detection over comorbidities, generate embeddings of clinical notes, and predict readmission risk, all without leaving the database.

That combination doesn't exist in any current graph database.

7. What I'd Love Help With

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

Healthcare data engineers – I need help understanding real-world FHIR/OMOP ingestion requirements.
Graph algorithm researchers – especially anyone who has implemented Node2Vec or temporal graph algorithms in C++.
GNN practitioners – is in-database inference actually useful, or is exporting to PyG/DGL always going to be the better workflow?
FHIR parser builders – this seems like an open gap in the C++ ecosystem. Should I build one or bridge to Java?
Tinkerers – the extension system is well-designed. Adding a new algorithm is a ~200-line exercise.