pgvector vs Qdrant vs Chroma vs Milvus: Memilih Vector Database untuk Aplikasi AI

Kalau kamu membangun aplikasi RAG, fitur pencarian semantik, atau rekomendasi berbasis AI, cepat atau lambat kamu akan berhadapan dengan satu pertanyaan: data vektor ini disimpan di mana? Embedding yang dihasilkan model seperti text-embedding-3-large atau model open-source sejenis bukanlah data biasa — ia berupa larik angka berdimensi ratusan hingga ribuan yang hanya berguna kalau bisa dicari berdasarkan kemiripan, bukan kecocokan persis.

Di sinilah vector database masuk. Artikel ini membandingkan empat pilihan paling populer di 2026 — pgvector, Qdrant, Chroma, dan Milvus — dari sisi arsitektur, kemudahan pakai, performa, dan skenario yang cocok untuk masing-masing, supaya kamu bisa memilih dengan kepala dingin, bukan ikut-ikutan tren.

Ringkasan:

• Vector database menyimpan embedding dan menjawab query "cari yang paling mirip", fondasi RAG dan pencarian semantik.
• pgvector paling praktis kalau kamu sudah memakai PostgreSQL: satu layanan lebih sedikit untuk diurus.
• Qdrant adalah pilihan seimbang untuk produksi self-hosted: cepat, open-source, dan punya hybrid search.
• Chroma paling cepat untuk prototipe dan eksperimen lokal.
• Milvus dirancang untuk skala miliaran vektor dengan arsitektur terdistribusi.
• Untuk sebagian besar aplikasi RAG, keputusan terbaik adalah mulai dari yang paling sederhana, lalu pindah saat terukur mentok.

Apa itu vector database?

Vector database adalah sistem penyimpanan yang dirancang khusus untuk menyimpan embedding — representasi numerik dari teks, gambar, atau audio dalam ruang berdimensi tinggi — dan untuk menjawab query kemiripan (similarity search) dengan cepat. Alih-alih mencari baris yang sama persis seperti WHERE nama = 'budi', kamu bertanya "vektor mana yang paling dekat dengan vektor query ini?" dan database mengembalikan tetangga terdekatnya beserta skor jaraknya.

Cara kerjanya bertumpu pada dua hal: model embedding yang mengubah konten menjadi vektor, dan index ANN (Approximate Nearest Neighbor) seperti HNSW atau IVF yang membuat pencarian di jutaan vektor tetap cepat tanpa membandingkan satu per satu. Tanpa index ANN, pencarian kemiripan pada 10 juta vektor berdimensi 768 akan terlalu lambat untuk aplikasi interaktif.

Kalau kamu belum familier dengan konsep RAG secara menyeluruh, baca dulu panduan lengkap RAG — artikel ini fokus pada satu komponennya: tempat embedding itu tinggal.

Kenapa pilihan vector database itu penting

Memilih vector database yang salah jarang terasa di minggu pertama. Ia terasa di bulan ketiga, saat data sudah 50 juta vektor, query mulai lambat, dan migrasi terasa seperti operasi jantung. Tiga alasan kenapa keputusan ini layak dipikirkan matang-matang:

Biaya operasional jangka panjang

Setiap layanan baru berarti satu hal lagi untuk di-backup, di-monitor, di-update, dan di-scale. pgvector menarik justru karena ia bukan layanan baru: ia hidup di dalam PostgreSQL yang kemungkinan sudah kamu operasikan. Sebaliknya, Milvus yang terdistribusi memberi skala besar tapi menuntut cluster dengan beberapa komponen (etcd, MinIO, dan node-node worker).

Karakter query menentukan pemenang

Tidak semua vector database unggul di hal yang sama. Ada yang kuat di filtering metadata (misalnya "cari dokumen mirip TAPI hanya yang kategorinya support dan dibuat tahun ini"), ada yang unggul di hybrid search (menggabungkan skor vektor dengan skor kata kunci BM25), dan ada yang unggul di throughput mentah. Kenali pola query aplikasimu sebelum memilih.

Lock-in itu nyata, tapi bisa dikelola

Migrasi antar vector database memang merepotkan karena format index dan API berbeda-beda. Tapi kabar baiknya: data mentahnya — vektor + metadata — selalu bisa diekspor ulang. Selama kamu menyimpan embedding asli dan skrip ingest yang reproducible, pindah database berarti re-index, bukan bencana.

