Building a RAG System on MySQL from Scratch — VECTOR Type in Practice, Engineering Trade-offs, and a pgvector Reference

當大家談到 RAG（Retrieval-Augmented Generation），第一個想到的儲存層往往是 Pinecone、Qdrant、Milvus，或是 PostgreSQL + pgvector。但是在絕大多數企業既有的 stack 裡，MySQL 才是那個「明明就在那裡、卻幾乎沒有人在 RAG 選型討論中提到」的角色。 MySQL 9.0 已經正式加入 VECTOR 資料型別。那麼問題來了：在不另外搬一座資料庫的前提下，到底能不能用 MySQL 把一個可運作的 RAG 系統做出來？做得起來、又能撐多久？ 本場次以一個從零打造、完整開源的 demo 專案為主軸，帶聽眾一步步在 MySQL 9.x 上構建 RAG 系統：從 schema 設計、embedding 寫入、Top-K 相似度查詢，到串接 LLM 完成問答。途中會深入 VECTOR 型別的內部儲存方式、可用函式，以及目前最關鍵的限制——社群版尚未提供原生 ANN 索引。 接著，我們把同一份資料、同一組查詢搬到 PostgreSQL pgvector 上做對照組 benchmark，誠實呈現兩者在 latency、recall、開發體驗、維運成本上的差距。最後提出一個務實的選型決策框架：什麼情境下「在 MySQL 上做 RAG」是合理的工程選擇，什麼情境下應該果斷換工具。 所有 demo 程式碼、SQL schema、benchmark 腳本與投影片都會以 Apache-2.0 / CC BY-SA 授權公開於 GitHub，現場聽眾可以即時在自己的環境重現。