Qdrant vs Chroma vs pgvector: Memilih Vector DB yang Tepat untuk RAG Self-Hosted

Qdrant vs Chroma vs pgvector: Memilih Vector DB yang Tepat untuk RAG Self-Hosted

Keputusan Qdrant vs Chroma vs pgvector bermuara pada tiga pilihan utama: kecepatan khusus tujuan, kesederhanaan prototipe, atau tetap berada dalam ekosistem Postgres. Setiap pendekatan berfungsi dengan baik; pertanyaannya adalah trade-off mana yang paling sesuai dengan pipeline RAG Anda.

Ringkasan Cepat: Database Vektor Mana yang Harus Anda Pilih?

Pilih Qdrant jika Anda membutuhkan pencarian vektor tingkat produksi dengan pemfilteran lanjutan, multi-tenancy, dan tidak keberatan menjalankan layanan terpisah.

Pilih Chroma jika Anda sedang membuat prototipe, menginginkan pengembangan lokal tanpa konfigurasi, atau perlu beralih dari ide ke RAG yang berfungsi dalam waktu kurang dari satu jam.

Pilih pgvector (+ pgvectorscale) jika Anda sudah menjalankan PostgreSQL dan menginginkan pencarian vektor tanpa menambah infrastruktur, terutama sekarang karena indeks StreamingDiskANN dari pgvectorscale telah menutup kesenjangan kinerja.

Jika Anda membangun aplikasi RAG dari awal, sisa artikel ini akan membantu Anda memilih fondasi yang tepat.

Kinerja: Seberapa Cepat Masing-Masing Database?

Kinerja menjadi penting sekali Anda melampaui beberapa ribu dokumen. Di sinilah ketiga opsi ini berbeda secara signifikan.

Qdrant

Qdrant dibangun dari dasar untuk pencarian vektor. Implementasi Rust-nya dan indeks HNSW kustom memberikan latensi rendah yang konsisten, tolok ukur menunjukkan latensi kueri sekitar 94ms bahkan di bawah beban konkuren. Ini mendukung kuantisasi skalar, biner, dan produk untuk mengompresi vektor dan mempercepat pencarian sambil mempertahankan recall di atas 95%.

Di mana Qdrant benar-benar unggul adalah dalam pencarian terfilter. Berbeda dengan database yang menemukan tetangga terdekat terlebih dahulu lalu memfilter, HNSW yang dapat difilter milik Qdrant menghormati batasan metadata selama traversing graf. Artinya, Anda tidak kehilangan recall saat menggabungkan pencarian vektor dengan filter seperti category = "technical" atau date > 2025-01-01.

Chroma

Rilis 1.0 Chroma menulis ulang intinya dalam Rust, memberikan penulisan dan kueri 3-5x lebih cepat dibandingkan implementasi Python aslinya. Pembaruan lanjutan pada Agustus 2025 menambahkan pengkodean vektor base64 untuk peningkatan throughput sebesar 70% lagi.

Untuk dataset di bawah satu juta vektor, Chroma benar-benar cepat. Ia berjalan tertanam dalam proses Python Anda tanpa overhead jaringan, yang membuat iterasi lokal menjadi responsif. Namun, ini adalah database satu node; tidak ada sharding atau replikasi bawaan.

pgvector + pgvectorscale

Ini adalah kuda hitam. pgvector vanilla dengan HNSW 5.250x lebih cepat daripada scan sekuensial, dan pgvector 0.8.0 menambahkan pemindaian indeks iteratif untuk mengatasi masalah overfiltering yang menghantui versi sebelumnya.

Namun, cerita sebenarnya adalah pgvectorscale. Ekstensi dari Timescale ini menambahkan indeks StreamingDiskANN, yang terinspirasi oleh penelitian DiskANN Microsoft, yang menyimpan indeks di disk alih-alih RAM. Pada tolok ukur 50 juta embedding Cohere (768 dimensi), pgvectorscale mencapai 471 QPS dengan recall 99%. Itu adalah throughput 11,4x lebih tinggi daripada 41 QPS milik Qdrant pada tingkat recall yang sama, dan latensi p95 28x lebih rendah daripada indeks yang dioptimalkan penyimpanan milik Pinecone.

