This product was not featured by Product Hunt yet. It will not be visible on their landing page and won't be ranked (cannot win product of the day regardless of upvotes).
Product upvotes vs the next 3
Waiting for data. Loading
Product comments vs the next 3
Waiting for data. Loading
Product upvote speed vs the next 3
Waiting for data. Loading
Product upvotes and comments
Waiting for data. Loading
Product vs the next 3
Loading
Slater
Low-RAM fast graph DB designed for local replica graphs.
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. Perfect for GraphRAGs and LLM memory
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:
“Low-RAM fast graph DB designed for local replica graphs.”
Slater was submitted on Product Hunt and earned 14 upvotes and 7 comments, placing #159 on the daily leaderboard. 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. Perfect for GraphRAGs and LLM memory
On the analytics side, Slater competes within Developer Tools, GitHub and Tech — topics that collectively have 1.2M followers on Product Hunt. The dashboard above tracks how Slater performed against the three products that launched closest to it on the same day.
Who hunted Slater?
Slater was hunted by Rick Knowles. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
For a complete overview of Slater including community comment highlights and product details, visit the product overview.
Rick Knowles
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