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.
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.
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.
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.
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.
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.
This is one of the cases where I think people really want a personal touch. Your README is the "hook" of a project, it's the first thing we see, and so you want to advertise "this thing was made with thought and care". Also the README does not need to be exhaustive, it should be a form of advertising and you can nest the lower level documentation in a /docs and link the sections from the README.
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.
I don't think it is completely about the language. JVM taking more memory isn't the problem with in-memory databases. It is having more data than can fit in memory. Even an in-memory SQL Db would eventually run out of memory, no matter the language it was coded in.
A lot of DB design is around this subject. And so it seems like if you found a way to allow a graph DB data to expand beyond in-memory by allowing it to reside on disk is a really big deal. But, since it would be a big deal, I'd think the big guys with a lot of resources would offer it as an option, or feature. It would be worth investing in.
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.
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.
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
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.
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.
Neat! Thank you for the in-depth!
So you're also using succinct datastructures with Elias-Fano, you might want to check out this paper https://aidanhogan.com/docs/ring-graph-wco.pdf on WCO joins over succinct indexes.
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.
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.
This is one of the cases where I think people really want a personal touch. Your README is the "hook" of a project, it's the first thing we see, and so you want to advertise "this thing was made with thought and care". Also the README does not need to be exhaustive, it should be a form of advertising and you can nest the lower level documentation in a /docs and link the sections from the README.
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?
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.
I don't think it is completely about the language. JVM taking more memory isn't the problem with in-memory databases. It is having more data than can fit in memory. Even an in-memory SQL Db would eventually run out of memory, no matter the language it was coded in.
A lot of DB design is around this subject. And so it seems like if you found a way to allow a graph DB data to expand beyond in-memory by allowing it to reside on disk is a really big deal. But, since it would be a big deal, I'd think the big guys with a lot of resources would offer it as an option, or feature. It would be worth investing in.
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.
How does "standard Bolt" relate to OpenCypher? Does Bolt support imply OpenCypher support?
Bolt is the wire protocol, and Slater supports Cypher and ISO GQL as syntax over Bolt.
[flagged]