Masalahnya? Tolok ukur ini menggunakan instance EC2 yang kuat. Hasil Anda mungkin bervariasi tergantung perangkat keras. Namun, trajektorinya jelas: PostgreSQL bukan lagi opsi "cukup bagus" untuk pencarian vektor, melainkan benar-benar kompetitif.

Kesimpulan: pgvector + pgvectorscale menang dalam angka tolok ukur mentah. Qdrant menang dalam kinerja pencarian terfilter. Chroma cukup cepat untuk prototipe tetapi tidak dibangun untuk skala besar.

Pengaturan dan Pengalaman Developer

Seberapa cepat Anda bisa beralih dari nol ke vektor?

Qdrant: Docker dan Go

Qdrant memerlukan kontainernya sendiri:

docker run -p 6333:6333 -v $(pwd)/qdrant_storage:/qdrant/storage qdrant/qdrant

Kemudian sisipkan vektor melalui REST API atau salah satu SDK resmi (Python, Rust, Go, TypeScript):

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

client = QdrantClient(url="http://localhost:6333")
client.create_collection(
    collection_name="documents",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)

Dasbor Qdrant di localhost:6333/dashboard adalah fitur yang menarik; Anda dapat menjelajahi koleksi, menjalankan kueri, dan memeriksa payload secara visual. Jalur dari pengembangan ke produksi bersih: pengaturan Docker lokal Anda bekerja secara identik di server produksi atau Qdrant Cloud.

Chroma: pip Install dan Selesai

Chroma memenangkan perlombaan kesederhanaan dengan margin lebar:

import chromadb

client = chromadb.Client()  # In-memory, zero config
collection = client.create_collection("documents")
collection.add(
    documents=["Your RAG document here"],
    ids=["doc1"]
)

Tanpa Docker. Tanpa server. Bahkan menangani pembuatan embedding secara otomatis jika Anda tidak menyediakan vektor. Untuk prototipe RAG, Anda bisa beralih dari pip install chromadb ke pencarian yang berfungsi dalam kurang dari 10 baris kode.

Saat Anda siap untuk persistensi, beralihlah ke chromadb.PersistentClient(path="./chroma_data"). Untuk akses multi-proses atau jaringan, Chroma memiliki mode server, tetapi pada titik itu, Anda mulai kehilangan keunggulan kesederhanaannya.

pgvector: SQL Sepenuhnya

Jika Postgres sudah ada dalam stack Anda, pgvector hanya butuh satu baris:

CREATE EXTENSION vector;

CREATE TABLE documents (
  id SERIAL PRIMARY KEY,
  content TEXT,
  embedding vector(1536)
);

CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

Semuanya menggunakan SQL. Embedding Anda hidup berdampingan dengan data aplikasi Anda dalam transaksi yang sama. Tidak ada pipeline sinkronisasi, tidak ada kredensial terpisah, tidak ada layanan tambahan untuk dipantau. Jika Anda sudah menjalankan PostgreSQL di produksi, ini adalah jalur dengan hambatan terkecil.

Menambahkan pgvectorscale di atasnya cukup mudah jika Anda menggunakan gambar Docker Timescale atau penyedia Postgres terkelola yang mendukungnya:

CREATE EXTENSION vectorscale;
CREATE INDEX ON documents USING diskann (embedding);

Kekurangannya? SQL tidak seergonomis DSL pemfilteran payload Qdrant atau API Pythonic Chroma. Dan Anda perlu mengelola pipeline embedding sendiri, pgvector tidak menghasilkan embedding untuk Anda.

Kesimpulan: Chroma menang untuk prototipe tercepat. pgvector menang jika Postgres sudah ada dalam stack Anda. Qdrant memiliki keseimbangan terbaik antara DX dan kesiapan produksi.

Skalabilitas dan Kesiapan Produksi

Membuat prototipe adalah satu hal. Menjalankan pipeline RAG yang menangani jutaan vektor dengan latensi konsisten adalah hal lain.

Qdrant: Dibangun untuk Skala Horizontal

Qdrant mendukung sharding horizontal langsung dari kotak. Anda dapat mendistribusikan koleksi di seluruh beberapa node, dengan faktor replikasi yang dapat dikonfigurasi untuk ketersediaan tinggi. Peta jalan 2026-nya mencakup pemisahan baca-tulis dan integrasi penyimpanan blok untuk skalabilitas yang lebih baik.

