Sanggahan terhadap PGVector

 (alex-jacobs.com)
9 poin oleh GN⁺ 2025-11-04 | 5 komentar | Bagikan ke WhatsApp
  • 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
Iklan

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
Iklan

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

Bacaan terkait

5 komentar

 
kaydash 2025-11-05

Tetap saja, untuk kueri gabungan (embedding + SQL tradisional), tidak ada yang menandingi pg_vector.
 
yangeok 2025-11-04

Saya rasa agar ekosistem menjadi sehat, perlu juga ada banyak sanggahan terhadap narasi yang menganggap sesuatu sebagai solusi serbabisa.
 
ethanhur 2025-11-05

Saya setuju. Bagi organisasi yang sebelumnya sudah menggunakan Postgres dengan baik dan memulai VectorDB dengan data kecil, pgVector jelas merupakan pilihan yang sangat baik, tetapi ketika traffic—terutama write traffic—mulai meningkat, tampaknya masalah yang disebut penulis artikel asli menjadi bottleneck.
 
ndrgrd 2025-11-04

Benar. Karena tidak ada yang sempurna. Saya rasa tidak masalah jika alasannya sebatas "ada hal lain yang lebih mendesak", tetapi kita tidak boleh menerima anggapan bahwa "tingkat yang sekarang pun sudah cukup".
 
