80/20 Of The Week: Vector Databases

80/20 Of The Week … Vector Databases

When we search for something normally, most systems look for exact words or close keyword matches.

That works fine… until it doesn’t.

For example, if I search for:

cheap phone

I probably also want results like:

budget smartphone affordable mobile device

The exact words are different, but the meaning is very close.

That is where normal keyword search starts struggling.

And that is also where vector databases start making sense.

1. What vector databases are

The easiest way to think about vector databases is this:

Once AI turns words, sentences, images, or documents into numerical representations called embeddings… you need somewhere to store them and search through them efficiently.

That “somewhere” is a vector database.

So instead of storing only plain text and asking:

“Which rows contain these exact words?”

you now store vectors and ask:

“Which stored items are closest in meaning to this query?”

That is the big shift.

2. Why we need them

Traditional databases are great at exact matches, filters, joins, transactions, and structured queries.

But semantic search works differently.

With semantic search, you do not only care about exact wording.

You care about similarity in meaning.

And once your data becomes embeddings, the main question is no longer:

“Does this text match exactly?”

It becomes:

“Which vectors are closest to this vector?”

That is not the kind of thing normal databases were originally designed for at scale.

Vector databases exist because once you have thousands, millions, or even more embeddings, finding the nearest ones quickly becomes its own problem.

3. What we can do with them

Vector databases are a big part of systems like:

• semantic search
• recommendation systems
• RAG pipelines
• duplicate/similarity detection
• image search
• matching users, items, or documents by meaning rather than exact words

For example:

• a search for cheap phone can return budget smartphone
• a question in a RAG system can retrieve documents that are relevant even if they do not use the exact same wording
• an image can be matched with visually similar images
• a product can be recommended because it is close in “feature space” to something a user liked before

Without vector search, many of these systems become much more brittle and much less useful.

4. What we cannot really do without them

Without vector databases, we can still do exact search.

But we lose a lot of the “meaning-based” behavior people now expect.

That means:

• worse semantic retrieval
• weaker recommendations
• less useful AI search
• much harder scaling once embeddings grow large
• slower similarity matching if we try to brute-force compare everything

So it is not that AI becomes impossible without them…

it just becomes much less practical and much less powerful in these use cases.

5. How they work

At a high level, the flow is usually this:

• take your text, image, or document
• pass it through an embedding model
• get a vector back
• store that vector in a vector database
• when a query comes in, embed the query too
• search for the nearest stored vectors
• return the most similar items

So if a document and a query have similar meaning, their vectors should end up relatively close.

That is the whole point.

In simple words:

keyword search tries to match words

vector search tries to match meaning

6. How implementation usually looks

A very common setup looks like this:

• raw data lives in your app / object store / SQL or NoSQL database
• embeddings are generated by an embedding model
• those embeddings are stored in a vector database
• query comes in
• query is embedded
• vector DB performs nearest-neighbor search
• top matches are returned to the application
• the app may then rerank, filter, or pass them into an LLM

So in practice, vector DBs are often not replacing everything.

They usually become one part of a bigger system.

For example:

• SQL DB stores product info
• vector DB stores product embeddings
• app combines filters like price/category with similarity search
• final result goes back to the user

That is why they feel both like an AI concept and a systems design topic.

7. Main takeaway

Vector databases matter because modern AI systems often need to search by meaning, not just by exact words.

Once embeddings enter the picture, storing and searching them efficiently becomes a real problem.

And vector databases are one of the main ways we solve it.

In short:

embeddings make semantic understanding possible

vector databases make it practical at scale

#AI #MachineLearning #VectorDatabases #Embeddings #SemanticSearch #RAG #SystemDesign #DataScience