Limitations & Roadmap
These are real gaps in VeltrixDB today. We'd rather you know them upfront than discover them in production.
Honest limitations
Secondary-index metadata is node-local in replicated mode
IDXCREATE/IDXDROP (index metadata) apply only on the node that receives them in replicated mode; raft mode replicates them. Workaround: in replicated mode, issue index create/drop against every node, or use raft mode when secondary indexes matter cluster-wide.QUERY / RANGE / SCANCUR reads are node-local in cluster modes These read paths are always served from the receiving node's local data — they do not fan out across the cluster, so in
raft/replicated modes their results reflect only what that node holds. Workaround: direct these operations at a node known to hold the relevant data, or fan out and merge client-side.repl-ship: LWW conflict resolution only, and no back-pressure Cross-region shipping is durable across shipper restarts as of v1.1.0 (
/admin/changes + --checkpoint), but two gaps remain: conflict resolution is last-write-wins only (it relies on the remote cluster's own version-vector deduplication), and there is no back-pressure signal to the source — local writes keep succeeding even while the destination is degraded or unreachable. Workaround: monitor destination lag and deadletter growth; design cross-region write patterns so LWW is acceptable. See Replication & CDC.Raft is a single group All consensus traffic flows through one Raft group — a single log and a single leader — so
raft mode does not scale writes horizontally: adding nodes adds fault tolerance and read capacity, not consensus write throughput. Workaround: use replicated mode when you need horizontally scaling writes without linearizability, or shard across multiple independent clusters at the application layer.Replicated mode is not linearizable
replicated mode is primary-copy replication for durability across copies; it has no single-writer ordering, so concurrent writers to the same key are not linearizable. Workaround: use raft mode instead when you need write linearizability; reserve replicated mode for durability-across-copies use cases with a single writer per key or where eventual consistency is acceptable. On the roadmap: not listed as a planned change — this is a deliberate architectural trade-off between the two modes, not a temporary gap.No Redis protocol (RESP) You can't point a Redis client at VeltrixDB yet. Workaround: use VeltrixDB's own text protocol (
nc-compatible) or one of the six native SDKs — the command surface (PUT/GET/DEL, atomic ops) is intentionally close to Redis's, so porting client code is mostly a find-and-replace. On the roadmap: yes — RESP compatibility is listed under "What's coming" in the changelog. Once it ships, migration will require only a connection-string change, not a code change.No managed cloud offering VeltrixDB is self-hosted only today — there is no VeltrixDB Cloud or equivalent hosted SaaS. Workaround: deploy via the Helm chart or the Kubernetes Operator on your own cluster (GKE, EKS, AKS with local NVMe). On the roadmap: yes — a managed offering is explicitly listed as planned.
Shipped in v1.1.0
The following were listed as limitations before the v1.1.0 "distributed-completeness" release and are now implemented — they no longer belong on the list above:
- Rack/zone-aware replica placement — start each node with
--rack-id <zone>and partition placement never puts two copies of a partition in the same failure domain (unless the replication factor exceeds the number of distinct racks, in which case placement still spans every rack available). Rack labels propagate via gossip, and rackless clusters keep the exact previous placement. New in v1.1.0, so less battle-tested than the rest of the placement path. See Cluster & Consensus. - Admin API access control —
/admin/*now defaults to loopback-only, with an optional bearer token (--admin-token) for remote access. See Security. - HNSW vector index — replaces the brute-force scan; ~O(log N) queries at 0.99 recall@10 (M=16, efSearch=64), with deterministic per-id levels and tombstoned deletes.
- SDK atomics everywhere —
CAS/INCR/DECR/SETNXadded to the Go, Python, Node.js, and Java clients (previously Rust/C++ only). See the SDK docs. - Auto-rebalance — node join/leave/failure triggers ring rebalance and physical key migration; opt out with
--auto-rebalance=false. - Linearizable reads in raft mode — with
--linearizable-reads, GET runs the Raft ReadIndex fence: quorum-confirmed, never stale. - List and set data types —
LPUSH/RPUSH/LPOP/RPOP/LLEN/LRANGEandSADD/SREM/SISMEMBER/SMEMBERS/SCARD. - Distributed routing for all data types — namespace, hash-field, vector, secondary-index, and list/set ops now go through the coordinator in raft and replicated modes (the residual index-metadata and local-read gaps above are what's left).
- Durable cross-DC catch-up — the
/admin/changesfeed plusrepl-ship --checkpoint: a restarted shipper replays exactly the delta it missed before rejoining the live CDC stream. See Replication & CDC. - PBKDF2 password hashing — PBKDF2-HMAC-SHA256 (210,000 iterations, per-user random salt) with legacy-hash fallback and a load-time deprecation warning. See Security.
What's coming
From the project changelog's "What's coming" section (items that shipped in v1.1.0 are listed above instead):
- RESP protocol (Redis compatibility) — point Redis clients at VeltrixDB without code changes.
- Raft log snapshots — prevent slow restarts on large clusters with 100+ GB WALs.
- Native range/prefix scans — remove the
NSSCANworkaround for sorted-data use cases. - Managed cloud offering.
- Multi-region replication — automatic cross-datacenter failover.
Track progress Follow GitHub Releases for updates on these items as they ship.