Vector databases explained for people who just want to understand. You have 10,000 product descriptions. User searches for "comfortable outdoor furniture." Traditional database: - Searches for exact word matches - Finds products containing "comfortable" OR "outdoor" OR "furniture" - Misses "cozy patio seating" even though it's the same thing - Keyword matching is stupid Vector database approach: - Convert search into numbers representing meaning: [0.2, 0.8, 0.1, 0.9, ...] - Convert every product description to similar numbers - Find products with similar number patterns - Returns "cozy patio seating" because the numbers are close - Meaning matching is smart How it works: Step 1: Turn text into vectors (arrays of numbers) - "comfortable chair" becomes [0.2, 0.7, 0.1, 0.4, ...] - "cozy seat" becomes [0.3, 0.8, 0.2, 0.5, ...] - Similar meanings = similar numbers - Uses AI models like OpenAI embeddings Step 2: Store vectors efficiently - Traditional database: Stores text - Vector database: Stores arrays of numbers per item - Indexes them for fast similarity search - Optimized for "find similar" not "find exact" Step 3: Search by similarity - User query: "outdoor furniture" - Convert to vector: [0.3, 0.6, 0.2, 0.8, ...] - Find closest vectors using math (cosine similarity) - Returns items ranked by similarity score Use cases: - Product search that understands intent - Documentation search that finds relevant answers - Recommendation engines - Chatbots that find similar questions - Anomaly detection Popular vector databases: - Pinecone: Managed, easy, expensive - Weaviate: Open source, feature-rich - Milvus: Fast, scalable, complex - pgvector: Postgres extension, simple - Qdrant: Fast, Rust-based Controversial take: You don't need a vector database for most projects. Start with Postgres + pgvector extension. Vector databases are great for scale. For under 1 million vectors, your regular database with a vector extension works fine.