memista

Overview

memista exists to test an unfashionable proposition: that a large share of the projects reaching for a dedicated vector database do not need one. The default architecture for retrieval now includes a separate vector service almost reflexively, and for corpora of a few tens of thousands of vectors that service is an extra deployment, an extra network hop, an extra failure mode and an extra thing to keep in sync with the application's own data.

The implementation pairs SQLite for metadata with USearch for the index, using HNSW with an inner-product metric over F32 vectors, and exposes a small Actix-web HTTP API — insert, search, drop — bound by default to localhost. The library form runs in-process, which is the configuration the argument is really about: no service, no network, no synchronisation between a row and its vector because they live in the same file.

Pairing SQLite with a specialised index rather than bolting vectors into SQLite is deliberate. The metadata half of a retrieval query is a relational problem that SQLite has solved for twenty years, and the vector half is an approximate-nearest-neighbour problem that a purpose-built HNSW implementation solves better than a generic extension. Keeping them separate means each side can be swapped without rewriting the other.

The project is explicitly experimental at v0.1.x. The API will change, and that is stated on the project rather than discovered during an upgrade. Anyone depending on it should pin a version and read the changelog, which is true of any pre-1.0 crate and worth repeating because retrieval components tend to get embedded deeply.

Where it loses, and it is worth being specific. Above roughly a million vectors, or under sustained high query concurrency, a dedicated system built for that regime — Pinecone, Qdrant, Milvus, Weaviate — will outperform an embedded index and offer operational features memista has no intention of implementing: sharding, replication, managed backups, multi-tenant isolation. memista is the answer to "do I need a vector database yet?", and for a growing corpus the honest answer eventually becomes yes.

In the portfolio it pairs with embedcache, which generates vectors locally; polymathy, the answer-engine harness, keeps its own USearch index rather than depending on memista.

A sizing heuristic, offered as a rule of thumb rather than a benchmark: if the corpus fits comfortably in the memory of the process that queries it and the query rate is measured in tens per second rather than thousands, an embedded index is likely to be simpler and faster end-to-end than a network call to a dedicated service. As either number grows by an order of magnitude the calculation reverses, and the right time to migrate is before the reversal rather than after the incident that reveals it.