Multi-tenancy adalah fitur kelas satu. Anda dapat mempartisi data berdasarkan penyewa menggunakan pemfilteran berbasis payload tanpa membuat koleksi terpisah, yang menjaga penggunaan sumber daya tetap efisien. Untuk sistem memori agen AI yang menangani banyak pengguna, ini adalah keuntungan yang berarti.

Cerita operasionalnya solid: backup bawaan, endpoint metrik untuk Prometheus, dan pemulihan crash berbasis WAL. Qdrant dirancang untuk di-host sendiri di produksi.

Chroma: Batas Satu Node

Chaoma jujur tentang batasannya. Ini adalah database satu node yang berfokus pada kesederhanaan dan pengembangan lokal. Tidak ada sharding bawaan, tidak ada replikasi, dan tidak ada clustering.

Chroma Cloud tersedia secara umum pada awal 2026 sebagai opsi terkelola serverless dan terdistribusi, sehingga Anda dapat mengalihkan skala horizontal ke sana alih-alih menjalankannya sendiri. Namun, cerita open-source self-hosted masih terutama "satu server, satu instance Chroma." Jika dataset Anda muat dalam satu mesin (hingga beberapa juta vektor tergantung dimensionalitas), itu tidak masalah. Di luar itu, Chroma self-hosted menemui jalan buntu dan Anda harus memilih antara Chroma Cloud atau migrasi.

pgvector: Skala dengan Postgres

pgvector mewarisi cerita skalabilitas PostgreSQL yang telah teruji. Anda mendapatkan replika baca, pooling koneksi via PgBouncer, dan replikasi logis. Penyedia terkelola seperti Neon dan platform Postgres serverless serupa membuat penskalaan vertikal hampir tanpa usaha.

Indeks StreamingDiskANN dari pgvectorscale adalah kunci pembuka untuk skala. Karena menyimpan indeks di disk (SSD) daripada RAM, Anda dapat menangani dataset yang sebaliknya memerlukan instance memori tinggi yang mahal. Pada 50 juta vektor, ia sudah kompetitif dengan database vektor khusus tujuan.

Batasannya adalah sharding horizontal. PostgreSQL tidak secara native melakukan sharding seperti Qdrant. Solusi seperti Citus ada tetapi menambah kompleksitas. Untuk sebagian besar beban kerja RAG self-hosted di bawah 100 juta vektor, penskalaan vertikal dengan pgvectorscale sudah cukup.

Kesimpulan: Qdrant menang untuk skalabilitas horizontal dan multi-tenancy. pgvector menang untuk menggunakan infrastruktur Postgres yang ada. Chroma tidak dirancang untuk skala produksi.

Biaya Self-Hosting

Ketiganya open-source dan gratis untuk dijalankan. Biaya sebenarnya terletak pada infrastruktur dan waktu engineering.

pgvector memiliki keunggulan biaya struktural: jika Anda sudah membayar untuk Postgres, menambahkan pencarian vektor pada dasarnya gratis sampai Anda membutuhkan sumber daya khusus. Tidak ada kontainer tambahan, tidak ada pemantauan tambahan, tidak ada strategi backup tambahan.

Penggunaan sumber daya Qdrant efisien untuk set fiturnya, tetapi ini adalah layanan terpisah; Anda perlu memperhitungkan overhead operasional menjalankan dan memantau bagian infrastruktur lain.

Chroma termurah pada tahap prototipe (nol infrastruktur) tetapi menjadi jalur paling mahal jika Anda mencoba menskalakannya melebihi apa yang dapat ditangani satu node.

Untuk mendeploynya di platform cloud, Qdrant dan pgvector keduanya memiliki deployment berbasis Docker yang mudah. Chroma juga berfungsi, tetapi Anda kehilangan kesederhanaan tertanam yang menjadi nilai jual utamanya.

Kesimpulan: pgvector menang dalam total biaya kepemilikan. Ini menghilangkan seluruh layanan dari stack Anda. Qdrant dihargai wajar untuk apa yang ditawarkannya. Cerita biaya Chroma hanya bekerja selama pembuatan prototipe.

Pemfilteran dan Pencarian Hibrida

RAG bukan sekadar "menemukan vektor terdekat." Anda perlu menggabungkan pencarian kemiripan dengan filter metadata, rentang tanggal, kontrol akses, dan terkadang pencocokan kata kunci.

