Sextant

Navigate, don’t trawl.

Sextant is an SSD-resident vector search library for the batch regime: build an index once, search it many times, drop it when you’re done. The whole index lives in one file on NVMe — fast to search, cheap to keep, and happy on an ordinary machine.

One file

The index is a file. That’s the whole operations story.

A build lands as a single immutable artifact — copy it, rsync it, mount it read-only. Search handles open O_RDONLY, so a stray write is structurally impossible, not just forbidden. Nothing to babysit.

SSD-resident

Working sets bigger than RAM, at SSD speed

Sextant owns its storage stack: direct I/O plus a built-in W-TinyLFU cache. Query working sets that exceed RAM still serve at SSD speed — and idle RAM stays near zero. No page-cache tuning, no memory provisioned for data at rest.

Filtered search

Predicates are part of the search, not a post-filter

Typed filter columns — integers, floats, bools, strings, sets, geo — constrain the search itself. Rare-value predicates fall back to exact brute force; malformed predicates throw, never silently pass-all. Results are deterministic: identical inputs, identical results, any thread count.

Recall on demand

Hundreds of bytes per vector — you pick the point on the curve

Per-leaf quantizers compress vectors to a few hundred bytes; exact rerank against the originals claws recall back (measured invariant 1.0 on our e2e gates). A built-in sweep maps recall against QPS, so the operating point is your choice, not a default you hope holds.

Embedding

A C++ core, a stable C ABI — and SQL via DuckDB

Embed it as a C++ library or cross the exception-proof C boundary. Or skip the library entirely: the sextant-duckdb extension adds CREATE INDEX … USING sextant to DuckDB and serves natural top-k queries with filter pushdown from the index — validated for parity against the engine CLI on a 2.9M×768 corpus.

Quick start

Already speaking SQL? Then this is the whole integration — point DuckDB at a table with embeddings and index it:

> LOAD sextant;
> CREATE INDEX idx ON docs USING sextant (embedding)
    WITH (path = 'docs.tree', filter_cols = 'language,source,year');

> SELECT * FROM docs
    WHERE language = 'en'
    ORDER BY array_distance(embedding, query_vec)
    LIMIT 10;

That top-k becomes an index scan, and the predicate pushes down into the engine — rare-value filters fall back to exact search automatically. Tuning is session variables with measured defaults; the full reference lives in the extension docs.

v0.1-rc · public on GitHub the public surface is build → search → drop. source at rescbr/sextant-engine (C++ library + CLI) and rescbr/sextant-duckdb (DuckDB extension). validated end-to-end on x86-64 and aarch64, with full gates on a 2.9M×768 production-shaped corpus. mutations remain experimental — we don’t ship maybes.

Why the name

A sextant doesn’t find the star. It measures the angle to it — and from that measurement fixes your position. Here, the star is the vector you’re looking for, the navigator is your query, and the sextant is the routing plane: cheap measurements first, expensive chart-reading only where it matters.

You carry the instrument, not the ocean’s chart. The routing table lives in DRAM; the billion-vector corpus stays on disk.