VelesDB is an embedded data engine that puts vector search, a typed property graph, and a typed columnar store behind one query language, VelesQL. It runs in-process on a server, laptop, browser, mobile device, or edge machine rather than as a remote cluster, so a retrieval or semantic-search query stays on the machine that issues it. The native binary is around 14 MB and the WASM build around 710 KB gzipped.
A single statement crosses all three engines: a MATCH clause walks typed relationships, a similarity() predicate ranks by vector distance, and typed columns filter on exact metadata, without glue code between separate systems. Vector search uses HNSW with AVX-512, AVX2, and NEON SIMD acceleration, five distance metrics, and PQ, RaBitQ, SQ8, and binary quantization. Three search modes trade recall against latency: fast (ef_search 64, recall@10 92.2%), balanced (128, 98.8%), and accurate (512, 100%).
On top of the engine sits an agent memory service. You store a fact with remember, link facts with typed edges, and ask why(), which starts from the best match and walks those links so the answer comes back with the facts that explain it, including ones that share no vocabulary with the question. Memories persist by default, forget(id) deletes one, and ttl_seconds gives a fact an expiry. The default embedder is an offline lexical hash, and embedder="ollama" switches recall to meaning-based matching. The same interface is available in Python, Node, an MCP server, and the TypeScript SDK.
A separate context compiler shrinks accumulated agent context to a token budget with no model call and no network access. Each fragment is kept, abstracted, or dropped with a recorded rule id, reason, and risk level that explain_compilation reports; over-budget content becomes a ctx://source/ handle that retrieve_context_source fetches back verbatim. The same input compiles to the same bytes, which also yields a stable prefix for prompt caching. Code, URLs, numbers, and negative constraints survive verbatim, and only content the agent hands the compiler is compressed.
Published measurements, each tied to a committed harness:
| Measurement | Figure | Conditions |
|---|---|---|
| Input-token savings | 82.5% | 12-turn agent-session corpus, cl100k tokens |
| Billed dollars saved | 21.9% | 19-turn session at Retina screenshot weight; 10.9% cropped, 14.7% over 36 turns |
| Vector search latency | 450 µs p50 | 10K vectors at 384 dimensions, recall ≥ 96% |
| Retrieval quality | +7.2 and +9.7 points | multi-hop on HotpotQA, time-scoped on TimeQA |
Core-edition limits include a single writer per collection, since the write-ahead log serializes on one fsync lock; no replication, sharding, or automatic failover; an enforcement hook for access control but no policy engine; and MATCH limited to two hops in the WASM build.
Features
- Three engines, one query: vector similarity, typed graph traversal, and columnar filtering in a single VelesQL statement
- Single embedded binary: roughly 14 MB native, with WASM, mobile, and Tauri builds and no hosted control plane
- Explainable recall: why() walks typed links from the best match and returns the evidence subgraph with hop depth
- Deterministic context compiler: byte-stable compression with a rule id, reason, and risk level per fragment and reversible source handles
- MCP memory server: velesdb-memory runs as a local stdio server, or as a shared HTTPS daemon for several clients
- Agent hooks: session-start, stop, pre-compact, pre-tool-use, and post-tool-use hooks put the memory in the loop
- HTTP surface: 54 REST endpoints for collections, points, search, graph, indexes, VelesQL, and administration
- Language bindings: a Rust core with Python, Node, TypeScript, WASM, and mobile surfaces
- Enterprise control plane: role-based access control, an audit trail, multi-tenancy, and clustering on the same binary
