For an internal code or document index, a vector extension on a database you already run is usually enough. Reach for a dedicated service only when your vector count, query rate or filtering needs outgrow it, and measure that rather than assume it.
Three ways to store vectors
- An extension on a database you already operate. pgvector adds vector similarity search to Postgres, so vectors sit next to your other data.
- A library inside your own process. Faiss is a library for similarity search and clustering of dense vectors, written in C++ with Python wrappers.
- A separate vector database service. Another system to run, secure, back up and pay for.
What pgvector gives you
Per its README, it supports single precision, half precision, binary and sparse vectors, and several distance functions including L2, inner product and cosine distance. The default is exact search, which it says provides perfect recall. Adding an index trades some recall for speed, and results can differ from exact search once an approximate index exists.
The big practical benefit is that metadata lives in the same row. Filtering by repository, language or team, and joining to a permissions table, is ordinary SQL. That matters for permission aware retrieval.
What Faiss gives you
Faiss compares vectors by L2 distance or dot product, and cosine works through normalised vectors. It is mostly CPU based, with optional GPU support. Its README says compressed representation methods can scale to billions of vectors in main memory on a single server, at the cost of less precise search. It is a library, not a database, so storage, updates, access control and metadata are your job.
When a dedicated service makes sense
- You need to filter and search across a very large collection under heavy concurrent load.
- Multiple teams need a shared, managed service with its own operations story.
- Your database team does not want vector workloads near the transactional database.
None of these is typical for one company's code and docs. Many internal indexes hold a modest number of chunks and a handful of queries a minute.
Questions to ask before adding infrastructure
- How many vectors will we have in a year? Estimate from lines of code and chunk size.
- What is our latency target, and have we measured exact search at that size?
- Do we need row level permissions? Where do they live?
- Who patches and monitors this new system?
- Can we rebuild the index from source in an hour? If yes, the vector store is disposable, and the choice is easier to change later.
The last question is the most useful one. If the store is a rebuildable cache of your source, a wrong early choice costs little.
Security applies to all three
A vector store holds a copy of your content in another form. See securing vector databases for the controls that apply whichever you pick.
Quick check
Is exact search too slow?
At small and medium sizes it often is not. Test it. Move to an approximate index only when measured latency requires it. See exact versus approximate search.
Can I switch stores later?
If you keep the source text and the embedding model name, yes. Re-embed and load into the new store.
Sources
Last reviewed: 19 October 2026.
