NVMe-nativeKey-valueVector & hybrid searchKubernetes-firstApache 2.0
VeltrixDB Documentation
VeltrixDB is an NVMe-native distributed key-value database with built-in vector, full-text and hybrid search. Values live on NVMe in an append-only log with ~1× write amplification by design (WiscKey KV-separation); the index and hot values stay in DRAM. This is the complete reference for building, deploying, and operating it.
| Benchmark | Result |
|---|---|
| Reads/s (measured — YCSB 0.17, single node, 4×NVMe) | 427,697 |
| Durable writes/s (fsync every write) | 18,064 |
| Read latency (avg, 200 threads) | 461 µs |
| Write amplification | ~1.0× |
| Storage density, 1B × 128 B values | ~160 GB |
Full benchmark methodology and hardware spec →
On main after v1.16 — ships in the next release
Writes after an online backup survive a crash Fixed on main after v1.16 — ships in the next release
On v1.0–v1.16 every write made after an online backup or /admin/checkpoint is lost on a crash (standalone and replicated) until the next clean restart. On those releases, restart the node cleanly after each backup.
Streaming raft snapshots Fixed on main after v1.16 — ships in the next release
No 256 MB cap, chunked InstallSnapshot, restore equals the snapshot (deleted keys no longer survive on followers), TTLs kept, Apply not stalled during capture; exactly-once apply across restarts and deterministic SETIF versions.
Online membership New on main after v1.16 — ships in the next release
/admin/cluster/members and veltrix cluster add-node / remove-node, --join, raft learners and pre-vote, the replicated drain, --force-new-cluster for disaster recovery.
Metrics, alerts and tests New on main after v1.16 — ships in the next release
go_* / process_*, search, raft, snapshot and replication-recovery metrics, 24 alert rules, a Jepsen-style consistency harness and nightly rolling-upgrade tests.
What's new in v1.14 to v1.16
Mutex and block profiles v1.16
--pprof-mutex-fraction and --pprof-block-rate fill /debug/pprof/mutex and /debug/pprof/block; read counters striped across cache lines (+13% in-process reads on an 18-core Mac).
Incremental Raft persistence v1.15
Append-only raft_log.dat plus raft_meta.dat instead of rewriting the whole log; followers fsync outside the node lock and acknowledge only durable entries. Upgrade migrates automatically; a rollback needs a re-sync.
Auto-rebalance no longer deletes keys v1.15
Raft mode never migrates keys, node failure or recovery moves nothing, and replicated mode deletes a key from a node only after every replica acknowledged it. New opt-in --raft-pipeline flag.
3-node benchmark harness v1.15
bench/compare runs RF 3 clusters of each database (NODES=3) and gcp-multihost.sh drives a multi-host run. No multi-host result is published yet.
Correctness fixes v1.14
TTLs survive restarts, a data-dir lock, atomic ops encrypted like PUT, CDC and audit on every write path, the Raft read barrier on every read, DEL removes a record's vectors and documents, FAILED replicas recover, and CLI fixes.
What's new in v1.11 and v1.12
Vector, BM25 & hybrid search v1.11
Vector namespaces with metadata filters and VDEL, int8 quantization, BM25 full-text (TSET / TSEARCH) and hybrid HSEARCH fused by reciprocal rank — all stored as ordinary keys next to the record they describe.
Cluster-wide search v1.11
Searches, QUERY and IDXQUERY fan out to every non-failed node and merge; a peer that misses --search-timeout-ms fails the request. Node-to-node traffic can be HMAC-signed with --cluster-secret-file.
Product quantization & disk graph v1.12
QUANT pq and GRAPH disk: measured 378 B of heap per 768-dim vector vs 3,383 B for float32 (10K synthetic vectors, macOS). Recall and latency tables state their conditions.
Safe restarts for search v1.12
Searches are refused until the startup index rebuild finishes (INFO search_ready), instead of silently missing vectors; nightly soak and SIGKILL chaos tests check every acknowledged write.
What's new in 1.1.0
Lists, sets & HNSW vector search
Two new data types plus a built-in HNSW vector index (VSET / VSEARCH) — persisted, replicated, rebuilt on restart.
Linearizable reads & auto-rebalance
Raft-mode GET behind a ReadIndex fence (--linearizable-reads), and node join/leave now migrates keys automatically.
Durable cross-region catch-up
repl-ship checkpoints its cursor and replays exactly the writes it missed via /admin/changes — deletes included.
PBKDF2 password hashing
210k-iteration PBKDF2-HMAC-SHA256 with per-user salts; legacy hashes keep working with a deprecation warning.
Atomics in every SDK
CAS / INCR / DECR / SETNX now ship in Go, Python, Node.js and Java — matching Rust and C++.
Disk-failure auto-degrade
A per-disk breaker fails writes fast after repeated I/O errors and flips /readyz to degraded so orchestrators drain the node.
Rack-aware replica placement
--rack-id keeps every copy of a partition in a distinct zone; labels propagate via gossip, rackless clusters are unchanged.
Admin API access control
/admin/* is loopback-only by default; --admin-token adds bearer-token auth. Metrics and probes stay unauthenticated.
Start here
Introduction
What VeltrixDB is, how it compares to Redis and RocksDB-backed stores, and when to use it.
Quickstart
Run VeltrixDB with Docker and issue your first PUT/GET in under 2 minutes.
Installation
Binary, Docker, Helm, and Kubernetes Operator installs for every environment.
Explore the docs
Architecture
Sharding, write/read paths, admission control, cluster and consensus.
Core Concepts
Data model, vector & hybrid search, wire protocol, and deployment modes.
Client SDKs
Go, Python, Node.js, Java, Rust, and C++ — same binary protocol, connection pooling built in.
Operations
Security, backup & restore, replication, monitoring, performance tuning, disaster recovery.
Reference
Every server flag, the Admin HTTP API, and CLI tools.
Kubernetes
CRD Operator and Helm chart for running VeltrixDB in production clusters.
Why VeltrixDB
Redis keeps every value in RAM. VeltrixDB keeps values on NVMe and only the index in DRAM — about 142 B/key with the native index, plus ~90 B/key for the ordered index unless disabled. With 1 KB values that is roughly 4–7× less RAM; with 128-byte values the index is about as large as the values, so the saving grows with value size. LSM-based stores like RocksDB typically see 10–30× write amplification from compaction; VeltrixDB's WiscKey-style KV-separation keeps that close to 1.0×.
See the honest trade-offs in Limitations & Roadmap and a feature-by-feature breakdown in VeltrixDB vs. Redis.