Not drop-in. VeltrixDB does not speak the Redis protocol (RESP); it has its own text and binary protocols and client SDKs for Go, Python, Node.js, Java, Rust, and C++. The command set is deliberately familiar — PUT/SET, GET, DEL, HSET/HGET, INCR, CAS, MPUT/MGET, plus ordered scans with RANGE and SCANCUR and vector / text search (VSEARCH, TSEARCH, HSEARCH) — so for point-lookup workloads the change is a client swap, not a redesign. RESP compatibility is on the roadmap with no date. If you need joins, SQL, or a full search engine (facets, phrase queries, stemming), VeltrixDB is the wrong tool — we'll tell you that in the demo.

The reproducible number: 427,697 reads/s, P99 2.8 ms (avg 461 µs) on YCSB workload C — 100M keys, 200 threads, one AWS node with 4× NVMe. The whole dataset fit in the 400 GB cache, so those were cache hits; we have not published a reproducible run where most reads miss to NVMe, or one at a billion keys. How it works: a sharded, scan-resistant LIRS cache serves hot keys (~92 ns in-process); a miss is one 4 KB-aligned Go pread from the value log, CRC32C-checked; and with no LSM compaction, value-log GC runs off the read path and backs off when read latency rises. Full conditions are on the performance page.

For vectors that belong next to your KV records, yes — since v1.11. Each namespace has one HNSW graph (cosine) with float32, int8 or product-quantized codes in RAM and an optional on-disk layer-0 graph (v1.12); the full vectors stay on NVMe and re-rank the candidates. Searches filter on the record with the same id and fan out across cluster nodes. Measured on one macOS laptop with GloVe-100 (100K real vectors, one query at a time): recall@10 0.953 at p50 0.77 ms (float32, ef 256); over the network with 20K vectors, int8 and 8 same-host clients, 24.6K QPS at recall 0.894. The honest limits: the index lives in RAM (~0.4–3.4 KB per 768-dim vector by layout) and is rebuilt at every start, with searches refused until it finishes; tested to 100K real vectors, nothing at 10M+; one graph per namespace, cosine only, no GPU; on v1.13 and earlier DEL removes the record but not its vector — use VDEL (and TDEL for text); Fixed in v1.14: DEL also deletes the record’s vectors and text; the search API is in the bundled Go client, other languages use the text protocol. There is no same-hardware comparison with Milvus, Qdrant or any other vector database. Details: vector search docs.

Yes, within limits. TSET indexes a document for Okapi BM25 (Unicode tokenizer, no stemming, stop words or phrase queries, at most 1 MiB per document), and HSEARCH fuses a vector and a text ranking with weighted reciprocal-rank fusion. In a cluster, BM25 is scored with cluster-wide statistics. There are no facets, aggregations or per-field weights, so if search is the product, Elasticsearch or OpenSearch is the better tool.

VeltrixDB is free and self-hosted, so the bill is your hardware — RAM, NVMe, and network — not a per-operation meter. RAM covers the index (~142 B/key measured at 5M keys with the native index, plus ~90 B/key for the ordered index unless disabled), whatever cache you choose and, if you use search, the vector and text indexes; NVMe holds the values. The saving over an all-in-RAM store grows with value size — roughly 4–7× less RAM at 1 KB values, little at 128 B values. See how to size a node, and we'll model your workload during the demo. We don't quote savings percentages we haven't measured.

A write is acknowledged only after it is fdatasync'd: the value to the value log and its record to a group-commit WAL, which shares one write(2) and one fdatasync across all writers in a batch. Since v1.12 group commit is adaptive: a lone writer is synced at once and the 15 ms window is only an upper bound (--group-commit=fixed restores the full wait). WAL records are binary with a CRC32C over the whole record (binary is the default since v1.6; v1.5 and earlier wrote text records). A crash replays the WAL; a clean shutdown writes a compacted checkpoint. Across nodes: --mode=raft for quorum-committed (linearizable) writes — reads are local by default, and --linearizable-reads sends GET and MGET through the ReadIndex fence; on v1.13 and earlier namespace, hash and range reads stay local (Fixed in v1.14: every read goes through it) — or --mode=replicated with eventual, quorum, or strong consistency, which is not linearizable under concurrent writers; --rack-id keeps replicas in different zones. Cross-region, repl-ship forwards the change stream. There is no SLA — it's software you run.

In the software: AES-256-GCM encryption of values at rest, TLS 1.3 for clients, TLS / mTLS between nodes, HMAC-SHA256 signing of node-to-node transfer and search traffic (--cluster-secret-file), RBAC, and an append-only audit log. /admin/* answers loopback only unless you set --admin-token. Known gaps: encryption key rotation is not implemented (one key per data directory, from an env var or key file), keys themselves are not encrypted, and point-in-time-recovery archives hold decrypted values, so protect the archive location. Because you run it in your own environment, compliance is scoped to your deployment — VeltrixDB itself holds no SOC 2 or ISO 27001 certification.

It depends on how much of your code talks to the store. The usual shape: one helm install, bulk-load with veltrix-migrate (JSONL import/export) or batched MPUT, shadow-read traffic for a few days to validate, then flip the connection. The migration guide walks through dual writes, cutover, and rollback.

Add nodes. Gossip does not add members on its own: every node has to know the new one, which on v1.16 and earlier means restarting each node with it in --peers (New on main after v1.16 — ships in the next release: nodes are added and removed online with veltrix cluster add-node / remove-node or --join); on v1.14 and earlier keys then migrate to their new owners in the background (--auto-rebalance, on by default), and a node failure also triggers that migration, which can delete keys, so run clusters with --auto-rebalance=false. Fixed in v1.15: raft mode never migrates keys (every node applies the whole log), and replicated mode copies a key to its new replicas and deletes it from a node only after every replica acknowledged it. The Kubernetes operator — a separate repository — automates resharding when the replica count changes. Distributed searches ask every node, so their cost grows with the cluster. There are no plans or capacity tiers to upgrade — the open-source engine has no limits beyond your hardware.

Yes — VeltrixDB is fully open source under Apache 2.0. The server lives on GitHub, with the client SDKs, the Helm chart and the Kubernetes operator in their own repositories: clone them, run them, fork them, send PRs. No license keys, no trial limits, no feature-gated tiers — the whole engine is free to use in production. There is no managed cloud service today; VeltrixDB is self-hosted only. A managed service is planned, with no date announced.