GitHub - Hikari-Systems/slater: Low-memory graphdb with Bolt+tls support, at-rest encryption & vectors designed for local replica graph use cases.

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 Reads and writes What you get Features How it works The writable layer Storage backends Mounts ACL Health check Worked example Development Performance License 📖 Full manual 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. Reads and writes Slater is a read-write graph database. You don't rebuild the whole image to correct one property, add a node, or retract an edge — you write the change directly, over Bolt, and it lands durably. The trick is that writes never tax the read path. 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: Reads over an unwritten graph cost exactly what they did before. An empty delta is a single predictable branch, not a merge — the read path is byte-identical whether or not the writable layer is on. The read cost of a write scales with the size of the delta, not the size of the graph. Whole-graph answers — 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. Acknowledged means durable. A single writer drains the queue and returns 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. Business-key writes, in either dialect. 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.

The writable layer is opt-in (delta.enabled); with it off, 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. What you get RAM set by your cache budget, not your graph size — fan out as many read replicas as you like; the graph never has to fit in memory. A drop-in for the graph — speaks Bolt, so any standard neo4j driver (JS, Python, Go…) works unchanged. It's Cypher (plus a slice of ISO GQL, reads and writes); nothing new to learn. Live, durable writes — an opt-in LSM layer over the immutable core: business-key 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. Deployment by file swap — build a new content-hashed generation offline, atomically flip the current pointer, and servers pick it up. Every block is checksummed, so a half-copied image is refused rather than served. Vector search built in — disk-native approximate-nearest-neighbour (cosine, L2, or dot KNN) sits right next to your graph, for when this is the retrieval layer behind a RAG pipeline, and embeddings are writable in place — no offline rebuild to add or change a vector. Locked down by design — read and write grants are independent, plus optional at-rest encryption, TLS Bolt, argon2id-hashed ACLs, and a read-only container rootfs for read replicas. Features Feature What it means for you Bounded, predictable memory Resident memory is capped by three cache budgets you set — it does not grow with graph size; you tune the performance/RAM trade-off instead of provisioning for the whole graph. A jemalloc allocator with background purge returns freed memory to the OS after heavy query bursts, so resident size falls back toward its idle floor rather than staying pinned at the post-burst high-water mark. Multi-tenant out of the box One server hosts many graphs with per-user read grants — multi-database isolation that most graph DBs reserve for a paid/enterprise tier.

Encryption at rest & in transit Per-block XChaCha20-Poly1305 sealing (the key is never written to disk) plus optional TLS (bolt+s://). GDPR-friendly by construction. Tiny, dependency-light install A small stripped binary on a distroless glibc base (no shell/apt) — the multi-arch (amd64/arm64) image pulls at ~22 MB, or ~12 MB for the server-only slater:latest-lite tag; pure-Rust TLS, no OpenSSL. Pull and run. Built for periodic publish Build a graph offline, serve it immutable, then atomically swap in a new version with zero downtime — ideal for data-warehouse / scheduled-refresh workloads. Rugged under load The server and offline builder both compile with #![forbid(unsafe_code)] — the engine's only unsafe lives in the audited jemalloc allocator crate. The core is immutable, so reads take no locks and never wait on a writer; a single writer serialises mutations behind the write path alone. No GC pauses, no data races. One bad query can't take the server down. Works with your neo4j tools Speaks Bolt 5.4 / 4.4 / 4.1 — use the standard neo4j drivers (JS, Python, Go, Java…), cypher-shell, or graph browsers unchanged. Rich Cypher query surface A broad read surface: MATCH/WHERE/WITH/UNION, CALL {…} subqueries, 70+ functions & aggregations, temporal & geospatial values, and regex. Live, durable writes An opt-in single-writer LSM layer over the immutable core (delta.enabled): business-key MERGE / SET / DELETE / CREATE / REMOVE over nodes and relationships, batched write-UNWIND (one fsync per batch), and CALL slater.consolidate() — group-committed, fsync-durable, and folded back into a fresh core by consolidation. The read path is byte-identical when the delta is empty.

ISO GQL, read and write Speaks a subset of ISO GQL (ISO/IEC 39075) over the same Bolt connection — quantified paths, path restrictors, shortest-path selectors, label/type boolean expressions, FOR, CAST, an optional GQL/CYPHER dialect prefix — and, with the writable layer on, GQL's data-modifying statements (INSERT / SET / REMOVE / [DETACH] DELETE) lower onto the same durable write path. Cypher and GQL, reads and writes, in one engine. Vectors + graph in one engine Disk-native ANN vector search (Vamana + PQ; cosine / L2 / dot) for embeddings/RAG, plus graph algorithms (PageRank, BFS, betweenness, WCC…) — bounded memory even with millions of vectors. Embeddings are writable (a FreshDiskANN-style write ladder): insert / update / delete a vector, KNN-visible at once, folded into the base without a rebuild. Safe on network storage Every file is BLAKE3 content-hashed and verified on open; torn or half-copied images are refused, not served. Designed for NFS/remote volumes (no mmap surprises). Pluggable storage backends Serve the same generation format from a local filesystem, an S3 (S3-compatible) bucket, or a Google Cloud Storage bucket — publish once, fan out to stateless replicas — with an optional local-SSD cache tier in front of the object store. See Storage backends. Two binaries make up the workspace: Binary Role slater The online Bolt server (the container ENTRYPOINT): serves reads and, with delta.enabled, the single-writer durable write path. slater-build The offline compiler: turns a primitive-Cypher dump into an immutable, content-hashed generation directory. Slater splits bulk building from serving: slater-build does the heavy lifting offline — ingesting your data and compiling it into an immutable generation — so a cold graph is never assembled on the serving hot path. Within the server, the read surface answers a broad Cypher slice — pattern matching, WITH/UNION/CALL {…} subqueries, 70+ scalar & aggregate functions, temporal & geospatial values, graph algorithms (algo.*),