FAISS

The index, not the database

Faiss is a similarity-search library from Meta. It builds and queries vector indexes, and that is the whole scope.

It has no server, no query language, no metadata filtering, no persistence layer you did not write, and no notion of a collection. Compare LanceDB, which is embedded and still gives you tables and multimodal columns, or Chroma, which gives you a client and a store. Faiss sits a layer below all of them, and several vector databases use it or something like it internally.

That makes it the right tool in two situations and the wrong one in most others.

When a library beats a database

You already have the storage. Your documents and metadata live in Postgres or on disk, and the only missing piece is nearest-neighbour lookup over an array of vectors. Faiss does that and adds no infrastructure.

You need control over the index. Batch jobs, research, offline evaluation, or a system where you want to choose the structure and its parameters rather than accept a managed default. Indexing embeddings covers those parameters, and Faiss is where they are most directly exposed.

Outside those, you are likely to rebuild a database badly. Filtering, updates, durability and concurrent access are all yours, and each is harder than it looks.

Index strings are the interface

Faiss configures an index with a factory string, which reads as a pipeline rather than a name: "Flat", HNSW32, "OPQ16_64,IVF65536_HNSW32,PQ16x4fsr".

The decision path in Faiss's own guidance is short. Exact results or few searches: "Flat", or "IDMap,Flat" if you need your own IDs attached. Memory not constrained: HNSW_M. Memory somewhat limited: an IVF index with nprobe tuned. Memory quite important: the OPQ/PQ combination. Maximum compression: RaBitQ.

Cluster counts scale with the dataset. Under a million vectors, 4√N to 16√N clusters; 65,536 at 1M to 10M; 262,144 at 10M to 100M; 1,048,576 above that.

Three things that catch people

Training. IVF and quantized indexes learn from data before they can store anything, in the region of 30,000 to 256,000 vectors. The vectors you train on should look like the vectors you will store, or the clustering is wrong in a way that only shows up on real queries.

Dimension constraints. With PQ, the dimension must be a multiple of M, and Faiss prefers D = 4M. An embedding model whose dimension does not divide neatly limits your options, which is a reason to know this before choosing the model.

GPU coverage is partial. Flat, IVF and the OPQ/PQ variants have GPU support. HNSW does not; it is CPU-only. So the index with the best recall-to-latency ratio is also the one you cannot accelerate, and a GPU budget may push you toward IVF instead.

What you have to build around it

Four things, before this is a system:

Persistence. Write the index to disk and reload it. Faiss will serialize; deciding when, and what happens to writes since the last save, is yours.

The ID mapping. An index returns positions or IDs, not documents. Keeping the mapping from vector to record correct across rebuilds is the bug that bites hardest, because a stale mapping returns confident nonsense rather than an error.

Updates and deletes. Some index types handle removal poorly, and the usual answer is periodic rebuilds. Plan the rebuild before you need it.

Filtering. If a query needs "only this customer's documents", Faiss is the wrong layer. Context security explains why post-filtering results is a tenant-leak shape, and a library with no filter support means you are the one who has to get that right.

Where to reach instead

For an application that needs filtering, durability and updates, a database is the answer: Weaviate for hybrid search, Supabase Vector to stay in Postgres, Chroma to start embedded.

Reach for Faiss when you want the index and nothing else, and when you are willing to own the four things above.

Further reading

• Faiss, Guidelines to choose an index: the decision path, index strings and GPU coverage.
• Indexing embeddings: the parameters, and what they trade.
• LanceDB: the nearest neighbour that is still a database.
• Purpose and functionality: what a vector database adds beyond the index.