Cara kerja vector database: dari teks ke pencarian mirip

Alurnya selalu sama, apa pun databasenya:

1. Chunking — dokumen panjang dipotong menjadi potongan kecil (misalnya 300–500 token) supaya setiap embedding mewakili satu gagasan yang fokus.
2. Embedding — setiap chunk dikirim ke model embedding dan menjadi vektor, misalnya 768 atau 1536 angka desimal.
3. Indexing — vektor-vektor itu dimasukkan ke index ANN (umumnya HNSW) agar pencarian tetangga terdekat berjalan dalam milidetik, bukan detik.
4. Query — saat pengguna bertanya, pertanyaannya diubah menjadi vektor dengan model yang sama, lalu database mencari vektor-vektor terdekat, sering digabung dengan filter metadata.
5. Retrieval — chunk-chunk terbaik dikembalikan dan biasanya diteruskan ke LLM sebagai konteks — inilah inti pola RAG.

Dua metrik jarak yang paling umum adalah cosine similarity (sudut antara dua vektor, bagus untuk teks karena tidak peduli panjang vektor) dan Euclidean/L2 distance (jarak lurus). Kebanyakan model embedding modern dinormalisasi sehingga keduanya memberi urutan hasil yang sama — pilih cosine sebagai default yang aman.

Satu hal yang sering disalahpahami: vector database tidak menggantikan database relasional. Ia melengkapi. Data transaksional, relasi antar entitas, dan agregasi tetap lebih nyaman di PostgreSQL. Vector database hanya menangani satu pekerjaan — pencarian kemiripan — tapi menanganinya dengan sangat baik.

pgvector: ekstensi PostgreSQL yang paling praktis

pgvector bukan database. Ia adalah ekstensi open-source untuk PostgreSQL yang menambahkan tipe kolom vector, operator jarak, dan index ANN (HNSW dan IVFFlat). Kamu mengaktifkannya dengan satu baris SQL, dan tiba-tiba database yang sudah kamu jalankan bisa melakukan similarity search.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
  id         bigserial PRIMARY KEY,
  content    text NOT NULL,
  category   text,
  embedding  vector(1536)   -- dimensi mengikuti model embedding
);

-- Index HNSW untuk pencarian cepat
CREATE INDEX ON documents
  USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

-- Query: 10 dokumen paling mirip, difilter kategori
SELECT id, content
FROM documents
WHERE category = 'support'
ORDER BY embedding <=> '[0.12, -0.03, ...]'::vector
LIMIT 10;

Operator <=> adalah cosine distance, <-> adalah L2 distance, dan <#> adalah negative inner product. Yang membuat pgvector istimewa terlihat di query di atas: klausa WHERE category = 'support' adalah filter relasional biasa yang memakai B-tree index biasa, berjalan di query planner yang sama dengan pencarian vektornya. Filtering — titik lemah banyak mesin vektor khusus — justru kekuatan Postgres.

Kelebihan: tidak ada layanan baru (backup, monitoring, dan transaksi ACID ikut gratis), SQL penuh untuk join dan filter kompleks, ekosistem Postgres yang matang (replikasi, connection pooling, managed service seperti Supabase atau RDS).

Kekurangan: index HNSW yang besar butuh waktu build lama dan RAM besar; performa query mentah di bawah mesin khusus berbahasa Rust/C++; tidak ada hybrid search bawaan (harus dirakit manual dengan full-text search Postgres); skala praktisnya umumnya di bawah 10–100 juta vektor tergantung hardware.

Cocok untuk: tim yang sudah memakai PostgreSQL, aplikasi RAG skala kecil-menengah, dan siapa pun yang mengutamakan kesederhanaan operasional. Aturan praktis dari banyak praktisi: kalau datamu di bawah 10 juta vektor dan Postgres sudah ada di stack, mulai dari pgvector.

Qdrant: mesin vektor seimbang untuk produksi

Qdrant adalah vector search engine open-source yang ditulis dengan Rust, dirancang sejak awal untuk pencarian kemiripan yang cepat dan akurat. Ia bisa dijalankan self-hosted lewat satu container Docker, atau dipakai sebagai layanan managed (Qdrant Cloud).

from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams

client = QdrantClient("localhost", port=6333)

client.create_collection(
    collection_name="docs",
    vectors_config=VectorParams(size=768, distance=Distance.COSINE),
)

