🐘 Tiger Data เปิดซอร์ส pg_textsearch: ก้าวใหม่ของการค้นหาแบบ BM25 บน PostgreSQL การที่ Tiger Data ตัดสินใจเปิดซอร์ส pg_textsearch ถือเป็นสัญญาณสำคัญของการเปลี่ยนเกมในโลกฐานข้อมูลโอเพ่นซอร์ส โดยเฉพาะอย่างยิ่งในยุคที่การค้นหาข้อมูลเชิงลึก (deep retrieval) และระบบ RAG กลายเป็นหัวใจของแอปพลิเคชัน AI สมัยใหม่ เนื้อหาบนหน้าเว็บระบุว่า pg_textsearch เคยเป็นฟีเจอร์เฉพาะบน Tiger Cloud แต่ตอนนี้ถูกปล่อยภายใต้ PostgreSQL License ทำให้นักพัฒนาและองค์กรสามารถนำไปใช้ได้อย่างอิสระ การมาของ BM25 แบบเนทีฟใน PostgreSQL ทำให้หลายองค์กรไม่จำเป็นต้องพึ่ง Elasticsearch สำหรับงานค้นหาที่ต้องการ ranking คุณภาพสูงอีกต่อไป นอกจากนี้ pg_textsearch ยังถูกออกแบบให้ทำงานร่วมกับ pgvector และ pgvectorscale เพื่อสร้างระบบค้นหาแบบ hybrid retrieval ที่ผสาน keyword + semantic search ในฐานข้อมูลเดียว ซึ่งเป็นทิศทางที่หลายบริษัทกำลังมุ่งหน้าไปในยุค AI-first ในมุมกว้างของอุตสาหกรรม การเปิดซอร์สครั้งนี้สะท้อนแนวโน้มที่ผู้ให้บริการฐานข้อมูลเริ่มผลักดัน “search inside the database” แทนการแยกระบบออกจากกันเพื่อลดความซับซ้อน ลดค่าใช้จ่าย และเพิ่มความเร็วในการพัฒนาแอปพลิเคชัน นอกจากนี้ยังช่วยให้ทีม DevOps และ SRE ลดภาระการดูแลระบบ search engine แยกต่างหาก ซึ่งมักมีต้นทุนสูงและต้องการผู้เชี่ยวชาญเฉพาะทาง สุดท้าย การเปิดซอร์ส pg_textsearch ยังเป็นการขยับหมากเชิงกลยุทธ์ของ Tiger Data ในการสร้าง “Postgres Search Stack” ที่ครบวงจร ตั้งแต่ keyword search, vector search ไปจนถึงการ scale retrieval สำหรับงาน AI enterprise ซึ่งอาจกลายเป็นคู่แข่งสำคัญของ Elasticsearch, OpenSearch และแม้แต่บริการ search-as-a-service เชิงพาณิชย์ในอนาคต 📌 สรุปประเด็นสำคัญ ✅ การเปิดซอร์ส pg_textsearch ➡️ เคยเป็นฟีเจอร์เฉพาะบน Tiger Cloud แต่ตอนนี้เปิดให้ใช้งานภายใต้ PostgreSQL License ➡️ ช่วยให้ Postgres รองรับ BM25 แบบเนทีฟโดยไม่ต้องใช้ระบบ search แยกต่างหาก ✅ ความสามารถของ pg_textsearch ➡️ รองรับ 29+ ภาษา และทำงานกับ partitioned tables ได้ ➡️ ใช้ operator <@> เพื่อทำ relevance-ranked search ได้ง่าย ➡️ ปรับค่า BM25 (k1, b) ได้ตามงาน ✅ การผสานกับ pgvector / pgvectorscale ➡️ ช่วยสร้าง hybrid retrieval (keyword + semantic) ในฐานข้อมูลเดียว ➡️ ลดความซับซ้อนของสถาปัตยกรรม RAG ✅ ผลกระทบต่ออุตสาหกรรมฐานข้อมูล ➡️ แนวโน้ม “search inside the database” กำลังมาแรง ➡️ ลดต้นทุนการดูแลระบบ search engine แยกต่างหาก ➡️ เพิ่มความเร็วในการพัฒนาแอปพลิเคชัน AI-first ⚠️ คำเตือน / ประเด็นที่ควรระวัง ‼️ การย้ายจาก Elasticsearch อาจไม่ง่าย ⛔ ระบบที่ใช้ฟีเจอร์เฉพาะของ Elasticsearch เช่น aggregations หรือ complex analyzers อาจต้องปรับโครงสร้างใหม่ ‼️ ประสิทธิภาพขึ้นกับ workload ⛔ แม้ BM25 ใน Postgres จะเร็ว แต่การ scale อาจยังไม่เท่าระบบ search engine ที่ออกแบบมาเฉพาะทาง ‼️ ความเสี่ยงด้านการจัดการ index ⛔ การใช้ memtable architecture ต้องวางแผนเรื่อง memory และการ update index ให้ดี https://itsfoss.com/news/tiger-data-pg-textsearch/