Choosing a Vector DB

Selection

Part of: Vector Databases & Production Search

Two teams build the same RAG feature. One drops their embeddings into a pgvector column next to data they already have in Postgres and ships in a day. The other reaches for a managed service, wires up a new SDK, a new bill, and a new on-call rotation. Neither is wrong. The mistake is picking before you know your constraints. Choosing a vector database is an engineering trade-off, not a leaderboard. What it is A vector store is anything that can hold embeddings and answer nearest-neighbor queries. They fall into three rough families. A library like FAISS is raw, in-process index code: blazing fast, free, but you own persistence, scaling, and filtering yourself. An extension like pgvector bolts vector search onto a database you already run, so similarity lives next to your relational rows. A managed service like Pinecone runs the whole index for you behind an API: you pay money to not think about sharding, replication, or uptime. How it works There is no universal winner, so you score candidates against your requirements and pick the cheapest one that clears every bar: The decisive axes are usually: scale (thousands vs billions of vectors), operational burden (do you want to run it?)

Challenge: Vector DB Selector