A type-safe, realtime collaborative Graph Database in a CRDT

I'm personally of the opinion that "graph databases" should be relational databases; the relational model can subsume "graph" queries, but for all the reasons Codd laid out back in the 60s... network (aka connected graph) databases cannot do the latter.

Let the query planner figure out the connectivity story, not a hardcoded data model.

  % 1. Base case: Directly connected systems (1 hop) with   bandwidth > 10
  fast_path(StartSys, EndSys, 1) :- 
      link(StartSys, EndSys, Bandwidth), 
      Bandwidth > 10.

  % 2. Recursive case: N-hop connections via an intermediate system
  fast_path(StartSys, EndSys, Hops) :- 
      fast_path(StartSys, IntermediateSys, PrevHops), 
      link(IntermediateSys, EndSys, Bandwidth), 
      Bandwidth > 10,
      Hops = PrevHops + 1.

  % 3. The Query: Find all systems connected to 'System_A' within 5 hops
  ?- fast_path('System_A', TargetSystem, Hops), Hops <= 5.

  // 1. Base case: Directly connected systems (1 hop)
  def fast_path(start_sys, end_sys, hops) =
    exists(bw: link(start_sys, end_sys, bw) and bw > 10 and hops = 1)

  // 2. Recursive case: Traverse to the next system
  def fast_path(start_sys, end_sys, hops) =
    exists(mid_sys, prev_hops, bw:
      fast_path(start_sys, mid_sys, prev_hops) and
      link(mid_sys, end_sys, bw) and bw > 10 and hops = prev_hops + 1)

  // 3. The Query: Select targets connected to "System_A" within 5 hops
  def output(target_sys, hops) =
    fast_path("System_A", target_sys, hops) and hops <= 5

https://www.dataversity.net/articles/say-hello-to-graph-norm...

...

That said, modern SQL can do this just fine, just... much harder to read.

  WITH RECURSIVE fast_path AS (
    -- 1. Base case: Directly connected systems from our starting node
    SELECT
      start_sys,
      end_sys,
      1 AS hops
    FROM link
    WHERE start_sys = 'System_A' AND bandwidth > 10
    UNION ALL

    -- 2. Recursive case: Traverse to the next system
    SELECT 
      fp.start_sys, 
      l.end_sys, 
      fp.hops + 1
    FROM fast_path fp
    JOIN link l ON fp.end_sys = l.start_sys
    WHERE l.bandwidth > 10 AND fp.hops < 5
  )

  -- 3. The Query: Select the generated graph paths
  SELECT * FROM fast_path;

How large is large, here? Tens of thousands of triples? Hundreds? Millions?

I'm working on a local-first browser extension for ActivityPub, and currently I am parsing the JSON-LD and storing the triples in specialized tables on pglite to be able to make fast queries on that data.

It would be amazing to ditch the whole thing and just deal with triples based on the expanded JSON-LD, but I wonder how the performance would be. While using the browser extension for a week, the store accumulated ~90k thousand JSON-lD documents, which would probably mean 5 times as many triples. Storage wise is okay (~300MB), but I think that a graph database would only be useful to manage "hot data", not a whole archive of user activity.

The query syntax looks nice by the way.

A: One of the main lessons of the RAG era of LLMs was reranked multiretrieval is a great balance of test time, test compute, and quality at the expense of maintaining a few costly index types. Graph ended up a nice little lift when put alongside text, vector, and relational indexing by solving some n-hop use cases.

I'm unsure if the juice is worth the squeeze, but it does make some sense as infra. Making and using these flows isn't that conceptually complicated and most pieces have good, simple OSS around them.

B: There is another universe of richer KG extraction with even heavier indexing work. I'm less clear on the ROI here in typical benchmarks relative to case A. Imagine going full RDF, vs the simpler property graph queries & ontologies here, and investing in heavy entity resolution etc preprocessing during writes. I don't know how well these improve scores vs regular multiretrieval above, and how easy it is to do at any reasonable scale.

In practice, a lot of KG work lives out of the DB and agent, and in a much fancier kg pipeline. So there is a missing layer with less clear proof and a value burden.

--

Seperately, we have been thinking about these internally. We have been building gfql , oss gpu cypher queries on dataframes etc without needing a DB -- reuse existing storage tiers by moving into embedded compute tier -- and powering our own LLM usage has been a primary internal use case for us. Our experiences have led us to prioritizing case A as a next step for what the graph engine needs to support inside, and viewing case B as something that should live outside of it in a separate library . This post does make me wonder if case B should move closer into the engine to help streamline things for typical users, akin how solr/lucene/etc helped make elastic into something useful early on for search.