Vector Databases

You will understand what vector databases are, why they exist, and how to use them in a real Spring Boot application to find meaning instead of just matching words.

Why This Matters

Picture a learner on EngineerPrep typing: "what should I do when a service goes down?" Your question bank has a great answer — a question about retry logic, one about fallback strategies, one about the Circuit Breaker pattern. But your SQL search looks for those exact words. "Service goes down" doesn't appear in any title. Zero results. The learner gives up. You just lost them. This is the keyword search problem. SQL is brilliant at finding exact matches. It is helpless when someone says the same thing in different words. A human reading both sentences instantly sees they mean the same thing. The question is: how do you give a database that same human intuition? That's exactly what vector databases are built to do.

The Simple Idea

Think about how you'd organize songs on a map. You might put heavy metal in one corner, classical in the opposite corner, and pop somewhere in the middle. Songs that sound similar end up close together on the map — even if their titles share no words. That's the core idea behind vector databases. A vector is just a list of numbers. For example: 0.2, 0.8, 0.1 . By itself that looks meaningless. But an AI model (called an embedding model ) can read a sentence and turn it into a vector — a list of hundreds of numbers that encodes the meaning of that sentence in a form the model has learned during training. Sentences with similar meanings get turned into vectors that are numerically close to each other. "Service goes down" and "handling failures" both land in the same neighborhood of that high-dimensional space.…

See It in Action

Imagine a simple two-dimensional map — just an X axis and a Y axis. In reality vectors have hundreds or thousands of dimensions, but two is enough to build the intuition. Step 1 — Questions get stored as dots. Every question in EngineerPrep's bank is fed through the embedding model. Each question comes out as a vector — a pair of coordinates in our simplified map — and gets placed as a dot. Questions about resilience patterns cluster in one area. Questions about data structures cluster in another. The dots land where they belong based on meaning, not keywords. Step 2 — A learner types a search query. The query "what should I do when a service goes down?" is fed through the same embedding model. Out comes a new vector — a new dot. It lands near the resilience cluster, because that's what the sentence is about. Step 3 — The database measures distances.…