Validiti RAM is an in-process memory layer that holds working sets in compressed form and runs token-presence queries against the compressed bytes directly. Same workload, fewer machines. Same RAM, more cache. Single-machine, in-process, no Redis cluster.
An in-process memory layer that holds more working data than would fit otherwise — and lets you query it without decoding it. Same physical RAM, more capacity, faster queries.
The same working set fits in a fraction of physical RAM — because each entry is held as compressed bytes instead of raw bytes.
Decoded data is still available on demand — any entry can be reconstructed byte-exact via a single in-process call.
Useful operations work without full decode — token-presence and phrase queries run against per-document position indexes built once at insert time. The compressed form is queryable, not just decodable.
71 MB working set (18,180 docs at ~4 KB each) on a developer workstation. Single-threaded run. All numbers reproducible from the included demo script.
| Metric | Naive (raw bytes in dict) | Validiti RAM | Ratio |
|---|---|---|---|
| Total bytes held | 71.01 MB | 26.12 MB | 2.72× smaller |
| GET latency (5,000 random ops) | 0.23 µs/op | 356 µs/op | (slower than dict, faster than disk/network) |
| Token-presence query (single token) | 5,216 ms · 5,826 hits | 2.7 ms · 5,826 hits | 1,942× faster · identical hits |
| Compound query (token A AND token B) | 5,263 ms · 1,973 hits | 2.9 ms · 1,973 hits | 1,838× faster · identical hits |
Both query methods return the identical hit set — verified by set equality. The query phase is a frozenset membership test against pre-built per-document indexes. Every additional query against the same cache is essentially free.
Anywhere your working set is too big for RAM and too valuable to page to disk. Anywhere you query the same compressed data over and over.
Search engines, analytics rollups, full-text indexes — the index is structurally repetitive and compresses well. Hold more index per node; fewer disk hits; faster query response.
Same eviction policies, same key/value access pattern, same in-process latency profile when keys are frequently re-queried. 2-3× more capacity per node before you need to shard.
The KV cache is a memory hog at LLM serve time. Validiti RAM-compressed KV cache reduces per-request memory footprint and allows higher concurrency on the same GPU/CPU host. Pair with Validiti Accelerate for full-stack savings.
Devices with constrained RAM (8–32 GB) can hold working sets that would normally need a server. Move expensive lookups out of the cloud and onto the edge node.
Particularly useful for systems where the cached data is text-heavy (legal, regulatory, structured records). Same buffer pool eviction, same query result cache — just bigger before you start spilling to disk.
"Find every doc that mentions term X" runs in milliseconds against millions of docs. The unencrypted text never appears in the process address space during the scan — that's a security property, not just a performance one.
At the asymptotic 2.72× ratio (regulatory-text corpus), here's how much working data the same machine holds. 80%-of-RAM utilization for both columns to keep the comparison fair.
| Machine RAM | Naive holds | Validiti RAM holds | Extra |
|---|---|---|---|
| 1 GB | 0.8 GB | 2.2 GB | +1.4 GB |
| 16 GB | 12.8 GB | 34.8 GB | +22.0 GB |
| 64 GB | 51.2 GB | 139.2 GB | +88.0 GB |
| 256 GB | 204.8 GB | 556.8 GB | +352.0 GB |
| 1 TB | 819.2 GB | 2.2 TB | +1.4 TB |
A 64 GB workstation holds 51 GB of working data naively; the same machine through Validiti RAM holds 139 GB — 2.7× more data accessible at memory speeds, with no disk fallback. Compression ratio is corpus-dependent: regulatory text 2.72×, templated logs 8–15×, diverse natural prose ~2×.
"I have more data than RAM" is solved today by sharding, paging to SSD, or standing up a Redis cluster. Each adds latency, complexity, and operational cost. Validiti RAM is a single-machine, in-process answer.
In-process. Single-machine. No new daemons. No external network calls. Drop-in for caches, indexes, or buffer pools that today are paging to disk or hitting Redis across the wire.
If your current answer to "this working set is too big" is add another Redis node or shard across machines or page to SSD, Validiti RAM is the in-process answer that runs on the box you already have. A 64 GB workstation holds 139 GB of working data. A 16 GB laptop holds 35 GB. The cluster shrinks; the latency drops; the ops surface goes away.
See where this fits →Foundation tier free for non-commercial. Per-machine licensing above.
Single-machine deployment. Curated public foundation libraries (Wikipedia, Gutenberg, StackExchange). Generous non-commercial usage threshold. Upgrade to Commercial when your traffic crosses it.
Single-server commercial license. Production foundation libraries. Custom curated libraries available. Email support.
Volume pricing for fleets. Fleet management. Dedicated support. Custom integration. Co-publishing of vertical libraries.
Already running Validiti Accelerate, DMS, Maths, Titus, Provenance, or Pacta42? Validiti RAM is bundled with any Validiti product purchase — the in-RAM deployment shape is included with the substrate that ships with every Validiti SKU.
A substrate-based memory layer isn't a universal answer. The places it wins are real; the places it doesn't are real too.
We are not shipping a download yet. The reference demo is built and reproducible; the productized SKU is in finalization. When the .deb opens, you'll install in five minutes and your working set will gain capacity overnight.
Tell us your workload (cache shape, working-set size, current Redis/SSD spend). We'll size your savings before launch and reserve a slot.
Reserve your launch slotEvery tier — including Foundation — ships the same protection envelope.
