What is a vector database

Each entry holds three things: the embedding vector itself, a metadata payload of ordinary fields such as dates, amounts, and account ids, and a pointer back to the source record. The vector is a search key, not the data; a query returns ids, scores, and metadata, and your application fetches the underlying document from wherever it lives.

The vectors arrive from outside. An embedding model, the subject of the companion article, maps each text chunk or record to a point in a space where nearby means similar; the database only stores and searches what your model produced. It follows that every vector in a collection must come from the same model, or the distances between them mean nothing.

The database also cannot repair what it is given. A financial document embedded as raw PDF text searches poorly; embedded as clean per-transaction rows it searches well. Producing those rows is where LedgerBox fits: a REST API and an open source TypeScript SDK that extract structured rows from bank statements before anything gets embedded.

Answering a similarity query exactly means measuring the distance from the query to every stored vector and keeping the smallest. That is trivial at ten thousand vectors and hopeless at a hundred million, because the work grows linearly with the collection. Approximate nearest neighbor search, ANN, is the escape hatch, accepting a small chance of missing a true neighbor in exchange for skipping most of the comparisons.

Two index families dominate. HNSW builds a layered graph in which each vector links to its neighbors, and a search hops greedily through the graph toward the query, descending layer by layer. IVF instead partitions the space into clusters and searches only the handful of clusters closest to the query. Both expose tuning parameters that move recall and latency against each other, and both are why results carry the word approximate: a slightly imperfect answer returned quickly usually beats a perfect one you had to wait for.

The practically hard part is not the similarity math but combining it with filters: nearest neighbors to this vector, but only where the account type is business and the date falls after January. Filter before the search and the index built over the whole collection no longer matches the survivors; filter after it and all k results may get thrown away. Engines differ more here than anywhere else, which makes filtered-query behavior the sharpest question to ask when evaluating one.

Dedicated engines include Pinecone, Weaviate, Milvus, Qdrant, and Chroma: systems built around ANN search, each with its own API, scaling story, and approach to the filtering problem above.

The other route extends a database you already run. pgvector adds a vector column type, distance operators, and HNSW and IVF indexing to Postgres, so embeddings sit in the same tables as everything else, inside the same transactions and joins, and the metadata filter is an ordinary WHERE clause. For many products that wins by subtraction: one fewer system to deploy, monitor, back up, and secure.

The honest tiebreaker is operational rather than algorithmic. A team already running Postgres with a collection in the hundreds of thousands of vectors rarely regrets starting with pgvector; a dedicated engine earns its keep when vector search is the core workload, the collection is very large, or its specific filtering and scaling machinery is the point.

Most projects start below the scale where any of this applies. A few thousand embeddings fit in memory as a plain array, and a flat scan that computes every distance is exact, a dozen lines of code, and quick enough that an index would add operational surface without adding anything a user could feel.

Treat the upgrade as a staircase, not a default. When the collection outgrows an in-memory scan, or needs persistence, concurrent writers, and filters, pgvector inside a Postgres you already operate comfortably covers a few hundred thousand vectors. A dedicated engine is the third step, and taking it on day one means running a new distributed system to serve queries a WHERE clause and an ORDER BY would have handled.