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.
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
supportint128_t
and uuid
, with arithmetic, comparison, and cast operators.gorgonzola_value_get_blob_with_size
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.00123
is now valid). Standardized vector function signatures across the board.Wrapped existing algorithms into extensions:
Integrated third-party libraries: Things I absolutely did not write:
I'm the guy who dusted off a dormant project, added some glue, and gave it a new name. I'm okay with that.
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.
At some point, I started thinking bigger. Healthcare data is fundamentally a graph:
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.
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 |
| 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.
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.
If you've read this far and any of the following sounds interesting – let's talk.
If this resonates – star the repo, open an issue, or just drop me a message. I reply to everyone.