--- title: "Vector Database untuk RAG: pgvector, Qdrant, atau Chroma?" description: "Langkah memilih vector database untuk chatbot RAG: bandingkan pgvector, Qdrant, Chroma, dan Milvus dari kemudahan, skala, filter, dan cara hosting." url: "https://nivelva.com/insight/vector-database-untuk-rag" category: "AI \u0026 Otomasi" tags: ["vector database","pgvector","qdrant","chroma","milvus","rag"] author: "Theresia Candiawan" published: "2026-11-07T12:01:00+07:00" updated: "2026-11-07T12:01:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # Vector Database untuk RAG: pgvector, Qdrant, atau Chroma? > **Jawaban singkat:** Untuk kebanyakan RAG skala kecil sampai menengah, PostgreSQL dengan pgvector sudah cukup, terutama bila kamu sudah memakai Postgres. Chroma praktis untuk prototipe, Qdrant kuat di filter dan pencarian hibrida, sedangkan Milvus dirancang untuk skala sangat besar di Kubernetes. 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](https://nivelva.com/insight/chatbot-ai-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](https://nivelva.com/insight/embedding-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](https://nivelva.com/insight/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](https://nivelva.com/insight/postgresql-vs-mysql). 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 | Aspek | pgvector | Qdrant | Chroma | Milvus | |:--|:--|:--|:--|:--| | Bentuk | Ekstensi PostgreSQL | Mesin pencarian vektor mandiri | Database embedding mandiri | Database vektor mandiri | | Lisensi | Open source | Apache 2.0 | Apache 2.0 | Apache 2.0 | | Kemudahan mulai | Mudah bila sudah memakai Postgres | Satu container Docker | Cukup `pip install`, bisa in-memory | Milvus Lite untuk coba, Standalone di Docker | | Filter metadata | Lewat SQL; filter setelah indeks, dibantu iterative scan | Indeks payload terintegrasi dengan HNSW | Filter metadata saat query | Pencarian dengan kondisi filter | | Pencarian hibrida | Digabung dengan full-text search Postgres | Vektor sparse dan BM25 | Dense, sparse, hibrida, full-text | BM25 dan hibrida multi-vektor | | Skala | Mengikuti kapasitas server Postgres | Dirancang untuk produksi, ada kuantisasi | Lokal, self-host, atau Chroma Cloud | Mode terdistribusi di Kubernetes | | Layanan terkelola | PostgreSQL terkelola yang mendukung pgvector | Qdrant Cloud | Chroma Cloud | Zilliz Cloud | 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. ## Pertanyaan yang sering diajukan ### Apakah RAG wajib memakai vector database khusus? Tidak. Yang dibutuhkan RAG adalah tempat menyimpan embedding dan mencarinya berdasarkan kemiripan. PostgreSQL dengan pgvector sudah bisa melakukannya, dan untuk banyak kasus perusahaan sudah memadai. ### Mana yang praktis untuk belajar atau prototipe? Chroma salah satunya, karena bisa dipasang dengan satu perintah pip dan dijalankan in-memory tanpa server. Setelah konsepnya jelas, kamu bisa menilai apakah perlu pindah ke pgvector, Qdrant, atau Milvus untuk produksi. ### Apakah pindah vector database nanti sulit? Relatif bisa dilakukan, karena embedding hanyalah deretan angka yang bisa diekspor. Yang lebih repot biasanya menyesuaikan kode filter dan query. Simpan teks asli dan metadata dengan rapi agar embedding bisa dibuat ulang bila perlu. ### Bagaimana mengamankan vector database? Perlakukan seperti database lain: aktifkan autentikasi, jangan buka port ke internet tanpa perlindungan, batasi hak akses, dan backup rutin. Isi embedding berasal dari dokumen perusahaan, jadi tingkat kerahasiaannya sama dengan dokumen aslinya. 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. ## Sumber - - - - - - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/vector-database-untuk-rag Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com