You're one person shipping a feature that needs semantic search — a docs assistant, a support bot, retrieval over your own notes. The reflex is to reach for a hosted vector database. Don't, not yet. For a solo build, the right tool is almost always an embedded vector store that runs inside your own process: no server to deploy, no bill, no ops. There are three that matter, and picking between them is refreshingly simple.

The short answer, up front: if you want nothing new installed and your corpus is small, use sqlite-vec. If you want the nicest API with metadata filtering and you fit in RAM, use Chroma. If you'll outgrow RAM or need versioned data for evals, use LanceDB. The deciding number is how many vectors you'll actually have — not which name sounds most serious.

Why "embedded" is the right default for one person#

A hosted vector database earns its keep when you have multiple tenants, billions of vectors, or a team on call. A solo builder has none of those problems yet. What you have is a laptop and a deadline. All three tools here run in-process — the database is a library you import, not a service you operate — so the cost is a copied file and a dependency, not a Kubernetes cluster. You can always graduate later. Starting on infrastructure you don't need is the expensive mistake.

sqlite-vec — the zero-dependency floor#

sqlite-vec is a SQLite extension. That's the whole pitch, and it's a strong one: your vectors live in the same .db file as the rest of your app data, and you query them with SQL. No new process, no new service, nothing to deploy. It runs anywhere SQLite runs — which is everywhere, including a phone or a serverless function.

It does brute-force KNN: it compares your query against every stored vector. That sounds slow until you do the arithmetic. Under tens of thousands of chunks, a linear scan is a few milliseconds, and you get exact results with zero index tuning. You filter with a normal SQL WHERE, join against your other tables, and back everything up by copying one file.

Use it when: the corpus is personal-scale (roughly ≤50k vectors), you want no new dependencies, and "it's just SQLite" is a feature. This is the correct default for most solo RAG.

Chroma — the ergonomics pick#

Chroma is the one that feels the nicest to write against. Its Python and JavaScript APIs are clean, collections and metadata filtering are first-class, and you're doing similarity search in about four lines. Under the hood it keeps an in-memory index backed by persistent storage, so queries are fast — as long as the data fits in RAM.

The ceiling is that RAM. Chroma is excellent up to roughly a million vectors on a machine with enough memory; past that, memory pressure builds and performance degrades. For a solo builder that ceiling is often far away, which is exactly why Chroma is a great middle option: you get real metadata filtering and collections without operating anything.

Use it when: you want the smoothest API and proper metadata filters, and your dataset fits comfortably in memory.

LanceDB — the scale-and-versioning pick#

LanceDB is written in Rust on the Lance columnar format, and it's built to do the one thing the other two can't: index datasets larger than RAM, reading from disk with IVF-PQ. It still runs embedded — no server — but it scales to billions of vectors bounded by your disk, not your memory.

Two extras matter for builders who are getting serious. First, hybrid search (vector + full-text) out of the box, which fixes the classic RAG failure where pure semantic search misses an exact keyword. Second, data versioning — the Lance format gives you time-travel over your data, which is quietly essential when you're running RAG evals and need a reproducible snapshot to grade against.

Use it when: you expect to exceed RAM, want hybrid retrieval, or need versioned data for evaluation.

The decision, in one axis#

Everything reduces to corpus size and appetite:

And because all three are embedded, the choice is low-stakes. Start with sqlite-vec, ship, and migrate only when a real limit — not a hunch — forces it. If you are about to exceed a single machine, that's the moment the cheap object-storage tier becomes relevant, and we compared those in S3 Vectors vs Turbopuffer vs LanceDB. For the local case, though, the winner is usually the boring one: the file you already have.