VeltrixDB Docs
v1.1.0 GitHub FAQ Quickstart

Client SDK Overview

VeltrixDB ships official client libraries for six languages. Every SDK speaks the same auto-detected binary wire protocol, so behavior, performance characteristics, and error semantics are consistent no matter which one you pick.

Available SDKs

All clients connect over a single TCP port (9000 by default) and negotiate the binary protocol automatically — the server also accepts a human-readable text protocol on the same port for quick nc/telnet testing, but the SDKs never use it.

LanguageInstallMin version
Gogo get github.com/VeltrixDB/veltrixdb-client-goGo 1.19+
Pythonpip install veltrixdbPython 3.8+
Node.jsnpm install veltrixdb-clientNode.js 16+
Javacom.veltrixdb:veltrixdb-client:1.0.0 (Maven/Gradle)Java 11+ (17+ to build from source)
Rustcargo add veltrixdb-clientRust 2021 edition
C++header-only — copy cpp/include/veltrixdb.hppC++17, POSIX sockets

None of the SDKs pull in third-party runtime dependencies — Go, Python, Node.js, and Java use only their standard networking libraries; Rust is pure stdlib; C++ depends only on POSIX sockets.

One protocol, six languages

Every client dials a plain TCP (or TLS) socket and frames requests the same way: [1B cmd][2B keyLen][4B valLen][key][value], with a [1B status][4B payloadLen][payload] response. Connection pooling is either built into the client (Go, Java, Python, Node.js all ship a pool type) or trivially composable (Rust and C++ are single-connection today — wrap them in your own pool, e.g. r2d2 for Rust).

Atomics in every SDK As of v1.1.0, the atomic-op verbs CAS, INCR, DECR, and SETNX are implemented as typed methods in all six clients — Go, Python, Node.js, and Java gained them in v1.1.0; Rust and C++ had them from the start. See each language page's "Atomic operations" section for exact signatures, or the Binary Protocol Reference for the wire framing.

Use MPUT / MGET — they are dramatically faster

Every SDK exposes a batch write (MultiPut / multi_put / multiPut) and batch read (MultiGet / multi_get / multiGet) call. These send one request frame carrying N entries instead of N separate round trips, and the server fans the work out across its 8192 shards in parallel. Batches of 256–1024 entries are commonly up to 50× faster than issuing the same number of individual Put/Get calls — use them for bulk loads, cache warms, and any hot loop that touches more than a handful of keys.

Disk density bonus Server-side, batched writes pack multiple small records into each 4 KB VLog block. For 128 B values that's roughly a 25× disk-density gain over single-key Put calls, which each consume one full block. See the Performance Tuning guide for the block-packing details.

Browse by language

Cluster-aware client (Go, bundled with the server)

The SDKs above each talk to a single node. VeltrixDB's server repository also ships a separate, cluster-aware Go client (client.NewClient, package github.com/VeltrixDB/veltrixdb/client) for use against raft or replicated deployments. It fetches cluster topology, builds the same consistent-hash ring the server uses to route keys, and transparently follows MOVED redirects to the current Raft leader. This is a different package from veltrixdb-client-go covered on the Go page — reach for it specifically when you're running a multi-node cluster and want client-side routing. See Deployment Modes for when each mode applies.