Vector Databases Explained

One misconception is worth dispelling at the outset: a vector database is not the home of your documents, images, or audio. Its core job is to store embeddings, also called vectors, produced by a machine learning model, along with optional metadata. An embedding is a dense numerical vector that encodes the semantic content of an input as a point in high-dimensional space. When you pass a sentence through a text embedding model you get back an array of floating-point numbers, perhaps 768 dimensions from a model such as BERT-base or 3,072 from a more recent embedding model. Those numbers represent the meaning of the sentence geometrically: sentences that mean similar things produce vectors that are close together, and unrelated sentences produce vectors that are far apart. The model encodes; the database stores and retrieves. The distinction matters because the quality of your retrieval depends entirely on the quality of your embeddings. A vector database is a precision instrument, but it is only as useful as what you feed it, and weak embeddings produce weak retrieval regardless of how sophisticated the indexing is. For each record a vector database typically holds the vector itself, a unique identifier, and optional metadata such as a title, timestamp, or category. The source content, such as the original text chunk, is best kept elsewhere, usually in a relational or document database: the vector store returns IDs and optionally metadata, and your application fetches the full content using those IDs. Some systems let you keep the chunk text in the metadata payload for convenience, but treating the vector store as the canonical copy of your data is an anti-pattern. This also explains why the shorthand that any database with a vector extension is a vector database is dangerous. Postgres with the pgvector extension is a legitimate and useful tool, but it is architecturally different from purpose-built systems such as Pinecone, Weaviate, Qdrant, and Milvus, which are designed from the ground up for high-dimensional vector workloads, with indexing, memory management, and query execution optimised specifically for this task at scale. Pgvector is a sensible choice for smaller workloads or teams already committed to Postgres, but conflating the two can lead to poor performance decisions.