# Simpan satu dokumen beserta metadata (payload)
client.upsert(
    collection_name="docs",
    points=[{
        "id": 1,
        "vector": [0.05, 0.61, 0.76, ...],
        "payload": {"category": "support", "year": 2026},
    }],
)

# Cari + filter payload dalam satu query
hits = client.query_points(
    collection_name="docs",
    query=[0.05, 0.61, 0.76, ...],
    query_filter={"must": [{"key": "category", "match": {"value": "support"}}]},
    limit=10,
).points

Fitur yang membedakannya: hybrid search bawaan (menggabungkan dense vector, sparse vector/BM25, dalam satu query), payload filtering yang kaya (filter pada metadata dengan index khusus), dan quantization (kompresi vektor seperti scalar/product quantization untuk menghemat RAM besar-besaran). API-nya bersih, ada dashboard web bawaan, dan klien resmi tersedia untuk Python, JavaScript/TypeScript, Rust, dan Go.

Kelebihan: performa query sangat baik untuk kelasnya, hybrid search tanpa rakitan manual, filtering metadata yang matang, satu binary/container yang mudah dioperasikan, lisensi Apache 2.0.

Kekurangan: tetap satu layanan tambahan untuk dioperasikan; API REST-nya cukup verbose untuk prototipe super cepat; skala horizontal butuh mode cluster yang lebih serius disiapkan dibanding Milvus.

Cocok untuk: aplikasi produksi self-hosted dengan 10 juta hingga ratusan juta vektor, RAG yang butuh hybrid search (kombinasi semantik + kata kunci terbukti menaikkan kualitas retrieval), dan tim yang mau open-source tanpa ketergantungan cloud.

Chroma: paling cepat untuk prototipe

Chroma adalah open-source embedding database yang dirancang dengan satu obsesi: membuat developer bisa mulai dalam hitungan menit. Instalasi semudah pip install chromadb, dan kamu bisa berjalan sepenuhnya embedded tanpa server sama sekali — cocok untuk notebook, skrip eksperimen, dan MVP.

import chromadb

client = chromadb.Client()  # mode embedded, tanpa server
collection = client.create_collection(name="docs")

collection.add(
    ids=["doc-1", "doc-2"],
    documents=["Panduan instalasi...", "Cara reset password..."],
    metadatas=[{"category": "support"}, {"category": "support"}],
)

results = collection.query(
    query_texts=["bagaimana cara instalasi?"],
    n_results=5,
    where={"category": "support"},
)

Chroma juga punya embedding function bawaan, jadi kamu bahkan tidak perlu memanggil model embedding secara manual di tahap prototipe — cukup serahkan teks, ia yang mengurus sisanya. Ada mode server/client untuk dipakai tim, dan Chroma Cloud untuk yang tidak mau mengurus infrastruktur.

Kelebihan: waktu dari nol ke query pertama paling singkat di antara semuanya, API sangat Pythonic, embedded mode tanpa dependensi server, dokumentasi yang ramah pemula (dokumentasi resmi Chroma).

Kekurangan: bukan pilihan utama untuk produksi skala besar — skalabilitas horizontal dan multi-tenancy lanjutan bukan kekuatannya; performa query di bawah Qdrant/Milvus pada data besar; fitur enterprise (seperti yang ada di Chroma Cloud) butuh layanan managed.

Cocok untuk: prototipe, demo, hackathon, eksperimen RAG, dan aplikasi kecil yang datanya di bawah beberapa juta vektor. Pola yang sehat: prototipe di Chroma, naik kelas ke Qdrant atau pgvector saat masuk produksi.

Milvus: untuk skala miliaran vektor

Milvus adalah vector database terdistribusi open-source (Apache 2.0) yang dibangun untuk satu tujuan: skala raksasa. Arsitekturnya memisahkan komponen penyimpanan, komputasi, dan koordinasi, sehingga bisa menangani miliaran vektor dengan replikasi dan sharding — wilayah yang tidak disentuh tiga kandidat lain.

from pymilvus import MilvusClient

client = MilvusClient(uri="http://localhost:19530")
client.create_collection(
    collection_name="docs",
    dimension=768,
    metric_type="COSINE",
)

client.insert(
    collection_name="docs",
    data=[{"id": 1, "vector": [0.05, 0.61, ...], "category": "support"}],
)

results = client.search(
    collection_name="docs",
    data=[[0.05, 0.61, ...]],
    filter="category == 'support'",
    limit=10,
)

