Skip to main content
Hello and welcome back. We now understand vector embeddings and how data becomes a list of numbers. A natural follow-up is: once embeddings are stored in a vector database, how do you retrieve meaningful results? This lesson assumes you already installed a vector database, created embeddings, and inserted them into the database. The core question here is: how do you query the information that
The image shows a diagram titled "Querying Vector Database," featuring a stylized vector database icon and three labeled steps: installation, storing embeddings, and querying.
is stored there? To make that easier to understand, we’ll first contrast this with something simpler: querying a normal (relational) database. Seeing how traditional databases search will make the vector-database approach more intuitive.

​
What you need to query a normal (relational) database

When you query a relational database such as MySQL or PostgreSQL, the process is structured and deterministic: you must provide specific, concrete details. Typically you need:
  • Connection details: host/URL, username, and password — credentials to access the database.
  • Location details: which database and which table to query — a database can contain many tables, like drawers in a filing cabinet.
  • The query: an exact instruction that specifies which rows and columns to return.
The image illustrates the process of querying a normal database, highlighting the necessary information such as connection details (URL, username, password), database name, table name, and query.
Put simply: connection details + where to look + what to ask = results.

​
Typical SQL example

Here is a simple SQL query that selects all products in the electronics category: 
SELECT * FROM products
WHERE category = 'electronics';
Breaking it down:
  • SELECT * — return all columns for matching rows.
  • FROM products — search the products table.
  • WHERE category = 'electronics' — filter rows where category exactly equals 'electronics'.
A relational database performs exact matches based on the column values and predicates you provide. For the query above, the database would return rows like: 
ID: 101 | Name: Laptop | Category: electronics
ID: 102 | Name: Phone  | Category: electronics
ID: 103 | Name: Tablet | Category: electronics
Relational databases match exact values (and boolean combinations of conditions). They are fast and predictable for structured, keyword-based queries, but they do not inherently understand the semantic meaning of words.
That strict exactness is both a strength and a limitation. If a user searched for gadgets or tech items, the SQL query above would return zero rows even though Laptop, Phone, and Tablet are conceptually related — because the table stores the literal string electronics, not the semantic concept “gadgets.”
AspectRelational (SQL)Semantic (Vector)
Match typeExact, deterministicSimilarity-based, fuzzy
Query inputStructured predicates (WHERE)Natural language, query embedding
Typical use caseTransactional data, reportingDocument search, recommendations, QA
PerformanceHighly optimized for exact lookupsRequires vector similarity search/indexing
Examplescategory = 'electronics'”Find items related to gadgets”

​
Security and best practices

Never hard-code credentials in source files or client-side code. Use environment variables, secrets management, or managed identity solutions to protect database credentials.

​
Where to go from here

Now that you understand how relational databases require exact queries and structured access, the next step is to learn how vector databases perform semantic search using embeddings and similarity metrics. That approach lets you search by meaning, not just exact keyword matches. Links and references: That is it for this lesson.

Watch Video