There is a moment in every semantic-search project where you ask: do I really need to run a vector database? For a growing number of solo builders in 2026, the answer is no — you need a table. sqlite-vec puts vector search inside the SQLite file your app already uses, and the whole thing is one loadable extension with no separate service to deploy, scale, or pay for.

The news this month is that sqlite-vec is finally growing the one feature it has always lacked — an approximate index — and it's arriving in alpha. That makes now the right time to be clear about what to ship today and what to wait for.

What sqlite-vec actually is#

It's a SQLite extension in pure C, zero dependencies, written by Alex Garcia and sponsored by Mozilla Builders. You load it, create a vec0 virtual table, and store float, int8, or binary embeddings right alongside your relational data. It runs everywhere SQLite runs — including the browser via WebAssembly, which means on-device search with no backend at all.

Install is one line in whatever you already use:

pip install sqlite-vec      # Python
npm install sqlite-vec      # Node
# also: gem, cargo, go get

And the query surface is just SQL:

.load ./vec0
create virtual table vec_examples using vec0(
  sample_embedding float[8]
);

insert into vec_examples(rowid, sample_embedding)
  values (1, '[-0.200, 0.250, 0.341, -0.211, 0.645, 0.935, -0.316, -0.924]');

select rowid, distance from vec_examples
where sample_embedding match '[0.890, 0.544, 0.825, 0.961, 0.358, 0.0196, 0.521, 0.175]'
order by distance limit 2;

That's the entire deployment story. No container, no port, no client library talking to a service — the vectors live in the same file as your users table.

The thing everyone calls a weakness is usually a feature#

For its whole life, sqlite-vec has done exact brute-force search: every query compares your search vector against every stored vector. Purists hear "brute force" and reach for an ANN database. That instinct is often wrong at solo-builder scale.

Brute force gives you perfect recall — it never misses the true nearest neighbor — with no index to build, tune, or keep warm. And it stays fast well into the hundreds of thousands of vectors, which is more than most embedded RAG apps, agent-memory stores, and product catalogs will ever hold. An approximate index trades a little accuracy for speed you don't need yet, plus tuning knobs (lists, ef, recall targets) you now own forever. Below the sweet spot, exact search is not the primitive option — it's the low-maintenance one. We made the general version of this case in brute force vs approximate vector search; sqlite-vec is the clearest place it applies.

The 2026 change: ANN is landing, but it's alpha#

Here's the fresh part. As of v0.1.10-alpha.1, sqlite-vec started adding approximate indexes — a rescore index, an experimental ivf index (currently disabled), and a DiskANN index. The most recent pre-release, v0.1.10-alpha.4 (May 18, 2026), is still fixing DiskANN bugs.

Read that literally. This is an alpha feature on a project that is still pre-v1 and openly warns of breaking changes to its SQL API and storage formats until 1.0. It's real, it's coming, and it will eventually push sqlite-vec's ceiling up — but it is not something to build a launch on this quarter. The stable release you should ship on is 0.1.9 (March 31, 2026), MIT/Apache-2.0 licensed, brute-force and dependable.

The graduation line#

So use sqlite-vec for what it's genuinely best at, and know the exact point where you outgrow it:

The trap is jumping the line early — paying for a clustered vector service to hold 40,000 embeddings because brute force felt unserious. It isn't. Ship the single file, keep your embeddings reproducible so you can rebuild the table on any version bump, and let your actual vector count — not your anxiety — tell you when it's time to move.