Vector Database
A store optimised for approximate nearest-neighbour search over high-dimensional embeddings.
The core operation is finding the vectors closest to a query vector, which exact search does in linear time and approximate indexes — HNSW, IVF, product quantisation — do in something closer to logarithmic, trading a small amount of recall for a large amount of speed.
The architectural decision most teams overthink. A dedicated vector database is warranted at large scale or with demanding filtered-search requirements; below a few million vectors, the vector extension in the relational database you already run is usually the better choice, because it keeps embeddings transactionally consistent with the records they describe and removes a system from the estate.
Two requirements to check regardless of choice: metadata filtering that is applied during the search rather than after it, and a re-indexing path, since changing the embedding model invalidates every stored vector.