Your Database Can't Read. Vector Databases Can.

Vector databases are everywhere right now. Before you add one to your architecture, it is worth understanding what problem they actually solve.

The Search Problem Nobody Talks About 🔗

Think about it - when you search for "cheap hotels near the beach", a traditional database has no idea what you mean. It looks for rows where columns contain the words "cheap", "hotels", "near", "beach". Exact matches, maybe with some LIKE wildcards. It is matching characters, not meaning.

That works fine for structured queries. "Give me all orders where status = 'pending'" - a relational database handles that brilliantly. But the moment your search depends on meaning rather than exact text, you are fighting the tool.

This is the gap vector databases fill. They do not store rows and columns. They store meaning.

What Is a Vector, Really? 🔗

A vector is just a list of numbers. That is it. But those numbers are meaningful - they are the output of a machine learning model trained to capture the semantic content of whatever you fed it.

Give a text embedding model the sentence "the cat sat on the mat" and you will get back something like [0.12, -0.87, 0.45, ...] - hundreds or thousands of numbers. Feed it "a kitten rested on the rug" and you will get a different list, but one that is close to the first one in mathematical space. The model learned that cats and kittens are related, that sitting and resting are similar, that mats and rugs belong to the same world.

This is the core idea: things that mean similar things end up near each other in vector space. And "near" is something we can compute very fast.

The same principle works for images, audio, code snippets, user behaviour - anything you can run through a model that produces embeddings.

How Similarity Search Actually Works 🔗

Once you have vectors, finding the most similar ones is a geometry problem. The most common approach is cosine similarity - measuring the angle between two vectors. Two vectors pointing in roughly the same direction are semantically similar. Two vectors pointing in opposite directions are not.

In theory you could compare a query vector against every stored vector. At a thousand entries, that is fine. At a million, it is slow. At a billion, it is not going to work.

This is where indexing algorithms come in. HNSW (Hierarchical Navigable Small World) is the most widely used - it builds a graph structure that lets you skip most of the search space and find approximate nearest neighbours in milliseconds. The trade-off is that it is approximate - you might miss the single closest match in exchange for speed. In practice, for most use cases, the top 5 results from an approximate search are indistinguishable from the exact top 5.

Simply put: vector databases are optimised for this specific operation in a way general-purpose databases are not. You can store vectors in PostgreSQL and compute cosine similarity with pgvector. For moderate scale, that works well. But a dedicated vector database gives you purpose-built indexing, filtering, and metadata handling that a SQL extension cannot match at scale.

One thing worth naming explicitly: your existing ORM does not know what cosine similarity is. Entity Framework Core, Dapper, whatever you use - none of it has a concept of "find me the rows most similar to this query". This is not a gap in those tools; it is a different paradigm entirely. The mental model shift from "find this exact thing" to "find things similar to this thing" is the hardest part of adding vector search to an existing system - not the database choice.

RAG: The Use Case That Made Vector DBs Famous 🔗

If you have worked with LLMs, you have probably heard of Retrieval-Augmented Generation. The problem it solves: LLMs have a knowledge cutoff. They do not know your internal documentation, your latest product specs, your customer's order history. And you cannot dump it all into the prompt - context windows have limits, and at scale this gets expensive fast.

The solution: store that knowledge as embeddings in a vector database. When a user asks a question, convert the question to a vector, find the most relevant chunks from your database, and inject them into the prompt. The LLM answers based on your data, not just its training.

This is why every AI feature announcement mentions vector databases right now. They are the memory layer for LLM-powered applications.

But RAG is not the only use case worth knowing about.

Other Use Cases Worth Knowing 🔗

Semantic search is the obvious one - search that understands meaning. "Show me articles about concurrency issues" finds posts about race conditions and deadlocks even if they do not contain those exact words.

Recommendation systems are another strong fit. If you embed your products and your users' purchase history into the same vector space, you can find "users whose taste is similar to this user" or "products similar to this one" with a nearest-neighbour query.

Anomaly detection works similarly - embed your normal traffic patterns, then flag incoming requests whose vectors are far from any known cluster. Duplicate detection, image search, code similarity - they all reduce to the same operation: embed, store, query by proximity.

The Landscape: Which One Do You Pick? 🔗

Here is a quick honest comparison of the options you will actually encounter:

• Pinecone - fully managed, serverless pricing, minimal ops overhead. Good if you want to ship fast and do not want to think about infrastructure. Vendor lock-in is real.
• Qdrant - open source, written in Rust, excellent performance. My personal preference for self-hosted setups. Great filtering support and a clean API, plus an official .NET SDK (Qdrant.Client).
• Weaviate - open source, schema-oriented, supports hybrid search (vector + keyword) out of the box. Good if you need both semantic and structured queries in one place.
• Chroma - lightweight, easy local setup, popular for prototypes and small projects. Not what you would put in front of production traffic at scale.
• pgvector - a PostgreSQL extension. If you already run Postgres and your scale is moderate (think hundreds of thousands of vectors, not hundreds of millions), this is often the pragmatic choice. No new infrastructure, no new operational complexity, familiar tooling. With Pgvector.EntityFrameworkCore you get a Vector column type and LINQ methods like CosineDistance() and L2Distance() - you can be running similarity queries in EF Core in an afternoon.

In my opinion, the biggest mistake teams make is reaching for Pinecone or Qdrant before they have validated that pgvector cannot handle their load. For most .NET teams already on Postgres/EF Core, pgvector is the right first step. The dedicated vector database conversation should happen at scale, not day one.

What This Means in Practice 🔗

If you are evaluating vector databases, a few things are worth keeping in mind.

Your embeddings are only as good as your model. A bad embedding model produces vectors where similar things end up far apart - no indexing algorithm fixes that. Test your retrieval quality before committing to a database choice.

Embeddings go stale. If your underlying data changes, the vectors need to be regenerated. This is an operational concern most architecture diagrams skip over.

Hybrid search matters. Pure semantic search sometimes misses exact matches (product SKUs, proper nouns, IDs). Most real production systems combine vector similarity with keyword search. Some databases (Weaviate, Elasticsearch with kNN) support this natively; others you wire up yourself.

And finally - you do not need a vector database to use embeddings. If you are building a small RAG prototype, start with pgvector or even SQLite with a vector extension. Add the dedicated infrastructure when you have a reason to.

Useful .NET Tools and Packages 🔗

If you are building on .NET, these are the packages and tools you will reach for:

• Pgvector.EntityFrameworkCore - adds Vector column type to EF Core with CosineDistance() and L2Distance() LINQ methods. Start here if you are already on Postgres.
• Qdrant.Client - official Qdrant .NET SDK for working with a dedicated Qdrant instance.
• Microsoft.SemanticKernel.Connectors.Qdrant and Microsoft.SemanticKernel.Connectors.Postgres - Semantic Kernel connectors for using Qdrant or pgvector as the vector store in an SK-based application.
• Memorizer - a .NET service that gives AI agents persistent semantic memory using pgvector. Supports workspaces, tagging, versioning, knowledge graph relationships between memories, and a web UI. Ships as a Docker image and exposes an MCP server, so any MCP-compatible agent can use it as a memory layer out of the box.

Closing 🔗

Vector databases are a genuine new primitive in the software stack, not just AI hype with a database attached. They solve a real problem - matching by meaning, at scale - that relational databases were never designed for.

But like any tool, the question is not "should I use a vector database?" It is "does my problem require this, and at what scale?" Start simple. Measure. Add complexity when the simpler thing runs out of road.

vector-databases semantic-search pgvector