Qdrant: Raja Pemfilteran

Pemfilteran payload Qdrant terjadi selama traversing HNSW, bukan setelahnya. Itu perbedaan kritis. Pemfilteran pasca-dapat mengurangi jumlah hasil Anda di bawah apa yang Anda minta; pra-pemfilteran menjamin Anda mendapatkan k hasil yang sesuai dengan batasan Anda.

DSL pemfilterannya ekspresif:

from qdrant_client.models import Filter, FieldCondition, MatchValue

results = client.search(
    collection_name="documents",
    query_vector=embedding,
    query_filter=Filter(
        must=[
            FieldCondition(key="category", match=MatchValue(value="engineering")),
            FieldCondition(key="year", range=Range(gte=2024)),
        ]
    ),
    limit=10,
)

Qdrant juga mendukung pencarian hibrida native dengan vektor padat dan jarang dalam kueri yang sama, yang berguna untuk menggabungkan pemahaman semantik dengan presisi kata kunci.

Chroma: Dasar tapi Dapat Digunakan

Chroma mendukung pemfilteran metadata dengan klausa where:

results = collection.query(
    query_embeddings=[embedding],
    where={"category": "engineering"},
    n_results=10,
)

Ini berfungsi untuk kasus sederhana, tetapi pemfilteran terjadi setelah pencarian vektor. Dengan filter yang restriktif dan dataset kecil, Anda mungkin mendapatkan hasil lebih sedikit dari yang diharapkan. Tidak ada dukungan vektor jarang atau pencarian hibrida bawaan.

pgvector: SQL Adalah Kekuatan Super Anda

pgvector mewarisi kekuatan penuh SQL untuk pemfilteran:

SELECT content, embedding <=> $1 AS distance
FROM documents
WHERE category = 'engineering'
  AND created_at > '2024-01-01'
  AND content @@ to_tsquery('RAG & retrieval')
ORDER BY distance
LIMIT 10;

Baris terakhir menggabungkan kemiripan vektor dengan pencarian teks lengkap bawaan PostgreSQL dalam satu kueri. Tidak perlu mesin pencari eksternal. Anda dapat melakukan join terhadap tabel pengguna Anda untuk kontrol akses, agregasi hasil, menggunakan CTE, apa pun yang bisa dilakukan SQL.

Pemindaian iteratif pgvector 0.8.0 juga membantu. Jika pemindaian HNSW awal tidak mengembalikan hasil terfilter yang cukup, ia secara otomatis melanjutkan pencarian alih-alih mengembalikan set parsial.

Kesimpulan: Qdrant menang untuk pemfilteran metadata kompleks berskala besar. pgvector menang untuk fleksibilitas pencarian hibrida (SQL + teks lengkap + vektor dalam satu kueri). Pemfilteran Chroma hanya memadai untuk prototipe.

Kapan Menggunakan Masing-Masing: Kerangka Keputusan

Berikut versi pohon keputusan: Apakah aplikasi Anda sudah menggunakan Postgres? Jika ya, mulailah dengan pgvector; Anda selalu bisa bermigrasi nanti jika Anda tumbuh melampauinya. Jika tidak, apakah Anda membuat prototipe atau membangun untuk produksi? Prototipe pilih Chroma. Produksi pilih Qdrant.

Pendekatan "mulai sederhana, migrasi nanti" valid karena ketiganya mendukung format embedding standar. Memindahkan vektor di antara mereka adalah migrasi data, bukan penulisan ulang arsitektur.

Faktor pgvectorscale: Mengapa Postgres Mengejar Ketertinggalan

Penting untuk membahas ini karena mengubah kalkulasi bagi banyak tim.

Sebelum pgvectorscale, kritik terhadap pgvector selalu "berfungsi baik di bawah satu juta vektor, tetapi tidak bisa diskalakan." Itu benar. Indeks HNSW hidup sepenuhnya di RAM, dan begitu dataset Anda melebihi memori yang tersedia, kinerja jatuh drastis.

StreamingDiskANN mengubah persamaan. Dengan menyimpan indeks graf di SSD alih-alih RAM, pgvectorscale menangani 50 juta vektor pada 471 QPS dengan recall 99%. Statistical Binary Quantization (SBQ) mengompresi vektor dengan hilangnya akurasi minimal; recall turun dari 98,6% menjadi 96,5% bahkan dengan kompresi agresif.

