Sanggahan terhadap PGVector

• Ekstensi Postgres pgvector mendukung pencarian kemiripan vektor, tetapi ada kesenjangan besar antara level demo dan lingkungan produksi nyata
• Indeks IVFFlat dan HNSW sama-sama memiliki kelebihan dan kekurangan yang jelas; khususnya HNSW bermasalah karena penggunaan memori hingga beberapa GB saat pembuatan indeks dan waktu build yang lama
• Pencarian real-time dan pembaruan indeks secara struktural sulit, dan saat penyisipan serta pembaruan berlangsung terus-menerus akan terjadi kontensi lock dan penurunan performa
• Karena keterbatasan strategi filtering (Pre/Post) dan query planner, muncul keseimbangan yang tidak stabil antara akurasi pencarian dan kecepatan
• Fitur yang disediakan database vektor khusus (Pinecone, Weaviate, dll.) harus diimplementasikan secara manual, yang pada akhirnya berujung pada peningkatan kompleksitas operasional dan biaya

---

Gambaran umum keterbatasan pgvector

• pgvector adalah ekstensi yang menambahkan kemampuan pencarian kemiripan vektor ke Postgres; ia bekerja baik dalam demo sederhana, tetapi menimbulkan masalah skalabilitas di lingkungan produksi
• Banyak tulisan blog hanya membahas instalasi dan contoh query sederhana, sementara masalah performa, memori, dan pengelolaan indeks saat operasional hampir tidak pernah disinggung

Masalah dalam pemilihan indeks

• pgvector menyediakan dua jenis indeks: IVFFlat dan HNSW
  • IVFFlat: struktur berbasis klaster; pembuatan indeks cepat, tetapi pengaturan jumlah klaster sangat memengaruhi performa dan akurasi
    • Karena redistribusi klaster tidak dimungkinkan, rebuild indeks berkala diperlukan
  • HNSW: struktur graf berlapis yang memberikan akurasi dan performa yang konsisten, tetapi penggunaan memori saat pembuatan indeks sangat tinggi dan prosesnya lambat
• Saat membuat indeks untuk jutaan vektor, penggunaan RAM lebih dari 10GB dimungkinkan, dan ini menjadi ancaman langsung bagi stabilitas database produksi

Sulitnya pencarian real-time

• Data baru harus bisa dicari segera setelah disisipkan, tetapi karena struktur pembaruan indeks, pencerminan secara real-time sulit dilakukan
  • IVFFlat: vektor baru ditambahkan ke klaster yang ada, dan seiring waktu terjadi ketidakseimbangan klaster → perlu rebuild berkala
  • HNSW: saat penyisipan, pembaruan graf menyebabkan kontensi lock dan beban memori
• Selama rebuild indeks, menjaga konsistensi data dan kesinambungan layanan menjadi sulit
• Di lingkungan produksi, diperlukan berbagai strategi workaround seperti staging table, indeks ganda, build offline, eventual consistency, dan lainnya

Keterbatasan filtering dan query planner

• Saat menggabungkan filter metadata seperti status, user_id, category dengan pencarian vektor, pilihan Pre-filter vs Post-filter sangat memengaruhi performa
  • Pre-filter menguntungkan untuk filter yang selektif, tetapi lambat jika datanya banyak
  • Post-filter lebih cepat, tetapi ada kemungkinan hasil hilang setelah filtering
• Query planner Postgres tidak memahami cost model untuk kemiripan vektor, dan karena informasi statistik tidak akurat, ia menghasilkan execution plan yang tidak efisien
• Akibatnya, diperlukan solusi sementara seperti CTE, partisi, penulisan ulang query, dan sebagainya, yang tidak efisien saat skala membesar

Perbandingan dengan database vektor khusus

• Pinecone, Weaviate, OpenSearch k-NN, dan lainnya secara bawaan menyediakan pemilihan strategi filtering otomatis, pencarian hybrid, indexing real-time, dan penskalaan horizontal
• Di pgvector, fitur-fitur ini harus diimplementasikan sendiri, yang menyebabkan kompleksitas operasional dan beban pemeliharaan
• pgvectorscale dari Timescale menyediakan StreamingDiskANN, build indeks inkremental, peningkatan filtering, dan lain-lain, tetapi
  • tidak didukung di AWS RDS, serta ada beban tambahan untuk instalasi dan pengelolaan ekstensi

Biaya dan pertimbangan operasional

• Database vektor khusus memang layanan berbayar, tetapi jika mempertimbangkan overprovisioning infrastruktur Postgres, pengelolaan indeks, dan waktu engineering, secara nyata bisa jadi lebih murah
• Sebagai contoh, Turbopuffer mulai dari $64 per bulan dan menawarkan kesederhanaan operasional serta skalabilitas

Kesimpulan dan rekomendasi

• pgvector sangat bagus secara teknis, tetapi memiliki banyak keterbatasan di lingkungan produksi
• Hal-hal utama yang perlu dipertimbangkan saat membangun sistem produksi
  1. Kompleksitas pengelolaan indeks dan kebutuhan memori yang tinggi
  2. Keterbatasan query planner yang menyebabkan filtering tidak efisien
  3. Biaya indexing real-time dan penurunan kualitas
  4. Penyederhanaan berlebihan dalam materi blog
  5. Alasan keberadaan database vektor khusus dan efisiensinya
• Kesimpulannya, kompleksitas operasional lebih besar daripada kesederhanaan integrasi Postgres, dan bagi sebagian besar tim, menggunakan database vektor khusus adalah pilihan yang lebih realistis