VeltrixDB — Values on NVMe, index in DRAM

The problem

At large key counts, you're not paying for a database. You're paying for RAM.

Redis and other in-memory stores keep every value in DRAM — hot or cold. Cloud RAM costs far more per gigabyte than NVMe SSD, so the bigger your dataset grows, the more you pay simply to hold it in memory. That's a bill that scales with your data, not your revenue.

In-memory store (e.g. Redis)

≥ 1 TB

RAM · 1B keys × 1 KB values

Every value pinned in memory, hot or cold
P99 spikes when AOF rewrite runs
Cost grows linearly with dataset size

≈ 4–7× less RAM · 1 KB values

VeltrixDB on NVMe

142–232 GB

RAM for the index · the ~1.4 TB of values sit on NVMe

Values on NVMe, only the index in DRAM
Value-log GC runs off the read path
You pay for machines, not a per-op meter

Arithmetic from measured per-key costs, not a billion-key benchmark. VeltrixDB’s index takes ~142 B/key (native index, measured at 5M keys) plus ~90 B/key for the ordered index unless --disable-ordered-index, plus whatever cache you give it; a 1 KB value packs into ~1.37 KB of NVMe. An in-memory store holds every value in RAM plus its own per-key overhead. The saving grows with value size: at 128-byte values the index takes about as much RAM as the values do, so small-value workloads save little. Size your own node with the sizing rules.

The shift

One idea, executed properly.

Move the bytes to where they're cheap. Keep only what you need in memory. Never let cleanup touch the fast path.

01 · Storage

Values on NVMe

Written once to an append-only value log. There is no LSM compaction; GC only copies still-live values out of mostly-dead segments — so write amplification stays near 1× by design, not the 10–30× typical of LSM trees.

02 · Memory

Index in DRAM

Only the index lives in memory — ~142 B/key measured — off the Go heap on cgo builds. A read is a cache hit (~92 ns in-process) or one 4 KB-aligned, CRC-checked NVMe read on a miss.

03 · Latency

P99 that holds

Value-log GC runs off the fast path and backs off when read latency rises. In the YCSB run: 100M durable writes and 10M reads, zero failures, read P99 2.8 ms.

See the full read/write path →

Vector, full-text & hybrid search · since v1.11

Search the records in the same database.

One id names one record: PUT doc-42 {"lang":"en"}, VSET doc-42 ... and TSET doc-42 ... describe the same thing. Vectors and documents are written through the same WAL and value log as any key; the search indexes in RAM are derived from them.

01 · Vectors

HNSW, quantized if you want

One cosine HNSW graph per namespace. RAM holds float32, int8 or product-quantized codes, and the layer-0 graph can sit in a mapped file; the full vectors stay on NVMe and re-rank the candidates. At 768 dimensions that is 3.4 KB down to ~0.4 KB of heap per vector (measured, 10K vectors).

02 · Text + hybrid

BM25, fused by rank

TSEARCH scores with BM25 over a Unicode tokenizer (no stemming or phrase queries). HSEARCH fuses the vector and text rankings with weighted reciprocal-rank fusion, and every search can filter on the KV record with the same id.

03 · Clusters

Fan-out that fails closed

In raft and replicated mode a search runs on every live node and the results are merged, with BM25 scored on cluster-wide statistics. A peer that misses the timeout fails the request unless you allow partial answers; node-to-node traffic can be HMAC-signed or mTLS.

Measured on one macOS laptop (Apple silicon), 2026-09-30: GloVe-100, 100K real word vectors, in-process, one query at a time — recall@10 0.953 at p50 0.77 ms (float32, ef 256). Over the network, 20K vectors, int8, 8 clients on the same machine: 24.6K QPS at recall 0.894. Not a comparison: no same-hardware run against another vector database exists. The index lives in RAM, is rebuilt at every start, and has been tested to 100K real vectors.

How vector search works ↗ Use cases & limits

What it means for the business

Four outcomes your board will care about.

Latency

An SLA you can actually promise.

No LSM compaction to fight your reads, and value-log GC backs off when read latency rises. Measure your own tail with the same YCSB harness we publish.

2.8msread P99 · YCSB, 100M keys, all cached

Cost

A bill that stops chasing your data.

Your data sits on NVMe instead of RAM — capacity priced like SSD, on hardware you run, with no per-operation meter to model.

4–7×less RAM at 1 KB values · per-key arithmetic, grows with value size

Portability

No cloud holds you hostage.

One Helm chart runs identically on GKE, EKS, AKS, or bare metal. Change providers without rewriting your data layer or your contracts.

4 platformsGKE · EKS · AKS · Bare metal

Time to value

Days to production, not quarters.

One Helm install deploys the StatefulSet, NVMe StorageClass, PodDisruptionBudget, and Prometheus scraping — 70+ metric families and a PrometheusRule included. The chart and the operator live in their own repositories, next to the server’s.

1 commandhelm install

Measured, not projected

427K reads/s on one node. Here's the distribution.

YCSB 0.17 workload C: 10M reads over 100M keys, 200 threads, single AWS node with 4× NVMe. The whole dataset fit in the 400 GB cache, so these are cache hits — not NVMe misses. Pure-Go build from June 2026. Full run — hardware spec, YCSB config, raw output — on the performance page.

Read · avg

461µs

461 µs · cache hit

Read · P95

2.07ms

2,069 µs · cache hit

Read · P99

2.77ms

2,771 µs · cache hit

Full benchmark & methodology ↗ Compare against Redis

Values on NVMe.
Index in DRAM.
RAM bill optional.