Dampak praktisnya: tim yang menjalankan pipeline RAG di Postgres tidak lagi perlu merencanakan migrasi ke database vektor khusus "ketika situasi menjadi serius." Untuk banyak beban kerja, pgvector + pgvectorscale adalah opsi yang serius.

Namun, pgvectorscale bukan obat mujarab. Ini adalah ekstensi TigerData (sebelumnya Timescale), jadi Anda memerlukan gambar Docker mereka atau penyedia yang membundelnya. Rilis 2026 menambahkan pencarian vektor terfilter berbasis label ke StreamingDiskANN, terinspirasi oleh penelitian Filtered DiskANN Microsoft, yang mempersempit keunggulan lama Qdrant pada kueri terfilter. Tetapi jika Anda membutuhkan isolasi multi-tenant atau dukungan vektor jarang native, Qdrant masih memiliki keunggulan.

Bagaimana Techsy Mendekati Pemilihan Database Vektor

Saat kami membangun pipeline RAG untuk klien, proses evaluasi kami terlihat seperti ini:

1. Audit stack yang ada. Jika tim sudah menjalankan Postgres, pgvector adalah titik awal default. Tidak ada gunanya menambah kompleksitas infrastruktur kecuali ada alasan yang jelas.
2. Profil pola kueri. Pemfilteran metadata berat dengan bidang kardinalitas tinggi? Itu mengarah ke Qdrant. Pencarian semantik sederhana? pgvector atau Chroma sudah cukup.
3. Estimasi lintasan skala. Di bawah 5 juta vektor dan tetap di sana? Opsi apa pun berfungsi. Merencanakan 50 juta+? pgvectorscale atau Qdrant, tergantung langkah 2.
4. Periksa kapasitas ops tim. Startup dua orang seharusnya tidak mengelola klaster Qdrant. Penyedia Postgres terkelola dengan pgvector biasanya merupakan panggilan yang tepat.

Kami telah membangun sistem RAG produksi dengan ketiganya. Jawaban jujurnya adalah bahwa pilihan database kurang penting daripada strategi chunking Anda, model embedding, dan desain pipeline retrieval. Jika Anda menghabiskan lebih banyak waktu memperdebatkan Qdrant vs pgvector daripada menguji ukuran chunk yang berbeda, Anda mengoptimalkan hal yang salah.

Butuh bantuan merancang pipeline RAG? Pemilihan vector-store dan desain retrieval adalah bagian dari layanan integrasi AI kami. Hubungi kami dan kami akan membantu Anda memilih fondasi yang tepat serta membangun lapisan di sekitarnya.

Pertanyaan yang Sering Diajukan

Apakah pgvector cukup baik untuk RAG produksi?

Ya, terutama dengan pgvectorscale. Indeks StreamingDiskANN menangani 50 juta+ vektor dengan recall 99% pada tingkat throughput yang mengalahkan database vektor khusus dalam tolok ukur. Jika Anda sudah menjalankan Postgres, jarang ada alasan untuk menambahkan database vektor terpisah untuk RAG.

Bisakah Chroma diskalakan ke jutaan vektor?

Chroma dapat menangani beberapa juta vektor pada satu node dengan RAM yang cukup, tetapi tidak memiliki penskalaan horizontal bawaan. Untuk dataset di luar apa yang dapat ditampung satu mesin, Anda perlu bermigrasi ke Qdrant, pgvector, atau layanan terkelola.

Apakah Qdrant mendukung pencarian hibrida dengan kata kunci?

Ya. Qdrant mendukung vektor padat dan jarang dalam koleksi yang sama. Anda dapat menjalankan kueri hibrida yang menggabungkan kemiripan semantik (padat) dengan pencocokan kata kunci (jarang) dan mengontrol pembobotan di antara keduanya.

Berapa banyak RAM yang saya butuhkan untuk setiap database?

Tergantung pada jumlah vektor dan dimensi. Sebagai panduan kasar: 1 juta vektor pada 1536 dimensi membutuhkan sekitar 6GB di Qdrant atau pgvector dengan HNSW. Chroma menggunakan sedikit lebih banyak karena overhead Python. Indeks DiskANN pgvectorscale secara dramatis mengurangi kebutuhan RAM dengan menyimpan indeks di SSD.

