Tiger Data ปล่อย pg_vectorsearch: index เวกเตอร์ PRISM บน Postgres ที่สร้าง index 100 ล้านเวกเตอร์ได้ใน 1 ชม. 40 นาทีบนเครื่อง RAM 128 GB ซึ่ง HNSW ของ pgvector สร้างไม่สำเร็จ — แต่ยังเป็น alpha และต้องใช้ Postgres 18

Tiger Data (บริษัทเดิมชื่อ Timescale ผู้พัฒนา TimescaleDB) ปล่อย pg_vectorsearch 0.1.0 เมื่อ 13 ต.ค. 2026 เป็น extension ของ PostgreSQL สำหรับค้นหาเวกเตอร์แบบ approximate nearest neighbor ที่ไม่ได้ใช้กราฟแบบ HNSW ซึ่งเป็นตัวเลือกหลักของ pgvector แต่ใช้ index แบบ แบ่ง partition ชื่อ PRISM (Partitioned Routing Index for Similarity Matching) คู่กับการบีบอัดเวกเตอร์ด้วย RaBitQ ใบอนุญาตเป็น PostgreSQL License และโพสต์นี้ขึ้นหน้าแรก Hacker News เมื่อ 14 ต.ค.

สำหรับทีมที่ทำ RAG หรือ semantic search บน Postgres ปัญหาที่ pg_vectorsearch ต้องการแก้คือ HNSW ใช้ RAM มาก จนหลายทีมต้องย้ายไปใช้ vector database แยก Tiger Data บอกว่าที่ 100 ล้านเวกเตอร์ เครื่องเล็กสุดที่ HNSW สร้าง index สำเร็จคือเครื่อง RAM 512 GB

ตัวเลขจากผู้พัฒนา

ทุกตัวเลขด้านล่างมาจากเครื่องมือ benchmark สาธารณะของ Tiger Data เอง วัด recall@10 เทียบกับการค้นแบบ brute-force และฝั่ง HNSW ใช้ halfvec 16 บิตของ pgvector

100 ล้านเวกเตอร์ (Cohere embeddings, AWS r8i)

	r8i.4xlarge (128 GB)	r8i.16xlarge (512 GB, แพงกว่า 4 เท่า)
PRISM เวลาสร้าง index	1 ชม. 40 นาที	49 นาที
PRISM p50 ที่ recall 99%	21 ms	19 ms
HNSW เวลาสร้าง index	สร้างไม่สำเร็จ	42 ชั่วโมง
HNSW p50 ที่ recall 95%	—	8 ms
HNSW ที่ recall 99%	—	ทำ latency ที่ใช้งานได้ไม่ได้

PRISM บนเครื่อง 128 GB ได้ 6 ms ที่ recall 95% เทียบกับ 8 ms ของ HNSW บนเครื่อง 512 GB ทีมยังลองสร้าง HNSW บนเครื่องใหญ่แล้วย้ายไปรันบนเครื่องเล็ก ผลคือใช้เวลาเกิน 1 วินาทีต่อ query ที่ recall 95%

1 ล้านเวกเตอร์ บน c8g.large (RAM 4 GB) PRISM สร้าง index ในราว 3 นาที ส่วน HNSW ใช้ราว 21.7 ชั่วโมงเพราะกราฟไม่พอดี RAM ขนาด index ของ PRISM เล็กกว่าราว 7 เท่า และตอบเร็วกว่าราว 40 เท่าที่ recall เท่ากัน บนเครื่อง 2 GB PRISM ยังได้ recall 99% ที่ 15 ms ส่วน HNSW บนเครื่อง 4 GB ใช้ 392 ms

เหตุผลทางเทคนิคที่ทีมให้คือ การเดินกราฟต้องกระโดดไปยังตำแหน่งหน่วยความจำที่ CPU คาดเดาล่วงหน้าไม่ได้ จึงเกิด cache miss บ่อย ส่วนการสแกน partition อ่านหน่วยความจำต่อเนื่อง ทำให้ prefetcher และ SIMD (AVX2, AVX-512, NEON) ทำงานได้เต็มที่ นอกจากนี้ RaBitQ เก็บเวกเตอร์ราว 1 บิตต่อมิติ และขอบเขตความคลาดเคลื่อนของมันช่วยตัดเวกเตอร์ที่ไม่มีทางติดอันดับออกก่อนการ rerank ด้วยค่าเต็ม แนวทางนี้คล้ายกับ ScaNN ของ Google, SPANN ของ Microsoft และ turbopuffer

ใช้กับ pgvector เดิมได้ทันที

