Slater – Low-memory graphdb designed for read-heavy graphs

https://github.com/Hikari-Systems/slater

by rickkjp • 1 day ago

43 14 1 day ago

rickkjp5• 1 day ago

Hi all - I just wanted to announce a low memory footprint FOSS graph db I've been working on (named Slater, after the Archer character). The most common complaint about Graph/GraphRAG DBs is the cost and memory footprint they consume: many depend on holding the whole dataset fully in RAM, which makes them expensive to run.

Slater starts with the premise of a fixed memory budget applied to an LRU cache of what's on disk, then uses ISAM blocks and DiskANN/Vamana/PQ to allow paging the contents of the graphs and vectors you need into that cache. It's designed around read-heavy-write-light cases, and can be backed either by local disk or by S3/GCS buckets with an optional sized local disk L2 cache as well.

Speaks standard Bolt, and is GDPR friendly (encryption at-rest and in-transit). Multi-user-multi-graph with ACLs, Rust-with-forbid-unsafe and NFS-friendly too (no mmaps). It's Apache licensed.

Please give it a try if you get a chance. Would love any suggestions or feedback.

Full disclosure: yes, it was authored by Claude Code, although I provided the storage model and design it used, along with code samples and influences from other open source projects like FalkorDB and Memgraph for Bolt wire-compatibility.

Thanks

packetlost• 1 day ago

One recommendation: do not let the LLM write your README for you. It can write other docs (though IME they still suck at it), but your README needs to be focused and easily digestible by a human glancing at the project.

LLMs have no concept of focus when it comes to docs, so they spew out way more information than is necessary or helpful to a human reading the document.

rickkjp5• 1 day ago

Ha - ok understood, although in my specific case I think this is better than anything I would have written. I edited it pretty hard to get it to say what I wanted it to say, so not sure if that counts. Thanks anyway for the feedback.

UltraSane• 1 day ago

I've wanted to analyze all published scientific papers and authors and their citation relationships in Neo4j but hit resource limits so this is very interesting to me.

FrustratedMonky2• 1 day ago

Big weakness of Neo4j, etc...?

Since it is a much in demand feature. Why do you think they have not done it themselves already, versus what you have done?

Curious if this is breakthrough? Or there are some negatives that prevent Neo4J from doing it also?

rickkjp5• 19 hours ago

Not a weakness so much I guess, just a different cost/performance trade-off choice that I think largely was a direct result of having been written in java for enterprise purposes at a time when Rust didn't yet exist. "Low memory" and "written in Java" are at least in my experience not terribly compatible goals.

j-pb2• 1 day ago

Cool stuff!

I still always want to know the numbers per edge. Because there'a a reaon why these graph DBs try to hold the stuff in memory, everything else is slow as heck. We have ~30bytes per edge in our succinct indexes, which makes the 1.5gb wiki dataset clock in at ~50gb.

If I understand correctly you shard the graph and then content adress each chunk:

- How do you decide on the sharding? I'd expect finding good connected subsets with nice memory locality to be extremely difficult computationally?

- How do you canonicalise your graph. Which has also been an extremely difficult problem in RDF land for example. Although that one is at least efficiently solvable.

rickkjp5• 16 hours ago

Sorry, I didn't see this question when it came in (the comment was collapsed in the thread for some weird reason).

The wikidata image I was using (sourced from a huggingface dataset Arun Sharma kindly uploaded for LadybugDB) is about 10GB zipped I think, and when imported into Slater takes up about 20GB of disk space. It's about 133GB of raw Cypher.

So in bytes/edge, that's probably about 14.

In terms of how to shard (which I'm taking to mean allocation of nodes to ISAM blocks) during an initial build or during a consolidation step, it will try to pack neighbours into the same blocks along with metadata about neighbouring segments, with some additional heuristics to avoid superhubs causing over-filling issues. For on the fly writes it just uses a normal WAL that it builds tables out of until theres a segment merge, at which point it then uses the same logic as for the consolidation.

In terms of canonicalising, it asks for a pk property during import, and then uses a (label, key property, value) tuple for uniqueness. So in a sense it doesn't really do that itself, it relies on that being handled outside the import.

Hope that helps.

PS as a follow-up: one really important memory-saving trick I used was Elias-Fano encoding on the adjacency matrices. Each node keeps an array of nodes it's joined to, and Elias-Fano does an amazing job of compression on those, both on disk and in RAM.

pbronez• 1 day ago

How does "standard Bolt" relate to OpenCypher? Does Bolt support imply OpenCypher support?

rickkjp5• 1 day ago

Bolt is the wire protocol, and Slater supports Cypher and ISO GQL as syntax over Bolt.

valentynkit• 12 hours ago

The delta layer is the part I'd want more detail on: once you're doing frequent consolidations against a multi-GB immutable core, what does write ampflication look like? That's usually where "runs in low hundreds of MB" plans get expensive.

Slater – Low-memory graphdb designed for read-heavy graphs

Related Stories