Slater - Low-RAM fast graph DB designed for local replica graphs.

Hey Product Hunt,

I'm Rick Knowles, the maker of Slater, a graph database that serves graphs which don't fit in RAM. It speaks standard Bolt, so any neo4j driver (JS, Python, Go, Java) talks to it unchanged, and it takes live, durable writes as well as reads.

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.

What that gets you:

* Live writes that don't tax reads: An opt-in LSM layer over the immutable core handles business-key MERGE / SET / DELETE / CREATE over nodes and edges, group-committed and fsync-durable. With no pending writes the read path is byte-identical, so you pay nothing for write machinery you aren't using.
* Vectors sitting next to the graph: Disk-native approximate-nearest-neighbour search (Vamana plus product quantisation) with cosine, L2 and dot metrics, so you match whatever your embeddings were trained for. Embeddings are writable in place: insert, update or delete a vector and it's KNN-visible at once, no offline rebuild.
* Cypher and ISO GQL, reads and writes, plus graph algorithms (PageRank, BFS, betweenness, WCC) and 70-odd functions. Nothing new to learn if you already use neo4j tooling.

Where I'd reach for it:

* LLM memory. Agent memory is read-heavy but it does mutate. Slater lets you write new facts and embeddings live, keep retrieval cheap, and fan out a replica per worker without a memory-hungry cluster sitting behind them.
* GraphRAG. Your knowledge graph and its embeddings live in one engine, so the traversal and the vector lookup happen in the same place, close to inference, instead of bouncing between a graph store and a separate vector DB.
* Identity, recommendation and dependency graphs, anything large and connected you query often.

Now the cloud economics, which is the part I'm proudest of: A managed graph service bills you for RAM sized to your entire graph, so the smallest production instance on the usual suspects starts north of $100 a month before you've stored much at all (Neo4j Aura's tiers begin around $65 for a dev-size box and $130+ for production, then climb per gigabyte of graph from there). Slater serves that 1.5-billion-edge graph in a few hundred MB of RAM, which fits comfortably on a t4g.small at about $12 a month, or under $8 on a one-year reservation. The same generation format serves from a local filesystem, S3, or Google Cloud Storage, all compiled into the image and picked by config, so you publish a graph once to a bucket and fan out stateless, disk-less read replicas that all read the same object store, with an optional local-SSD cache tier in front to claw back the round-trips. You size each box to its cache budget rather than the dataset, add throughput by adding identical cheap instances, and stop paying for RAM headroom you touch once a day. The image itself is tiny (around 22 MB multi-arch, 12 MB for the server-only lite tag) on a distroless base, so cold starts and autoscaling stay boring.

It's Apache 2.0, written in Rust, forbids unsafe code outside the audited allocator, and runs as a read-only container. At rest disk encryption makes it GDPR safe, and multi-tenanted for free. If you're running graph replicas, a GraphRAG stack, or agent memory and wincing at the RAM bill, I'd love for you to try it:

https://github.com/Hikari-System...

Thanks

the way memory is treated as a budget you set rather than something the graph dictates is a really elegant call. love that it just talks bolt too

loaded a 600M node dataset on my laptop and it just worked without me tuning anything weird. the bolt compatibility meant my existing neo4j python scripts ran unchanged which honestly saved me a whole afternoon.

Drove a billion-edge graph through the Bolt driver with the cache set to 200MB and queries still came back fast. Native vector search next to the graph is a really nice touch for GraphRAG setups.

honestly the fact that you can pin memory to a budget instead of letting the graph dictate it is such a smart move, makes deploying huge GraphRAG setups way less scary.

Played around with the bolt endpoint and it just connected with the standard neo4j driver, no config fuss, which is honestly the dream. The fact that memory stays flat while the graph keeps growing is the part that got me.

Really cool to see graph scale without blowing up RAM. One thing that would help me adopt it faster is a simple Docker Compose setup with sample GraphRAG data already loaded, so I could benchmark against my current neo4j stack in under ten minutes instead of wiring up a dataset from scratch.