MariaDB Vector: Why your AI data should be in an RDBMS
summary
Argues that vectors belong inside a relational DB because your source, results and audit trail already live there and because storing vectors alongside rows enables mixed queries and reproducible RAG workflows. Describes MariaDB Vector as a core feature (not a plugin) that stores vectors, uses HNSW index today and will add IVF flat, supports nearest‑neighbor lookups (retrieve top 5–10), requires embeddings created externally (OpenAI, Llama, etc.), and emphasizes chunking, index reuse, auditability and internal speed benchmarks rather than reinventing a specialized vector store.
AI-written summary · about
chapters (7)
- 0:00Introduction
- 3:17Why vectors in RDBMS
- 4:43What is MariaDB
- 7:14AI features overview
- 9:47Main use cases explained
- 13:42Demo and resources
- 14:46Q&A
related talks
06mWhat makes vector databases essential for RAG and AI apps?
36mUnleashing the Power of Vector Databases for AI-Driven Applications
15mBeyond Vector Search: Building Ultra-Resilient GenAI Applications...
01h 46mVector Databases (for GenAI & beyond)
39mWhat's in a Vector Database?
42mChoosing the Vector Database for Your GenAI Application
48mVectors are the new JSON
26mThe Rise of Vector Databases - Lessons from the Milvus Community