pg_vectorsearch มีชนิดข้อมูลของตัวเองคือ vec32 และ vec16 และยังสร้าง index PRISM บนคอลัมน์ vector/halfvec ของ pgvector ได้โดยไม่ต้องเขียนข้อมูลใหม่ query เดิมที่ใช้ <->, <#>, <=> ใช้ได้เหมือนเดิม:

CREATE EXTENSION pg_vectorsearch;
-- โหลดข้อมูลก่อน PRISM คำนวณขนาด index จากจำนวนแถวตอนสร้าง
CREATE INDEX ON documents USING prism (embedding vec32_l2_ops);
SET prism.nprobe = 40;  -- 0 = อัตโนมัติ (เป้า recall ~95%)

ค่าที่ต้องปรับมีค่าเดียวคือ prism.nprobe (จำนวน partition ที่สแกนต่อ query)

ข้อจำกัดของ alpha

• ต้องใช้ PostgreSQL 18 ขึ้นไป และยังไม่แนะนำสำหรับ production อัปเกรดระหว่าง prerelease อาจต้อง drop แล้วสร้าง extension และ index ใหม่
• insert/update ได้ แต่เมื่อข้อมูลเปลี่ยนมาก recall จะค่อย ๆ ลดลง เพราะยังไม่แบ่ง partition ใหม่อัตโนมัติ ต้องเรียก prism_rebalance หรือ REINDEX เอง และ ไม่ควรสร้าง index บนตารางว่างแล้วค่อยเติมข้อมูล
• delete ทำงานได้ แต่ยังไม่นำพื้นที่ในหน้า index กลับมาใช้ ต้อง REINDEX เพื่อคืนพื้นที่
• ยังไม่มีการกรอง WHERE แบบ streaming คู่กับ ORDER BY (อยู่ในแผน GA) และยังไม่ได้ทดสอบ replication หรือ backup/restore อย่างเต็มที่
• Tiger Data ประกาศว่า pgvectorscale (index แบบกราฟที่ได้แนวคิดจาก DiskANN ซึ่งทีมปล่อยปี 2024) จะเข้าสู่ maintenance mode โดยให้เหตุผลว่าบางส่วนของกราฟอาจเข้าไม่ถึงในชุดข้อมูลมิติต่ำ ทำให้ recall ลดลงโดยไม่มีใครสังเกต

มุมมอง AI Curator

เรื่องที่น่าสนใจที่สุดในประกาศนี้ไม่ใช่ตัวเลขความเร็ว แต่คือ ผู้พัฒนา index แบบกราฟยอมรับเองว่าเลิกใช้แนวทางนั้น Tiger Data ทำ pgvectorscale แบบ DiskANN มาสองปีแล้วพบว่า recall ลดลงแบบที่ตรวจไม่เจอ ซึ่งเป็นความเสียหายที่แย่กว่าระบบช้า เพราะผู้ใช้จะไม่รู้ว่าผลค้นหาแย่ลงจนกว่าคำตอบของ RAG จะเริ่มผิด ทีมที่ใช้ HNSW อยู่ควรถือเรื่องนี้เป็นสัญญาณให้วัด recall บนข้อมูลจริงเป็นระยะ ไม่ใช่วัดแค่ latency

ส่วนตัวเลข ต้องอ่านอย่างระมัดระวังเพราะผู้พัฒนาวัดเองบนชุดข้อมูลที่เลือกเอง แต่การเปิดเครื่องมือ benchmark สาธารณะและบอกให้ “เปิด issue ถ้าผลไม่ตรง” ช่วยให้น่าเชื่อถือขึ้น สำหรับทีมในไทยที่รัน Postgres บนเครื่องขนาดกลาง หรือบน managed service ที่ RAM มีราคาสูง ผลที่ 1 ล้านเวกเตอร์บนเครื่อง 2–4 GB สำคัญกว่าผลที่ 100 ล้าน เพราะงาน RAG ภายในองค์กรส่วนใหญ่อยู่ในช่วงนี้ แต่ข้อจำกัดเรื่อง Postgres 18 ทำให้ยังใช้กับ managed Postgres หลายเจ้าไม่ได้ และเรื่อง recall ลดลงเมื่อข้อมูลเปลี่ยนบ่อยทำให้เหมาะกับคลังเอกสารที่ค่อนข้างคงที่มากกว่า ช่วงนี้ควรลองบน staging ด้วยข้อมูลจริง แล้วค่อยพิจารณาอีกครั้งเมื่อมี rebalance อัตโนมัติใน GA

---

แหล่งข่าว

• Tiger Data — Announcing pg_vectorsearch: Scalable Open-Source Vector Search in PostgreSQL
• GitHub — timescale/pg_vectorsearch
• pg_vectorsearch — CHANGELOG (0.1.0, 13 ต.ค. 2026)