Vector database
A store built to answer 'what is closest in meaning to this?' It indexes embeddings so nearest-neighbor search stays fast at millions of rows.
See it
What it is
A vector database stores embeddings with their text and metadata and answers one question very fast: given this query vector, which stored vectors are nearest? Brute-force comparison is fine up to a few tens of thousands of rows. Past that you want an approximate index like HNSW or IVFFlat, which trades a sliver of recall for orders of magnitude more speed.
The real decision is dedicated versus bolted on. pgvector inside the Postgres you already run keeps vectors, rows and permissions in one transaction and one backup, and is the right default for most apps. Pinecone, Qdrant, Weaviate and friends earn their keep at large scale, with heavy metadata filtering, or when you want the ops handed off.
Gotcha: it is a search index, not a source of truth. Keep canonical documents elsewhere so you can rebuild the index from scratch when you change the embedding model or the chunking, which you will. Second gotcha: filtering matters as much as similarity. Without a tenant or permission filter applied at query time, semantic search will cheerfully hand back another customer's documents.
Ask AI for it
Add semantic search to my Postgres app with pgvector. Create a chunks table with document_id, tenant_id, heading path, content and an embedding column sized to my embedding model, plus an HNSW index on cosine distance. Write an upsert path that deletes and reinserts all chunks for a document when it changes, and a search function that filters by tenant_id before ranking, returns the top 10 by cosine distance with their source document, and reads the embedding dimension from one shared config constant.