Bisakah saya bermigrasi antar database ini nanti?

Ya. Ketiganya bekerja dengan array float standar, sehingga vektor bersifat portabel. Anda perlu membuat ulang indeks dan menyesuaikan lapisan kueri Anda, tetapi itu adalah migrasi data, bukan penulisan ulang. Sebagian besar alat migrasi seperti alat migrasi resmi Qdrant menyederhanakan ini.

Mana yang paling baik bekerja dengan LangChain dan LlamaIndex?

Ketiganya memiliki integrasi resmi dengan LangChain dan LlamaIndex. Chroma sering menjadi default dalam tutorial, membuatnya paling lancar untuk memulai. Integrasi Qdrant dan pgvector sama matangnya untuk penggunaan produksi. Lihat panduan kami tentang alat RAG terbaik untuk pandangan lebih luas tentang ekosistem.

Haruskah saya menggunakan pgvector atau pgvectorscale?

Gunakan keduanya. pgvector menyediakan tipe vector inti dan indeks HNSW. pgvectorscale menambahkan StreamingDiskANN di atasnya untuk kinerja yang lebih baik pada skala besar. Mereka adalah ekstensi pelengkap, bukan alternatif.

Apakah Qdrant gratis untuk self-host?

Sepenuhnya gratis di bawah lisensi Apache 2.0. Qdrant Cloud adalah opsi terkelola berbayar, dimulai dengan tier gratis 1GB. Untuk self-hosting, Anda hanya membayar untuk infrastruktur komputasi.

Bagaimana dengan Milvus atau Weaviate sebagai gantinya?

Keduanya adalah alternatif yang solid. Milvus lebih kuat pada skala sangat besar (miliaran+ vektor) dengan akselerasi GPU. Weaviate memiliki pipeline vektorisasi bawaan yang bagus. Tetapi untuk RAG self-hosted di bawah 100 juta vektor, Qdrant, Chroma, dan pgvector mencakup sebagian besar kasus penggunaan dengan kompleksitas operasional yang lebih rendah.

Bisakah pgvector menangani kueri RAG konkuren di produksi?

Ya. PostgreSQL dirancang untuk beban kerja konkuren. pgvector mewarisi pooling koneksi (PgBouncer), replika baca, dan kontrol konkurensi MVCC. Untuk RAG throughput tinggi, pasangkan pgvector dengan connection pooler dan sesuaikan shared_buffers serta effective_cache_size.

Vonis Akhir

Secara keseluruhan: Untuk sebagian besar pipeline RAG self-hosted, pgvector + pgvectorscale adalah pilihan pragmatis. Cukup cepat, dapat diskalakan hingga puluhan juta vektor, dan menjaga stack Anda tetap sederhana. Anda sudah tahu SQL. Tim Anda sudah mengelola Postgres. Satu layanan lebih sedikit berarti satu hal lebih sedikit yang bisa rusak pada pukul 2 pagi.

Jika Anda membutuhkan pencarian terfilter canggih, multi-tenancy, atau Anda membangun produk di mana pencarian vektor adalah fitur inti (bukan kemampuan pendukung), Qdrant adalah investasi yang tepat. Ini adalah database vektor open-source paling lengkap karena suatu alasan.

Chroma mendapatkan tempatnya sebagai alat prototipe. Gunakan untuk memvalidasi pendekatan RAG Anda, menguji strategi chunking yang berbeda, dan beriterasi pada kualitas retrieval. Saat Anda siap untuk produksi, bermigrasilah ke salah satu dari dua lainnya yang sesuai dengan stack Anda.

Saran terbaik? Berhenti berdebat dan mulai membangun. Pilih pgvector jika Anda memiliki Postgres, Qdrant jika tidak, dan buat pipeline RAG Anda berfungsi. Anda selalu bisa mengganti vector store nanti; model embedding, strategi chunk, dan logika retrieval jauh lebih penting.

Sumber

• Tolak Ukur Qdrant
• Rilis Chroma 1.0: 4x Lebih Cepat
• pgvectorscale: StreamingDiskANN untuk PostgreSQL
• pgvector Sekarang Lebih Cepat daripada Pinecone dengan Biaya 75% Lebih Sedikit
• pgvector 0.8.0: Pemindaian Indeks Iteratif
• Harga Qdrant