Milvus mendukung banyak tipe index (HNSW, IVF, GPU-accelerated), punya konsol manajemen Attu, dan tersedia sebagai layanan managed lewat Zilliz Cloud. Dokumentasi Milvus cukup lengkap untuk menyiapkan cluster.

Kelebihan: skala horizontal terbaik di kelas open-source, kaya pilihan index termasuk akselerasi GPU, ekosistem matang untuk enterprise, multi-tenancy yang serius.

Kekurangan: footprint operasional paling berat — butuh etcd, MinIO/object storage, dan beberapa layanan pendukung; overkill total untuk data di bawah puluhan juta vektor; kurva belajar paling curam.

Cocok untuk: perusahaan dengan ratusan juta hingga miliaran vektor, kebutuhan SLA dan multi-tenancy yang ketat, atau tim platform yang memang sudah terbiasa mengoperasikan sistem terdistribusi.

Perbandingan head-to-head

Tabel berikut merangkum posisi masing-masing berdasarkan dokumentasi resmi dan perbandingan komunitas (termasuk benchmark terbuka VectorDBBench). Angka latensi adalah perkiraan kasar untuk 1 juta vektor 768 dimensi — hardware dan tuning mengubah segalanya, jadi perlakukan sebagai gambaran urutan besar, bukan janji.

Pola yang muncul jelas: semakin ke kanan, semakin besar skala yang dilayani — dan semakin besar beban operasionalnya. Tidak ada yang gratis.

Studi kasus: memilih untuk tiga skenario nyata

Teori tanpa skenario membuat perbandingan terasa abstrak. Berikut tiga situasi yang sering muncul, beserta pilihan yang masuk akal dan alasannya.

Skenario 1: chatbot dokumentasi untuk startup SaaS (200 ribu dokumen)

Stack sudah memakai PostgreSQL di Supabase. Volume kecil, tim backend tiga orang, tidak ada yang mau begadang mengurus cluster. Pilihan: pgvector. Aktifkan ekstensi, tambah kolom vector, buat index HNSW, selesai dalam satu sore. Filtering kategori dan tenant via WHERE biasa. Kalau dua tahun lagi datanya 50 juta vektor dan query melambat, migrasi ke Qdrant masih terbuka — embedding dan skrip ingest sudah ada.

Skenario 2: pencarian produk e-commerce (40 juta produk, butuh hybrid search)

Query seperti "sepatu lari merah murah" butuh gabungan makna semantik ("sepatu lari") dan kata kunci persis ("merah"). Di sinilah hybrid search bawaan bersinar. Pilihan: Qdrant. Satu container, quantization untuk menekan RAM, payload filter untuk kategori/harga/stok. Tim DevOps kecil masih sanggup mengoperasikannya.

Skenario 3: platform analitik dengan 2 miliar event embeddings

Skala ini bukan wilayah eksperimen — butuh sharding, replikasi, dan multi-tenancy yang serius. Pilihan: Milvus (atau Zilliz Cloud kalau tim tidak mau mengurus cluster). Keputusan ini mahal secara operasional, tapi di skala ini tidak ada jalan pintas yang jujur.

Perhatikan polanya: jawabannya selalu dimulai dari skala data dan kapasitas operasional tim, bukan dari "mana yang paling canggih".

Kesalahan umum saat memilih vector database

Setelah melihat banyak tim salah langkah, lima kesalahan ini paling sering berulang:

1. Memilih berdasarkan benchmark mentah. Angka QPS tertinggi tidak berarti apa-apa kalau query aslimu selalu memakai filter metadata yang kompleks. Uji dengan workload sendiri, bukan workload orang lain.
2. Mengabaikan filtering sejak hari pertama. Hampir semua RAG produksi memfilter berdasarkan tenant, kategori, atau tanggal. Pastikan kandidatmu menanganinya dengan baik — di sinilah pgvector dan Qdrant unggul.
3. Lupa mengunci model embedding. Mengganti model embedding berarti seluruh vektor harus dihitung ulang dan di-index ulang. Pilih model, kunci versinya, dan catat dimensinya di skema.
4. Tidak menyiapkan strategi re-index. Index HNSW perlu di-tune (m, ef_construction, ef_search) dan dibangun ulang saat data berubah drastis. Alokasikan maintenance_work_mem yang cukup saat build index besar di pgvector.
5. Over-engineering di hari pertama. Menjalankan cluster Milvus untuk 500 ribu vektor adalah pemborosan yang nyata — biaya server, waktu DevOps, dan kompleksitas debugging. Mulai sederhana, ukur, naik kelas saat data membuktikan kamu butuh.

