hikari-systems/slaterLow-memory graphdb with Bolt+tls support, at-rest encryption & vectors designed for local replica graph use cases.
Current version: v0.25.2 — 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
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. Rather than loading the graph into memory, it compiles it once, offline: slater-build turns your data into a content-addressed, immutable on-disk image, and any number of Slater servers then serve that image over Bolt (so your existing neo4j drivers just work), paging blocks in on demand and holding only a fixed cache budget resident. That is how the same 90M-node graph serves from a few hundred MB of RAM — graph size and memory bill are decoupled. A 4 GB graph and a 400 GB graph cost the same RAM to serve, so 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.
Compiled once does not mean frozen, though. That image is a base, not a final state: an opt-in write layer sits above it, so a live graph can be corrected and extended without rebuilding anything.
The core is immutable; the graph is not. Turn the writable layer on (delta.enabled) and you write over Bolt — correct one property, add a node, retract an edge — and the change lands durably, with no rebuild of the image. What keeps it cheap on the read side is where the writes live.
Writes accumulate in a log-structured-merge (LSM) layer over the immutable core: a write-ahead log and an in-memory table, spilling to immutable delta segments, folded back into a fresh core by a periodic consolidation. What that buys you:
count(*), the label and relationship-type marginals — stay metadata reads even with writes outstanding: the delta keeps its own counters, so a count(*) over a 91.6M-node core with half a million pending writes still answers in tens of milliseconds without touching a single block.SUCCESS only after the fsync that covers the write. Group your writes and they're cheap — a write-UNWIND commits one fsync per batch rather than per row.MERGE / MATCH … SET / DELETE (and CREATE / REMOVE, detach delete, relationship writes) keyed on a node's identity property — or the equivalent ISO GQL data-modifying statements (INSERT / SET / REMOVE / DELETE), which lower onto the same path. Correct, insert, upsert and retract, over nodes and edges, addressed the way your data already is.With the layer off — the default — Slater serves the pure immutable core and refuses writes. See The writable layer for the full model.
On the name. Slater is named after the CIA agent in Archer (a great show) who insists on going by a single name — "Just… Slater" — and one of my favourite characters in it. See the character wiki page.
MERGE / SET / DELETE over nodes and edges, group-committed and fsync-durable, folded back into a fresh core by consolidation. Reads don't pay for it.current pointer, and servers pick it up. Every block is checksummed, so a half-copied image is refused rather than served.