Search for a command to run...
No comments yet. Be the first to comment.
Privacy isn't dead. It's just being rebuilt. The old internet promised us "move fast and break things." We moved fast. We broke things. Now we're realizing what we broke: privacy. Every LLM you use wa
Coding is changing faster than you think. Not just "AI helps with autocomplete." AI is becoming the primary developer. You become the reviewer. The Skill Inversion Old model (2020): Human writes code.
Single AI agents are limited. They make mistakes. They miss context. They take wrong paths. Multi-agent systems don't have these problems. They have different problems. But better ones. The Single Age
You've learned basic RAG. You embed documents. You retrieve them. You feed them to an LLM. It generates an answer. Then you deploy it. And it breaks. Because the real world isn't simple retrieval. Adv
The biggest AI models aren't winning anymore. GPT-4: 1.8 trillion parameters Claude 3 Opus: 200+ billion parameters Claude 3.5 Sonnet: Unknown but smaller Llama 3.1: 405 billion parameters PhiMoe (ope
Muhammad Zulqarnain | Full Stack AI Engineer & Geospatial Developer
16 posts
A blog by Muhammad Zulqarnain — Full Stack AI Engineer & Geospatial Developer based in Turku, Finland. I write about RAG systems, LLMs, Prompt Engineering, Next.js, TypeScript, and geospatial development. Practical insights, deep dives, and real-world AI solutions.
You've never heard of vector databases.
Yet they're running in the background of every AI app you use.
ChatGPT uses them. Claude uses them. Every startup building on top of LLMs uses them.
And understanding them is about to become a superpower.
Traditional databases are designed for exact matches.
SQL query: "Give me rows where name = 'Muhammad'" Database: "Found 3 exact matches."
Useful for structured data. Useless for meaning.
Vector databases are designed for semantic search.
Query: "Find documents similar to this concept." Vector DB: "Here are the 10 most semantically similar documents."
Completely different paradigm.
Step 1: Convert to Vectors
Take text: "The CEO announced a merger." Pass through embedding model (e.g., OpenAI embedding API). Get back: [0.2, -0.5, 0.8, 0.1, ...] (1536 dimensions for OpenAI)
Numbers represent semantic meaning in high-dimensional space.
Step 2: Store in Vector DB
Instead of:
ROW 1: text="The CEO announced a merger", id=1
You store:
ROW 1: vector=[0.2, -0.5, 0.8, ...], text="The CEO announced a merger", id=1
Step 3: Search by Similarity
Query: "What did the executive say?" Convert to vector: [0.18, -0.52, 0.75, ...] Find closest vectors using distance metrics (cosine similarity, L2 distance). Return: "The CEO announced a merger" (most similar)
No exact match needed. Semantic match is enough.
Before Vector DBs (The Old Way)
User: "What's our refund policy?" Company's chatbot: Keyword search for "refund". Returns: 47 documents (because they all mention refund). User: "That's not helpful."
After Vector DBs (The New Way)
User: "What's our refund policy?" Chatbot: Semantic search for documents about returns and reimbursement policies. Returns: 3 highly relevant documents. User: "Perfect."
Before Vector DBs (Code Search)
Engineer: "Find code that handles payments." IDE: Returns 200 results with the word "payment". Engineer wastes 2 hours filtering noise.
After Vector DBs (Code Search)
Engineer: "Find code that handles payments." AI: Semantic search finds payment processing logic even if named differently. Engineer: Gets to work in 30 seconds.
Vector DB Vendors:
Pinecone - Most popular, $100M+ raised
Weaviate - Open source, strong community
Milvus - Chinese alternative, massive scale
Qdrant - Privacy-focused, European
Chroma - Emerging, embedded approach
Why so many? TAM is massive. Winner hasn't emerged yet.
Companies Using Vector DBs:
Every RAG (Retrieval Augmented Generation) company
Every semantic search startup
Every AI knowledge base company
Every code search AI company
Dimension Count
OpenAI embeddings: 1536 dimensions
Anthropic embeddings: 768 dimensions
Open source models: 384-1024 dimensions
More dimensions = more semantic richness = slower search. Trade-off to optimize.
Distance Metrics
Cosine Similarity: Most popular. Measures angle between vectors.
L2 Distance: Euclidean distance. Useful for denser data.
Dot Product: Fast, works with normalized vectors.
Choice matters for your use case.
Retrieval Speed
Brute force: Check every vector. Slow but accurate.
HNSW (Hierarchical Navigable Small World): Fast approximation. Default for most.
IVF (Inverted File Index): Good for massive scale.
Balance accuracy vs speed.
The Setup
50,000 support tickets in your database
New customer question: "My payment failed, what do I do?"
Goal: Find similar past tickets to help answer
The Vector DB Approach
Embed the 50,000 tickets once (cost: $5 in API calls)
Store in Pinecone (cost: $50/month)
New question comes in
Embed it (cost: $0.001)
Search vector DB (instant, 1ms)
Return top 5 similar tickets
Feed to LLM as context
LLM generates personalized answer
Total latency: 500ms Total cost: Negligible
The Old Approach (Keyword Search)
Keyword search 50,000 tickets for "payment failed"
Get 400 results
Rank by relevance (what's "relevance"?)
Return top 5
Agent manually reads and composes response
Total latency: 10 minutes of human time Total cost: $1-2 per ticket
RAG = Retrieval Augmented Generation.
Every successful AI product uses it:
Retrieval: Use vector DB to find relevant context
Augmentation: Add context to the LLM prompt
Generation: LLM generates answer using context
Without vector DBs, RAG doesn't work.
Without RAG, AI apps hallucinate and fail.
Vector DBs are foundational infrastructure.
At 1M documents: Works fine. At 10M documents: Still fine. At 100M documents: Vector DB costs spike. Latency increases. At 1B documents: Becomes a real problem.
Your choice of vector DB and index type matters at scale.
Pinecone scales better than self-hosted. Costs more. Self-hosted (Qdrant, Weaviate) is cheaper at huge scale but harder to operate.
1. Hybrid Search
Combine:
Semantic search (vector) for meaning
Keyword search (traditional) for exact terms
Filtering (traditional) for constraints
All integrated seamlessly. Best of both worlds.
2. Multi-Modal Vectors
Embeddings that work across:
Text
Images
Audio
Video
Search across modalities. Find video similar to a text query.
3. Real-Time Embeddings
Embeddings that update as data changes.
Today: Embed data once, store forever. Future: Embeddings that adapt to context.
4. Smaller, Faster Embeddings
Today's OpenAI embeddings: Fast and good. Future: 10x smaller, 100x faster, still 95% as accurate.
Cheaper inference. Faster search. More accessible.
If you're a founder:
Build on vector DBs immediately
Make semantic search your moat
Your competitors using keyword search will lose
If you're an engineer:
Learn embeddings (OpenAI API or open source)
Experiment with Pinecone or Weaviate
Build a simple semantic search feature
Understand HNSW indexing
If you're hiring: Look for engineers who understand:
What embeddings are
How to chunk data for embeddings
How to evaluate embedding quality
How vector DBs actually work under the hood
Rare skill. 10x value.
Databases used to be about storing data.
Vector databases are about storing and finding meaning.
That's the fundamental shift in data infrastructure.
Every serious AI product will have a vector DB in its stack.
Mastering them puts you ahead of 99% of other engineers.d Every AI App