VeltrixDB vs. Redis

An honest comparison. Redis is excellent software with a massive ecosystem — VeltrixDB solves a different set of problems. Use this page to decide which one fits your workload.

The fundamental difference

Redis stores everything in RAM. It is fast by default, expensive at scale, and subject to GC pause spikes under write pressure.

VeltrixDB stores values on NVMe SSDs behind a DRAM index and an LIRS cache. It targets predictable P99 latency under sustained load, roughly 25× storage density versus an all-RAM layout, and a garbage collector that cannot be permanently paused.

Latency at a glance

The key difference is the shape of P99 over time. Redis P99 is low until it isn’t. VeltrixDB P99 does not drift — the three-tier GC and RT-priority NVMe queue enforce a ceiling.

Storage cost at scale

RAM costs roughly 15–20× more per GB than NVMe SSD in cloud pricing. At 1 billion keys with 128-byte values:

• Redis: ~$3,000–5,000/month for the memory (r6g.16xlarge-class territory)
• VeltrixDB: ~$300–500/month for NVMe (n2-highmem-64 local SSD, 3 nodes)

Write amplification

Write amplification maps directly to SSD wear and write latency. At 1.0×, every byte lands on NVMe exactly once.

When Redis wins

Use Redis when:

• Your full dataset fits comfortably in RAM — at, say, 5M keys and 256 bytes each, Redis’s DRAM-only path beats any disk-backed system at P50.
• You need pub/sub, streams, sorted sets, or Lua scripting — Redis has a rich data-structure model; VeltrixDB is a key-value store.
• Your team already runs Redis — operational familiarity has real value.
• You need a managed hosted service today — Redis Cloud, ElastiCache, and Upstash all exist. VeltrixDB’s managed offering is not yet available.

When VeltrixDB wins

Use VeltrixDB when:

• Your dataset doesn’t fit in RAM — or fitting it in RAM costs more than you want to pay. VeltrixDB’s LIRS cache keeps hot keys in DRAM; cold keys spill to NVMe automatically.
• You need predictable P99 under sustained write pressure — if production dashboards show Redis P99 spikes during AOF rewrite or keyspace expiry, VeltrixDB’s three-tier GC is built for exactly this problem.
• You’re doing bulk writes at high concurrency — MultiPut with 1024-entry batches reaches ~446K batch ops/s per node, while Redis pipelining is bounded by single-threaded command processing.
• You’re running on Kubernetes with local NVMe — VeltrixDB ships a first-class Kubernetes Operator, Helm chart, and GKE local-SSD auto-detection.
• Write amplification matters — if you’re running on cloud SSDs and watching disk wear, 1.0× versus 10–30× is the difference between replacing SSDs yearly versus every few months.

Migrating from Redis

VeltrixDB uses a simple text protocol compatible with nc:

# Redis
redis-cli SET mykey myvalue
redis-cli GET mykey

# VeltrixDB (same semantics)
echo -e "PUT mykey myvalue\nGET mykey" | nc localhost 9000

For SDK migration, swap the client:

# Before (redis-py)
import redis
r = redis.Redis(host='localhost', port=6379)
r.set('key', 'value')
val = r.get('key')

# After (veltrixdb-python)
import veltrixdb
r = veltrixdb.Client(host='localhost', port=9000)
r.put('key', 'value')
val = r.get('key')

The API surface is intentionally close. PUT/GET/DEL map directly to SET/GET/DEL. MultiPut/MultiGet map to Redis pipelines. SETNX, INCR, DECR, and CAS are all supported.

Feature matrix

Benchmark reference

All VeltrixDB numbers below are from a 3-node GKE cluster (n2-highmem-64, 8×375 GB NVMe per node, raw block device VLog, Linux 6.6, --read-heavy preset).

3-node cluster · 80R/20W · 1 billion keys (internal run — unverified;
see the YCSB numbers for measured, reproducible results)

Reads/s:         7,200,000
Writes/s:        1,800,000
P50 (blended):   ~220 ns
P99 (blended):   ~510 µs
GC emergency:    0 events in 30 min
Errors:          0

Full benchmark methodology: Benchmarking Methodology.

Questions?

Open an issue on GitHub or start a discussion. If you’re evaluating VeltrixDB for a production workload and want to talk through your specific requirements, the team is happy to help you benchmark against your actual data shape. See the FAQ for common questions.