{"slug": "i-forked-an-archived-graph-database-and-started-dreaming-about-healthcare-ai", "title": "I forked an archived graph database and started dreaming about healthcare AI", "summary": "A developer forked the archived Kùzu graph database, adding vector search, LLM embeddings, and a full Graph Data Science suite to create Gorgonzola, aiming to make it the central engine for healthcare AI. The developer's contributions include C/C++ API extensions, integration of third-party libraries like FAISS and ONNX Runtime, and wrapping existing algorithms into extensions. The project envisions a graph database that can run analytics such as PageRank, LLM embeddings, and vector similarity search directly, without data export.", "body_md": "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.\n\nA month ago, I found [Kùzu](https://github.com/kuzudb/kuzu) – 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.\n\nThis 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.\n\nLet 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.\n\nHere's what *I* actually contributed to Gorgonzola (my fork):\n\n**C/C++ API Extensions** (the actual code I wrote):\n\n`uint128_t`\n\nsupport`int128_t`\n\nand `uuid`\n\n, with arithmetic, comparison, and cast operators.`gorgonzola_value_get_blob_with_size`\n\n`get_blob`\n\ntruncated binary data at the first `\\0`\n\n. This API returns the full buffer and its byte length. A small fix, but critical for binary data.`00123`\n\nis now valid). Standardized vector function signatures across the board.**Wrapped existing algorithms into extensions**:\n\n**Integrated third-party libraries**:\n\n**Things I absolutely did not write**:\n\nI'm the guy who dusted off a dormant project, added some glue, and gave it a new name. I'm okay with that.\n\nI use AI assistants extensively. I'm not a C++ expert, and the codebase is large – hundreds of thousands of lines.\n\nHere's what AI does for me:\n\n**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.\n\n**Repetitive code** – Serializers, copy constructors, test stubs, configuration structs. Mind-numbing but necessary. AI handles it well.\n\n**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.\n\n**Documentation and examples** – Writing example Cypher queries and usage docs is quick with AI, and I iterate on them.\n\n**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.\n\nThis 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.\n\nAt some point, I started thinking bigger. Healthcare data is fundamentally a graph:\n\nEvery 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.\n\n**What if the graph database was the analytics engine?**\n\nWhat 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?\n\nGorgonzola 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.\n\nStill, 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.\n\n**Works (to some extent):**\n\n| Capability | Status |\n|---|---|\n| OpenCypher queries with graph traversals | ✅ Solid – inherited from Kùzu |\n| PageRank, Betweenness, Leiden, Louvain, WCC, SCC | ✅ Standard implementations, integrated |\n| Shortest paths (single, all, weighted) | ✅ Multiple variants available |\n| K-Core decomposition, Spanning Forest | ✅ Built-in |\n| Vector search via HNSW index | ✅ Using an existing library |\n| Cosine similarity, distance, inner product | ✅ Built-in array math functions |\n| LLM embedding generation (OpenAI, Gemini, Ollama, etc.) | ✅ Calls external APIs, returns float arrays |\n| Querying DuckDB tables from Cypher | ✅ Thin wrapper, functional |\n| CSV/Parquet import/export | ✅ Standard bulk loading |\n| Full-text search with stemming | ✅ FTS extension |\n| Connectors to PostgreSQL, Iceberg, Delta Lake, S3 | ✅ Thin wrappers, functional |\n\n**Doesn't work (yet):**\n\n| Gap | Status |\n|---|---|\n| Native FHIR/HL7 parsing | ❌ Experimenting – no C++ ecosystem exists |\n| Medical terminology (ICD, SNOMED, LOINC, RxNorm) | ❌ Have crosswalk CSVs, no built-in ontology engine |\n| Similarity metrics (Jaccard, Adamic-Adar, SimRank) | ❌ Not implemented |\n| Graph embeddings (Node2Vec, DeepWalk) | ❌ Algorithmically understood, needs random walk infrastructure |\n| GNN training/inference inside the database | ❌ Far off – requires embedded ML runtime |\n| Temporal graph queries | ❌ Just ideas on paper |\n| Survival analysis | ❌ Not started |\n| RDF/SPARQL support | ❌ Not started – huge scope |\n| Subgraph isomorphism (VF2) | ❌ Not started |\n\nThis is a proof of concept and a learning project – not a replacement for Neo4j or TigerGraph.\n\nHere's the aspirational roadmap. I want to stress: this is a **wishlist**, not a commitment.\n\n| Phase | Focus | What it unlocks |\n|---|---|---|\n1 (current) |\nGraph analytics + vector search + LLM embeddings | Basic clinical graph analytics, hybrid structured/unstructured queries |\n2 |\nSimilarity metrics (Jaccard, Adamic-Adar, Personalized PageRank), Node2Vec, DeepWalk, VF2 | Link prediction, biomedical pathway matching |\n3 |\nNative FHIR parser, terminology bundles (SNOMED, LOINC, RxNorm), RDF/SPARQL bridge | Zero-ETL healthcare ingestion, knowledge graph interoperability |\n4 |\nIn-database GNN inference (GraphSAGE, GAT, GIN), link prediction, node classification | Risk scores computed inside the graph, no data export |\n5 |\nTemporal graph queries, survival analysis, causal inference, explainability (GNNExplainer) | Clinical AI: patient trajectory modeling, interpretable predictions |\n\nThe 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.\n\nThat combination doesn't exist in any current graph database.\n\nIf you've read this far and any of the following sounds interesting – let's talk.\n\nIf this resonates – star the repo, open an issue, or just drop me a message. I reply to everyone.", "url": "https://wpnews.pro/news/i-forked-an-archived-graph-database-and-started-dreaming-about-healthcare-ai", "canonical_source": "https://dev.to/lechibang1512/i-forked-a-dead-graph-database-and-started-dreaming-about-healthcare-ai-29gf", "published_at": "2026-07-16 13:22:52+00:00", "updated_at": "2026-07-16 13:41:05.844914+00:00", "lang": "en", "topics": ["artificial-intelligence", "machine-learning", "large-language-models", "ai-infrastructure", "developer-tools"], "entities": ["Kùzu", "Gorgonzola", "FAISS", "ONNX Runtime", "OpenCypher"], "alternates": {"html": "https://wpnews.pro/news/i-forked-an-archived-graph-database-and-started-dreaming-about-healthcare-ai", "markdown": "https://wpnews.pro/news/i-forked-an-archived-graph-database-and-started-dreaming-about-healthcare-ai.md", "text": "https://wpnews.pro/news/i-forked-an-archived-graph-database-and-started-dreaming-about-healthcare-ai.txt", "jsonld": "https://wpnews.pro/news/i-forked-an-archived-graph-database-and-started-dreaming-about-healthcare-ai.jsonld"}}