GoKawiilSlater
Current version: v0.24.1 — all releases.
In one line: Slater serves graphs that don't fit in memory — hundreds of millions of nodes and billions of edges in low hundreds of MB of RAM — over standard Bolt, so any neo4j driver just works, with disk-native vector search sitting next to the graph, and it takes live, durable writes without giving that up. Resident memory is set by a cache budget you choose, not by the size of the graph.
Shortcuts
Why Slater exists
A graph database stores data as things (nodes) and the relationships between them (edges), with the relationships as first-class citizens. That's what you want when your questions are about connections rather than rows — "who's within three hops of this account?", "what's the full dependency chain behind this build?", "which accounts share a device, an address, and a card?" — the queries that become a swamp of recursive joins in SQL but fall out naturally in a graph.
The most common complaint about graph databases is that they don't scale past what you can hold in RAM. Many of them (eg neo4j, Memgraph, FalkorDB, etc) keep the whole graph resident: a 40 GB graph wants 40 GB of memory — per instance. Want a replica per region, per tenant, or per pod? Multiply the bill. And past a certain size they simply won't load: eg the 90 million node / 1.5B-edge Wikidata graph needs ~64–128 GiB resident, so the in-memory engines can't open it at all.
Slater is the rebuttal. It serves that same 90M-node graph from a few hundred MB of RAM, because it pages the graph from an on-disk image on demand instead of holding it resident — so the graph size and the memory bill are decoupled.
Slater takes the opposite approach. You compile the graph once, offline, into a content-addressed on-disk image with slater-build ; then any number of Slater servers serve it over Bolt (so your existing neo4j drivers just work) while holding only a fixed cache budget in memory. A 4 GB graph and a 400 GB graph cost the same RAM to serve — you fan out cheap, stateless read replicas and let the store, not the heap, hold the graph.
That makes it a natural fit for knowledge graphs behind RAG, recommendation and identity graphs, dependency graphs — anything large and connected you want to query cheaply and often. Disk-native vector search lives right next to the graph, so the same engine is the retrieval layer for embeddings too.
... continue reading