Vector Database untuk RAG: pgvector, Qdrant, atau Chroma?

Sedang membangun chatbot yang menjawab dari dokumen perusahaan dan bingung harus menyimpan embedding di mana? Jawaban singkatnya: bila kamu sudah memakai PostgreSQL dan jumlah dokumennya belum raksasa, mulailah dengan pgvector. Pindah ke database vektor khusus seperti Qdrant atau Milvus baru masuk akal ketika kebutuhan filter, skala, atau kecepatanmu sudah melampaui yang nyaman ditangani Postgres.

Vector database menyimpan embedding, yaitu deretan angka yang mewakili makna sebuah potongan teks, lalu mencari potongan yang maknanya paling dekat dengan pertanyaan pengguna. Di sistem RAG, inilah komponen yang menentukan dokumen mana yang dibaca model sebelum menjawab. Gambaran besar cara kerja RAG ada di chatbot AI dari dokumen perusahaan. Artikel ini membahas cara memilih tempat penyimpanannya, langkah demi langkah.

Langkah memilih vector database

Langkah 1: hitung ukuran data dan pertumbuhannya

Mulailah dengan angka kasar: berapa dokumen yang akan dimasukkan, kira-kira dipotong menjadi berapa bagian (chunk), dan seberapa cepat bertambah. Ribuan sampai ratusan ribu potongan dari SOP, katalog, dan FAQ adalah ukuran yang umum untuk perusahaan menengah. Jumlah sebesar itu masih nyaman untuk semua pilihan di artikel ini.

Perhatikan juga dimensi embedding dari model yang kamu pakai, karena memengaruhi ukuran penyimpanan dan batas indeks. Contohnya, dokumentasi pgvector menyebut indeks HNSW dan IVFFlat untuk tipe vector mendukung hingga 2.000 dimensi, dan tipe halfvec hingga 4.000 dimensi. Cara memotong dokumen dan memilih model embedding dibahas di embedding dan chunking RAG.

Langkah 2: tentukan kebutuhan filter

Hampir semua RAG di perusahaan butuh filter. Contohnya: hanya cari di dokumen divisi tertentu, hanya dokumen yang masih berlaku, atau hanya dokumen yang boleh dilihat pengguna yang sedang bertanya. Filter hak akses ini sangat penting agar chatbot tidak membocorkan dokumen ke orang yang salah.

Di sinilah perbedaan antar database mulai terasa. Dokumentasi pgvector menjelaskan bahwa pada indeks perkiraan, filter diterapkan setelah pencarian indeks, sehingga filter yang sangat selektif bisa mengembalikan hasil lebih sedikit dari yang diminta. Sejak versi 0.8.0, pgvector menyediakan iterative index scan untuk mengatasinya, dan untuk nilai filter yang sedikit bisa memakai partial index. Qdrant, menurut dokumentasinya, memperluas graf HNSW dengan indeks payload sehingga filter diterapkan selama pencarian berlangsung.

Langkah 3: putuskan apakah butuh pencarian hibrida

Pencarian vektor kuat untuk makna, tetapi kadang lemah untuk kata yang persis sama, seperti kode produk, nomor pasal, atau nama orang. Pencarian hibrida menggabungkan pencarian makna dengan pencarian kata kunci.

Qdrant mendukung vektor sparse dan pencarian BM25 untuk kebutuhan ini. Chroma menyebut dukungan pencarian dense, sparse, dan hibrida, serta pencarian teks penuh dan regex. Milvus menyediakan pencarian teks penuh berbasis BM25. Di PostgreSQL, pencarian kata kunci bisa memakai fitur full-text search bawaan Postgres, lalu digabungkan dengan hasil pgvector di sisi aplikasi atau lewat query.

Langkah 4: pilih model hosting

Ada tiga pola besar. Pertama, menumpang di database yang sudah ada, misalnya menambahkan ekstensi pgvector ke PostgreSQL. Kedua, menjalankan sendiri database vektor khusus di server atau container. Ketiga, memakai layanan terkelola dari penyedianya.

Keempat proyek yang dibahas di sini open source: pgvector, Qdrant (Apache 2.0, ditulis dengan Rust), Chroma (Apache 2.0), dan Milvus (Apache 2.0). Qdrant menawarkan opsi cloud terkelola, hybrid, private, dan open source. Chroma punya Chroma Cloud. Milvus punya versi terkelola dari Zilliz. Bila kamu tidak ingin merawat server sendiri, PostgreSQL terkelola yang mendukung pgvector juga pilihan yang praktis; konsepnya dibahas di apa itu cloud database.

Langkah 5: coba dengan data asli

Jangan memilih hanya dari tabel fitur. Ambil sebagian dokumen nyata dan 30 sampai 50 pertanyaan yang biasa ditanyakan, lalu bandingkan hasil pencarian di dua kandidat. Lihat apakah potongan yang benar muncul di urutan atas, seberapa cepat hasilnya, dan apakah filter bekerja sesuai harapan.

Untuk prototipe, Chroma termasuk yang cepat dicoba: cukup pip install chromadb, dan klien in-memory bisa langsung dipakai tanpa server. Qdrant bisa dijalankan dengan satu perintah Docker, tetapi perlu dicatat bahwa repositori resminya mengingatkan perintah default itu berjalan tanpa autentikasi, jadi jangan dibuka ke internet sebelum diamankan.

Kapan PostgreSQL biasa sudah cukup?

Pertanyaan ini paling sering muncul, dan jawabannya lebih sering "cukup" daripada yang dibayangkan.

Postgres dengan pgvector masuk akal bila kamu sudah memakai PostgreSQL untuk aplikasi, ingin metadata dokumen dan embedding berada di tempat yang sama, butuh transaksi dan backup yang sudah terbiasa kamu kelola, dan jumlah data masih dalam skala yang bisa ditangani satu server database. Keuntungan terbesarnya justru di luar fitur vektor: satu sistem untuk dirawat, satu cara backup, dan hak akses yang sudah ada. Bila kamu masih menimbang engine database secara umum, perbandingannya ada di PostgreSQL vs MySQL vs MariaDB.

Database vektor khusus mulai layak dipertimbangkan bila filter yang rumit menjadi lambat atau hasilnya kurang lengkap, data tumbuh ke skala yang membuat satu server Postgres kewalahan, kamu butuh fitur seperti kuantisasi untuk menekan pemakaian memori, atau tim ingin memisahkan beban pencarian dari database transaksi.

Ringkasan perbandingan

Versi pgvector yang tercantum di petunjuk instalasi resminya per 4 November 2026 adalah 0.8.7, dengan dukungan PostgreSQL 13 ke atas. Fitur proyek open source berubah cepat, jadi cek dokumentasi resmi sebelum memutuskan.

Sebelum memutuskan, cek daftar singkat ini:

• Sudah tahu perkiraan jumlah potongan dokumen dan dimensi embedding.
• Sudah menulis kebutuhan filter, terutama filter hak akses.
• Sudah memutuskan perlu atau tidak pencarian kata kunci.
• Sudah memilih antara menumpang di Postgres, self-host, atau layanan terkelola.
• Sudah menguji dua kandidat dengan dokumen dan pertanyaan asli.
• Sudah menyiapkan autentikasi dan backup sebelum tayang.