Qenlo, an embedded vector database in Rust

what it is

one canonical record store holds your ids, normalized vectors, metadata, and tombstones. the search indexes (cpu, wgpu, usearch, pytorch) are derived from it, so any of them can be rebuilt without changing which records exist. search is exact by default and filters by user and timestamp before ranking. results come back in a fixed order, distance then id.

storage is checksummed snapshots plus a write-ahead log. a failed write never half-updates the store, and reopening checks shape, dimension, checksum, and format version.

why i built it

vector indexes are disposable and application data is not. most vector databases ask you to run a service for what is, in many apps, a few hundred thousand rows owned by one process.

when to use it, and when not to

use it when one process owns the collection, exact results are useful, filters cut the candidate set down, and local persistence matters. think desktop semantic search, offline rag, per-user document collections, and local agent memory.

use something else for joins, multi-node replication, hosted ingestion, heavy concurrent writes, billion-scale approximate search, built-in encryption, or a production sla. it is not a distributed database and not a fastest-in-class engine. it is beta, and it has not been through production.

install

go, kotlin, and swift sdks are in preview. the license is apache-2.0.

# rust (Cargo.toml)
qenlo = "0.1.0-beta.2"

# python
pip install qenlo==0.1.0b2

# typescript
npm install @a3ro.dev/qenlo@beta

execution paths

in automatic mode it reports which path actually ran and why. required-gpu mode errors out instead of quietly falling back to cpu.

• cpu exact: the default. exhaustive search over the rows your filter lets through.
• wgpu exact: optional gpu acceleration. depends on your adapter and driver, and fixed costs can dominate small sets.
• usearch hnsw: optional approximate search. measure recall on your own data and filters.
• pytorch tensor: optional python snapshot. derived, not durable.

the research

the paper, The Efficient Kernel Runs Slow, asks when the gpu actually wins. the light gpu path's device time swung up to 4.6x across rtx 4090 hosts, and a cpu/gpu routing rule i fit failed its preregistered held-out test, so i reverted it. every number links back to its boundaries in the repo, and every retained evidence file is hashed and checked in ci.