GN⁺ 2025-11-04
Opini Hacker News

  • Kami di Discourse sudah menggunakan pgvector di produksi pada ribuan basis data
    Ini dipakai untuk sebagian besar pageview, dan fitur Iterative Scans ditambahkan pada versi 0.8.0 untuk memperbaiki masalah pre/post filtering
    Untuk layanan tunggal, basis data vektor khusus mungkin lebih mudah, tetapi itu bukan solusi universal

    • Kami banyak menggunakan quantization
      Untuk penyimpanan kami memakai halfvec (float 16-bit), dan untuk indeks kami memakai bit (vektor biner) sehingga biaya penyimpanan dan performa sama-sama terjaga
    • Di perusahaan kami Halcyon, kami menangani triliunan embedding, dan Postgres tidak cocok untuk skala itu
      Kami memakai Vespa untuk menjalankan pencarian bergaya map-reduce di tingkat node
      Untuk melakukan hal serupa di Postgres, sepertinya diperlukan sharding dan logika aplikasi yang kompleks
      Reindexing atau denormalisasi metadata juga tampaknya pasti memakan waktu lama
      Meski begitu, basis data vektor juga bukan solusi universal, dan sistem seperti Vespa yang mendukung filtering relasional jauh lebih efisien
    • Banyak orang memakai pgvector di produksi
      Tetapi iterative scan bukan solusi mendasar, melainkan lebih seperti jalan keluar sementara
      Kita harus memahami parameter seperti ef_search dan max_search_tuples, dan planner belum sepenuhnya memahami model biaya untuk pencarian vektor yang difilter
      Pada akhirnya ini soal apakah Anda punya kapasitas untuk men-tuning query planner yang cerdas sendiri, atau lebih memilih memakai layanan yang memang khusus menangani itu
    • Ada juga pendekatan yang melakukan filtering saat penelusuran indeks berlangsung
      Metode yang dijelaskan dalam paper Microsoft diimplementasikan oleh pgvectorscale dari Timescale
      Pendekatan ini bisa lebih efisien dibanding pre/post filtering sederhana
    • Penasaran ini dipakai untuk kasus seperti apa. Apakah ini sistem pencarian hibrida yang menggabungkan kata kunci + vektor?

  • Di VectorChord, kami sudah menyelesaikan sebagian besar masalah pgvector yang disebutkan di blog tersebut
    Dengan IVF + quantization, kami mendukung update 15x lebih cepat dibanding HNSW di pgvector
    Dengan 16vCPU dan memori 32GB, kami bisa mengindeks 100 juta vektor berdimensi 768 dalam 20 menit
    Reindexing tanpa kehilangan data dimungkinkan dengan CREATE INDEX CONCURRENTLY
    Pre/post filtering dan pencarian hibrida berbasis BM25 juga didukung
    Untuk detailnya, lihat blog VectorChord

    • Jika memakai quantization dan IVF, saya penasaran berapa angka recall sebenarnya
    • Kami punya pelanggan yang menjalankan 3 miliar vektor dengan Postgres + VectorChord + sharding
      Studi kasusnya bisa dilihat di blog ini
    • Saya sempat mengevaluasi VectorChord, tetapi karena tidak didukung di RDS, saya harus menambah layanan terpisah sehingga akhirnya tidak jadi mengadopsinya

  • Pembuatan indeks memang memakan banyak memori, tetapi bisa dikendalikan dengan maintenance_work_mem
    Rebuild indeks bisa ditangani dengan REINDEX CONCURRENTLY, dan update HNSW secara konsep mirip dengan update B+tree
    Tulisan ini memberi kesan bahwa penulisnya tidak benar-benar membaca dokumentasi Postgres

    • Tetapi jika maintenance_work_mem dibatasi, proses indexing akan melambat
      B+tree hanya menyentuh halaman log H, sedangkan HNSW harus memodifikasi ribuan vektor
    • Indeks HNSW bisa berukuran ratusan GB hingga beberapa TB
      Untuk membangunnya ulang, kapasitas DB harus disediakan lebih dari dua kali lipat, dan ini juga memengaruhi workload lain
      REINDEX CONCURRENTLY pun memakan waktu lama
      Walaupun kompleksitas insert HNSW rendah, biaya konstannya besar sehingga dalam praktiknya tetap berat
    • Walaupun ada pengaturan seperti maintenance_work_mem, tetap berisiko jika RAM dalam skala GB dipakai berjam-jam saat sistem sedang berjalan
      REINDEX CONCURRENTLY juga memakai disk 2~3 kali lebih banyak dan berdampak pada performa
      Intinya bukan Postgres kurang fitur, melainkan kompleksitas operasionalnya yang besar
      Basis data vektor khusus menangani hal-hal seperti ini secara otomatis, jadi untuk tim kecil jauh lebih efisien

  • Fakta bahwa Turbopuffer mulai dari $64 per bulan menjelaskan mengapa pgvector populer
    Jika $64 terasa mahal, Anda bisa memakai pgvector; jika terasa murah, kemungkinan kasus penggunaan Anda sudah cukup kompleks sehingga basis data vektor khusus lebih cocok

  • Bahkan di antara pelanggan GCP, saya sering melihat pgvector HNSW dipakai di produksi
    Namun ini realistis hanya pada skala 0 hingga 10 juta vektor
    ETL, overhead operasional, dan masalah konsistensi perlu dipertimbangkan
    Jika Anda membutuhkan transaksi, pencarian hibrida, dan latensi rendah, AlloyDB + ScaNN adalah pilihan yang lebih baik
    (Sebagai catatan, saya membuat ScaNN di GCP dan saat ini memimpin AlloyDB Semantic Search)

    • Karena AlloyDB bukan open source, itu adalah produk yang menargetkan pasar yang berbeda

  • Prinsip dasar saya adalah YAGNI
    Kurangi jumlah layanan sebisa mungkin, dan tambahkan hal baru hanya ketika masalah benar-benar muncul
    Jika Postgres sudah cukup, pakai saja; kalau tidak, saat itu kita akan tahu persis apa yang dibutuhkan

    • Tetapi pendekatan seperti ini sering kali berbalik merugikan
      Hal-hal seperti penulisan vektor real-time dan penggabungan filter SQL dengan pencarian kemiripan terlihat sepele, padahal sebenarnya fitur esensial
      Saat skala membesar, batasan seperti ini akan terlihat sangat fatal
    • Sekali memilih basis data, menggantinya sulit, jadi sebaiknya berhati-hati sejak awal

  • Saat memakai model vector embedding, manfaatnya besar bahkan untuk dataset yang tidak terlalu besar
    Contohnya seperti pencarian dokumen atau pencarian informasi produk
    Saya ingin antarmuka seperti file system, di mana saat dokumen ditulis indeks otomatis diperbarui
    Karena itu layanan seperti Amazon S3 Vectors(tautan) terasa menarik
    Saya penasaran dengan pengalaman penggunaan nyatanya

  • Masalah-masalah yang disebutkan itu sebenarnya sudah teratasi, dan saya lebih suka memakai PGVector
    Jika Postgres bisa menggantikan Kafka dan menangani 100 ribu event per detik, maka dibanding basis data vektor khusus seperti Chroma, PGVector juga sangat mungkin sudah cukup
    Tautan referensi

    • Saya penasaran masalah mana saja yang secara spesifik sudah teratasi

  • Sebagian besar kasus penggunaan pgvector adalah dataset kecil seperti “chatbot berbasis dokumentasi teknis”
    Datanya tidak sering berubah, dan tidak ada multi-tenancy sehingga masalah filtering juga lebih sedikit
    Sementara itu Chroma mendukung SPANN, SPFresh, pencarian hibrida, dan merupakan open source Apache 2.0 sepenuhnya
    Dengan model harga berbasis pemakaian, biayanya juga bisa sekitar $1 per bulan

  • Redis Vector Sets yang saya kembangkan selama setahun terakhir menyelesaikan masalah-masalah ini
    Dengan implementasi HNSW langsung, update real-time dimungkinkan dan memori langsung dibebaskan saat data dihapus
    Mendukung kecepatan insert puluhan ribu ops/sec dan pencarian 50 ribu ops/sec
    Secara default mendukung quantization sehingga efisiensi memorinya juga tinggi
    Semua detailnya dirangkum dalam dokumen README
    Saat ini fitur replikasinya juga sudah selesai diuji sepenuhnya