Vector Databases Explained — What They Are, How They Work, and Why Your Business Needs One
Every AI-powered feature you've seen in the last two years — semantic search, chatbots that actually understand questions, recommendation engines that feel uncanny, RAG systems that answer from your own documents — they all share one piece of infrastructure under the hood: a vector database.
Yet most business leaders have never heard of them. They're the unsung engine behind the AI revolution — invisible to users, indispensable to builders. If you're planning any AI feature for your product or internal tools, understanding vector databases isn't optional. It's foundational.
This guide explains vector databases from first principles. No maths degree required. By the end, you'll understand what they are, why they exist, how they compare, and whether your next project needs one.
📖 What This Guide Covers
• What vectors and embeddings are
• How vector search differs from keyword search
• Key concepts: dimensions, similarity metrics
• Real use cases with business impact
• Database comparison (7 options)
• Decision framework for choosing
• Performance and indexing strategies
• Cost analysis at different scales
• Getting started (5 steps)
• When you DON'T need one
What is a Vector? (The Plain English Version)
A vector is simply a list of numbers that represents something's meaning. That's it. Not its text, not its name, not its ID — its meaning.
Think of it like GPS coordinates for concepts. London is at roughly (51.5, -0.1). Paris is at (48.9, 2.3). They're close together on a map — and their coordinates reflect that proximity. Now imagine doing the same thing, but for meaning rather than geography — and using 1,000+ dimensions instead of just two.
🗺️ The Meaning Map Analogy
"King" → [0.21, -0.44, 0.87, 0.12, ...] (1,536 numbers)
"Queen" → [0.23, -0.41, 0.85, 0.15, ...] (nearby in vector space)
"Banana" → [-0.65, 0.33, -0.12, 0.77, ...] (far away — different meaning)
Words with similar meanings end up with similar numbers. The AI model that creates these numbers has learned from billions of text examples what "similar meaning" looks like.
The process of converting text (or images, or audio) into these number arrays is called embedding. The numbers themselves are called an embedding vector. And the AI model that does the conversion is called an embedding model.
A vector database, then, is a specialised database optimised for storing millions of these number arrays and finding the most similar ones to a given query — in milliseconds.
How Vector Search Works (vs Keyword Search)
Traditional search (what you've used for 25 years) is keyword-based. It matches the exact words you type against the exact words in the database. Vector search matches meaning against meaning — regardless of what specific words are used.
| Query | Keyword Search Result | Vector Search Result |
|---|---|---|
| "affordable car" | Only docs containing "affordable" AND "car" | Also finds "budget vehicle", "cheap automobile", "economical transport" |
| "how to fix a broken pipe" | Plumbing AND software pipe results mixed | Understands context — returns plumbing guides if context is home repair |
| "feeling under the weather" | Weather forecasts (wrong) | Health and wellness content (correct — understands the idiom) |
| "I need to return this" | Pages containing the word "return" | Returns policy, refund process, exchange info |
This difference is transformative for business applications. Your customers don't search using the exact terminology in your documentation — they use their own words, slang, idioms, and questions. Vector search bridges that gap.
✅ The Business Impact
Companies switching from keyword search to vector search typically see a 40-60% improvement in search relevance and a 25-35% reduction in support tickets — because customers find the right answer on the first search, in their own words.
Key Concepts: Embeddings, Dimensions, and Similarity Metrics
Three concepts come up in every vector database conversation. Here's what each means in practical terms:
Embeddings
An embedding is the numerical representation of a piece of content — a sentence, paragraph, image, or product description. You create embeddings using an embedding model (like OpenAI's text-embedding-3-small or Cloudflare's bge-base-en-v1.5).
You embed your documents once (during indexing), and you embed the user's query at search time. Then you compare the query embedding against all stored document embeddings to find the closest matches.
Dimensions
Dimensions are how many numbers are in each vector. More dimensions generally means more nuanced meaning capture — but also more storage and computation cost.
384 dimensions
Fast, cheap, good for simple similarity. Models: MiniLM, bge-small.
768 dimensions
Balanced. Good for most business use cases. Models: bge-base, Cohere embed.
1,536 dimensions
High fidelity. Best quality, higher cost. Models: OpenAI text-embedding-3-small.
Similarity Metrics
How does the database decide which vectors are "close" to each other? Three main methods:
Cosine Similarity
Measures the angle between vectors. Ignores magnitude, focuses on direction.
Best for: text search, RAG, semantic matching. The default choice for most use cases.
Dot Product
Measures both direction and magnitude. Rewards vectors that are both similar and "strong".
Best for: recommendation systems where magnitude indicates relevance or popularity.
Euclidean Distance
Straight-line distance between points. Simple and intuitive.
Best for: clustering, anomaly detection, image similarity.
💡 Practical Advice
If you're unsure, use cosine similarity. It's the default for text-based applications and works correctly regardless of how your embeddings are normalised. You'll only need alternatives for specialised use cases.
Use Cases: Where Vector Databases Create Business Value
Vector databases aren't a solution looking for a problem. They solve real, expensive problems that traditional databases cannot. Here are the six highest-impact use cases:
🤖 RAG Chatbots
AI chatbots that answer from your specific documentation. The vector database stores your knowledge base and retrieves relevant context for every question.
Impact: 60-80% reduction in support tickets. 24/7 instant answers.
🔍 Semantic Search
Replace keyword search with meaning-based search across documentation, products, or content. Customers find what they need using natural language.
Impact: 40-60% improvement in search relevance. Higher conversion.
🎯 Recommendation Engines
"Customers who liked X also liked Y" — powered by embedding similarity rather than manual tagging. Works for products, content, music, and any catalogue.
Impact: 15-30% increase in average order value or engagement.
🖼️ Image & Visual Search
Upload a photo, find visually similar products. Used in fashion, real estate, manufacturing QA, and art. Embed images with CLIP or similar vision models.
Impact: New UX paradigm. "Find me something like this" without words.
🚨 Anomaly Detection
Embed normal behaviour patterns, then flag anything that's far away in vector space. Used in fraud detection, security monitoring, and quality control.
Impact: Catch fraud 10x faster than rule-based systems.
🔄 De-Duplication
Find near-duplicate records even when they're worded differently. "John Smith, 10 High St" and "J. Smith, 10 High Street" are the same person — vector similarity catches this.
Impact: Clean data, reduced storage costs, fewer customer mix-ups.
Vector Database Comparison (2026)
The market has matured rapidly. Here's how the major options compare across the dimensions that matter for production workloads:
| Database | Type | Hosting | Free Tier | Max Vectors | Best For |
|---|---|---|---|---|---|
| Pinecone | Managed SaaS | Cloud only | Yes (100K vectors) | Billions | Enterprise, zero ops |
| Cloudflare Vectorize | Managed (edge) | Cloudflare network | Yes (5M vectors) | 5M per index | Cloudflare stack, low latency |
| Weaviate | Open source + Cloud | Self-hosted or managed | Yes (sandbox) | Billions | Multi-modal, GraphQL API |
| Qdrant | Open source + Cloud | Self-hosted or managed | Yes (1GB cluster) | Billions | Performance, Rust-native |
| Milvus | Open source + Cloud | Self-hosted (Zilliz cloud) | Yes (Zilliz free) | Trillions | Massive scale, enterprise |
| pgvector | PostgreSQL extension | Wherever Postgres runs | Yes (it's free) | Millions | Existing Postgres, simple |
| Chroma | Open source (embedded) | In-process or hosted | Yes (open source) | Millions | Prototyping, Python devs |
🏆 Our Recommendations
Already using Cloudflare? → Cloudflare Vectorize. Native integration with Workers AI, zero network hops, generous free tier.
Want zero infrastructure management? → Pinecone. The most mature managed service with excellent documentation.
Need full control (self-hosted)? → Qdrant. Rust-based, fast, excellent API design, good Docker support.
Already on PostgreSQL? → pgvector. Add vector search without introducing a new database. Limits around 1-5M vectors.
Just prototyping? → Chroma. Runs locally, zero config, Python-native. Move to production DB later.
How to Choose a Vector Database (Decision Framework)
Choosing the right vector database depends on five factors. Answer these questions and the right option usually becomes obvious:
1. How many vectors will you store?
Under 100K → any option works, stay simple. 100K-5M → managed services or pgvector. 5M+ → purpose-built (Pinecone, Qdrant, Milvus). 100M+ → Milvus or Pinecone enterprise.
2. What's your existing infrastructure?
On Cloudflare → Vectorize (zero-friction integration). On AWS → Pinecone or self-host on ECS. On PostgreSQL → pgvector first, migrate later if needed. On nothing yet → Pinecone (least to manage).
3. What latency do you need?
Under 50ms (real-time search UX) → Cloudflare Vectorize (edge), Qdrant (in-memory). Under 200ms (chatbot) → any managed service. Under 1s (batch processing) → anything, latency doesn't matter.
4. Do you need metadata filtering?
"Find similar products, but only in category X and under £50" — this requires metadata filters. Pinecone, Qdrant, and Weaviate handle this natively. pgvector requires joining with regular SQL. Chroma supports basic filters.
5. What's your budget and team size?
Solo developer → Chroma (prototype) then Pinecone (production). Small team → Pinecone or Cloudflare Vectorize. Dedicated infra team → Qdrant or Milvus self-hosted (cheapest at scale, most control).
Performance Considerations: Indexing Strategies
When you have millions of vectors, you can't compare the query against every single one (that would be too slow). Vector databases use indexing algorithms to approximate nearest-neighbour search — trading a small amount of accuracy for massive speed improvements.
Three main strategies dominate:
HNSW (Hierarchical Navigable Small World)
Most PopularCreates a graph structure that navigates from coarse to fine — like zooming into a map. Start at the continent level, narrow to country, city, street.
Speed: Very fast (sub-ms)
Accuracy: 95-99%
Memory: High (index in RAM)
Used by: Pinecone, Qdrant, Weaviate, pgvector (with hnsw index)
IVF (Inverted File Index)
Divides vectors into clusters (buckets). At search time, only searches the most relevant buckets. Like searching one shelf in a library instead of the whole building.
Speed: Fast
Accuracy: 90-95%
Memory: Lower than HNSW
Used by: Milvus, Faiss, pgvector (with ivfflat index)
Flat (Brute Force)
Compares against every vector. Guaranteed perfect accuracy, but O(n) — gets linearly slower as data grows. Only viable for small datasets.
Speed: Slow at scale
Accuracy: 100%
Memory: Lowest
Used by: Chroma (default), development/testing environments
⚠️ What This Means Practically
For most business applications, the managed services handle indexing automatically — you don't need to configure HNSW parameters yourself. The key takeaway: vector search at scale is approximate (95-99% accurate), not exact. This is fine for search, recommendations, and RAG. It would not be appropriate for cryptographic or financial applications requiring exact matching.
Cost Analysis: What to Expect at Different Scales
Vector database costs have dropped dramatically since 2023. Here's what realistic monthly costs look like in 2026:
| Scale | Vectors | Queries/day | Managed (£/mo) | Self-hosted (£/mo) | Notes |
|---|---|---|---|---|---|
| Prototype | Under 10K | Under 100 | £0 (free tier) | £0 (Chroma local) | All providers have free tier at this level |
| Small | 10K-100K | 100-1K | £0-25 | £0 (pgvector on existing DB) | Most startups stay here for months |
| Medium | 100K-1M | 1K-10K | £50-200 | £30-100 (VPS) | Most production RAG systems |
| Large | 1M-10M | 10K-100K | £200-800 | £100-400 (dedicated) | E-commerce, large catalogues |
| Enterprise | 10M+ | 100K+ | £2,000+ | £1,000+ (cluster) | Custom pricing, multi-node clusters |
💰 Hidden Costs to Budget For
Embedding generation: You pay the embedding model provider (OpenAI, Cohere, or self-hosted) to convert text into vectors. At £0.02-0.10 per 1M tokens, this is usually negligible for indexing but adds up for high query volumes.
Re-indexing: When you update documents, you need to regenerate embeddings. Budget for periodic re-indexing costs.
Query-time AI inference: In a RAG system, the vector DB is step 1. You still pay for the LLM that generates the final response (£0.50-5.00 per 1K queries depending on model).
Getting Started: 5 Steps to Your First Vector Search
Here's the practical path from "nothing" to "working vector search" — regardless of which provider you choose:
Prepare Your Data
Gather the documents you want searchable. Split them into sensible chunks (typically 200-500 words per chunk). Each chunk becomes one vector. Too large = diluted meaning. Too small = lost context.
Choose an Embedding Model
For English text: OpenAI text-embedding-3-small (cheap, good) or Cloudflare bge-base-en-v1.5 (free on Workers AI). For multilingual: Cohere embed-multilingual-v3. Match the model's output dimensions to your vector database configuration.
Index Your Documents
Pass each chunk through the embedding model to get its vector. Store the vector + the original text + metadata (title, URL, category) in your vector database. This is a one-time operation (plus updates when docs change).
Build the Query Pipeline
When a user searches: embed their query using the same model → query the vector DB for top-K similar vectors → return the associated text chunks. For RAG: feed those chunks + the original question to an LLM for a synthesised answer.
Evaluate and Iterate
Test with real queries. Check: does it return the right documents? Is the relevance good? Tune: chunk size, overlap between chunks, number of results returned (top-K), and metadata filters. Most teams iterate 3-4 times before production.
⏱️ Timeline Reality Check
A basic vector search proof of concept can be built in 1-2 days by an experienced developer. Production-quality (with chunking strategy, metadata, error handling, monitoring) takes 3-6 weeks. Full RAG system with citations, feedback loops, and analytics: 4-8 weeks.
When You DON'T Need a Vector Database
Not every search problem requires vectors. Here's when traditional approaches are better:
Skip Vectors When...
- • You need exact matching (order IDs, email addresses, SKUs)
- • Your data is purely structured/numerical (SQL is better)
- • You have fewer than 100 documents (just put them in the prompt)
- • Users search by known fields (filters, not free text)
- • Full-text search (Elasticsearch, Meilisearch) already works well enough
- • Your content is highly structured (product codes, taxonomies)
Use Vectors When...
- • Users search with natural language questions
- • Content uses varied terminology for the same concepts
- • You need "similar to this" functionality
- • You're building RAG (AI + your documents)
- • You need cross-lingual search (query in English, find French docs)
- • You want recommendations based on content similarity
⚠️ Common Mistake
The biggest mistake we see: businesses adding a vector database when full-text search with good ranking would suffice. If your users search for "Nike Air Max size 10" and you have structured product data with those exact fields — a regular search index (Elasticsearch, Meilisearch, even PostgreSQL full-text) is simpler, cheaper, and likely more accurate. Vectors shine when meaning varies from wording.
Summary: Key Takeaways
Vector databases are the infrastructure layer that makes modern AI features possible. Here's what to remember:
1. Vectors capture meaning, not keywords. They're numerical representations of content that allow similarity-based search — finding things that mean the same thing, even when worded differently.
2. They're the backbone of RAG. Every AI chatbot that answers from your documents uses a vector database to find the right context before generating a response.
3. The market is mature enough for production. Managed services (Pinecone, Cloudflare Vectorize) handle scaling, indexing, and operations. You don't need a PhD to use them.
4. Start small, scale later. Free tiers are generous. Prototype with 1,000 vectors, prove value, then scale to millions. The architecture stays the same.
5. Choose based on existing infrastructure. Already on Cloudflare? Use Vectorize. Already on PostgreSQL? Start with pgvector. Greenfield? Pinecone for zero ops.
6. They're not always the answer. Exact matching, structured queries, and small document sets don't need vectors. Use the right tool for the problem.
7. Costs are predictable and reasonable. Most production workloads cost £50-500/month. The embedding model and LLM inference are often the larger cost, not the database itself.
Need help choosing or implementing a vector database?
We build production RAG systems and semantic search for UK businesses — from architecture selection through to deployment and monitoring. Whether you're evaluating options or ready to build, we can help you move faster with fewer wrong turns.
Book a free consultation →