Best practice: checklist sebelum produksi

• Kunci dimensi dan model embedding di awal; dokumentasikan di README repo.
• Pisahkan koleksi per tenant atau gunakan filter tenant yang terindex — jangan mengandalkan filter tanpa index di data besar.
• Ukur recall, bukan cuma latensi. Naikkan ef_search (atau parameter setara) sampai recall@k memenuhi target kualitas, lalu optimalkan kecepatan.
• Siapkan skrip re-index idempoten sejak awal — kamu akan membutuhkannya lebih cepat dari dugaan.
• Monitor ukuran index dan RAM, terutama untuk HNSW yang rakus memori.
• Backup data mentah (vektor + metadata), bukan cuma snapshot index — index bisa dibangun ulang, data mentah tidak.
• Untuk topik terkait seperti desain REST API di sekitar layanan pencarianmu, perlakukan endpoint search seperti API produk: versioning, rate limit, dan observability.

FAQ

Apakah saya butuh vector database khusus, atau cukup PostgreSQL dengan pgvector?

Untuk sebagian besar aplikasi — RAG internal, pencarian dokumen, rekomendasi skala kecil-menengah — pgvector cukup. Ia memberi ACID, join, dan filter SQL dalam satu sistem yang sudah kamu kenal. Pindah ke mesin khusus saat pengukuran menunjukkan pgvector mentok: biasanya di atas puluhan juta vektor atau saat butuh hybrid search yang serius.

Apa itu HNSW dan kenapa semua vector database memakainya?

HNSW (Hierarchical Navigable Small World) adalah struktur index berbasis graf yang membuat pencarian tetangga terdekat berjalan dalam waktu logaritmik. Ia membangun lapisan-lapisan graf di mana pencarian dimulai dari lapisan jarang lalu menyempit ke lapisan padat. Hampir semua vector database modern mendukungnya karena ia memberi keseimbangan terbaik antara kecepatan, recall, dan ukuran memori.

Bisakah satu aplikasi memakai dua vector database sekaligus?

Bisa, dan kadang itu desain yang tepat. Pola umum: data panas (hot) di mesin cepat seperti Qdrant, data dingin di penyimpanan murah, atau prototipe di Chroma lalu produksi di pgvector. Kuncinya adalah lapisan abstraksi tipis di kode — jangan biarkan query mentah ke database spesifik tersebar di seluruh codebase.

Bagaimana cara migrasi dari Chroma ke Qdrant atau pgvector?

Ekspor semua vektor beserta metadata dan ID-nya, lalu tulis ulang ke database tujuan dan bangun ulang indexnya. Karena data mentah bersifat portabel, migrasi adalah masalah waktu re-index, bukan kehilangan data. Simpan skrip ingest yang deterministik sejak hari pertama supaya proses ini bisa diulang kapan saja.

Apakah vector database menggantikan Elasticsearch?

Tidak sepenuhnya. Elasticsearch (dan OpenSearch) unggul di pencarian kata kunci, agregasi, dan full-text dengan relevansi yang matang. Vector database unggul di pencarian semantik. Untuk RAG berkualitas tinggi, kombinasi keduanya — hybrid search — sering memberi hasil terbaik, dan beberapa mesin seperti Qdrant sudah menyediakannya dalam satu query.

Kesimpulan

Tidak ada vector database yang terbaik secara absolut — yang ada hanyalah yang paling cocok untuk skala, query, dan kapasitas operasionalmu. pgvector menang di kesederhanaan kalau PostgreSQL sudah ada. Qdrant adalah paket produksi self-hosted yang paling seimbang. Chroma membuatmu bergerak paling cepat di tahap eksperimen. Milvus adalah jawaban jujur untuk skala miliaran vektor.

Mulai dari yang paling sederhana yang memenuhi kebutuhan hari ini, ukur dengan workload aslimu, dan naik kelas saat data — bukan hype — menyuruhmu pindah. Kalau kamu membangun RAG di atasnya, panduan lengkap RAG dan panduan MCP untuk AI agent adalah bacaan lanjutan yang pas.

Punya pengalaman memakai salah satunya di produksi? Ceritakan di kolom komentar — pengalaman nyata jauh lebih berharga daripada benchmark sintetis.