Pinecone vs ChromaDB vs Qdrant vs pgvector: Hangisi? (2026)

RAG sistemi kuruyorsunuz ve vektör veritabanı seçme aşamasında takıldınız. Pinecone mu, ChromaDB mi, Qdrant mı, yoksa PostgreSQL’in içine gömülü pgvector mı? Hepsinin GitHub’ı güzel görünüyor, hepsi benzerlik araması yapıyor ve hepsinin “production-ready” dediği bir noktası var.

Gerçekte bu dört araç birbirinden oldukça farklı senaryolar için tasarlanmış. Yanlış seçim, ilk prototipin ötesinde büyürken ya ciddi performans sorunuyla ya da tahmin edilemez fatura rakamlarıyla yüzleşmenizi gerektirir. Bu karşılaştırma, 2026 itibarıyla güncel özellikler ve fiyatlandırmayla dört aracı yan yana koyuyor.

Vektör Veritabanı Neden Önemli?

LLM’lerin bağlam penceresi ne kadar genişlerse genişlesin, on binlerce belgeyi her sorguda prompt’a doldurmak ne mümkün ne de mantıklı. Bunun yerine, belgeler önceden embedding modeli geçirilip yüksek boyutlu vektörlere dönüştürülür ve bu vektörler bir veritabanında indekslenir.

Sorgu geldiğinde aynı embedding modeli soruyu da vektöre çevirir; veritabanı en yakın komşuları (ANN, Approximate Nearest Neighbor) milisaniyeler içinde döndürür. Bu belgeler LLM’in bağlamına eklenir ve model “bilgili” bir yanıt üretir. RAG mimarisinin tamamına bakmak isteyenler için temel kavramları özetleyen rehber iyi bir başlangıç noktası.

Hangi veritabanını seçtiğiniz bu akışta doğrudan fark yaratır: indeks kalitesi, filtreleme hızı ve ölçeklenme biçimi son kullanıcı deneyimine yansır.

4 Aday Bir Bakışta

Pinecone: Bulut-Native, Sıfır Ops

Pinecone 2019’dan beri yalnızca yönetilen bulut servisi olarak çalışıyor. Kendi altyapınızı kurmazsınız, index parametrelerini ayarlamazsınız; bir API key alır, indeks oluşturur, vektör gönderirsiniz.

2023’te gelen Serverless tier bu pozisyonu daha da netleştirdi: depolama ve sorgu maliyetleri ayrı faturalanıyor, istekle doğrusal bir maliyet yapısı ortaya çıkıyor. Büyük hacimde ama düşük frekanslı sorgu çalıştırıyorsanız serverless son derece uygun maliyetli olabiliyor.

Pinecone Artıları ve Eksileri

Artılar:

• Ops yükü sıfır: sunucu, indeks optimizasyonu, yedekleme hepsini Pinecone yönetiyor
• Hibrit arama (sparse + dense) native destekli
• Namespace ile multi-tenant izolasyonu kolay
• Güçlü Türkiye CDN kapsamı ve düşük gecikme

Eksiler:

• Vendor lock-in: açık kaynak yok, başka bir sisteme taşıma API üzerinden elle yapılmalı
• Öngörülemeyen maliyet: yüksek yazma hacminde ve büyük indeksle fatura ciddi artabiliyor
• Self-hosted seçeneği yok; tamamen internet bağlantısına ve Pinecone altyapısına bağımlısınız

Ne Zaman Pinecone?

Küçük bir ekip hızla production’a taşımak istiyor ve altyapı yönetimi için bant genişliği yoksa Pinecone mantıklı. Özellikle hibrit arama (keyword + semantik) gerektiren chatbot ve belge arama uygulamalarında hazır gelen sparse vektör desteği önemli bir avantaj.

from pinecone import Pinecone

pc = Pinecone(api_key="YOUR_API_KEY")
index = pc.Index("my-rag-index")

# Upsert
index.upsert(vectors=[
    {"id": "doc-1", "values": [0.1, 0.2, ...], "metadata": {"source": "legal-policy.pdf"}},
])

# Sorgu
results = index.query(
    vector=[0.1, 0.2, ...],
    top_k=5,
    filter={"source": {"$eq": "legal-policy.pdf"}},
    include_metadata=True
)

ChromaDB: Hızlı Prototipleme

ChromaDB, açık kaynak vektör veritabanları arasında en kolay başlangıcı sunan araç. Tek satır pip install chromadb ile hem in-memory hem de persist modda çalışmaya başlarsınız. Özellikle Jupyter Notebook veya ilk prototiplerde herhangi bir altyapı gerekmez.

Ne var ki ChromaDB’nin mimarisi performans ve ölçek açısından kısıtlı. Büyük koleksiyonlarda ANN araması yavaşlar, metadata filtreleme kabiliyetleri diğer araçlara kıyasla basit kalır. Hibrit arama desteği de yok.

ChromaDB Artıları ve Eksileri

Artılar:

• Kurulum ve kullanım en basit olan araç
• Local development’ta sıfır bağımlılık
• LangChain, LlamaIndex ile sıkı entegrasyon; örnek kod bolluğu
• Tamamen ücretsiz (self-hosted)

Eksiler:

• Büyük koleksiyonlarda (10M+ vektör) belirgin performans düşüşü
• Hibrit arama yok; sparse vektör desteği eksik
• Production deployment’ta ek mühendislik gerekiyor (Docker, auth, yük dengeleme)
• Yönetilen bulut servisi ücretli ve hâlâ olgunlaşıyor

Ne Zaman ChromaDB?

Bir hafta içinde çalışan bir prototip üretmek istiyorsanız ChromaDB hızı en iyi seçenek. Hackathon projeleri, araştırma denemeleri ve 1 milyonun altındaki vektör koleksiyonları için yeterli. Production’da kalmayı planlamıyorsanız ya da koleksiyon büyüdüğünde başka bir araca geçmeyi göze alıyorsanız ChromaDB ile başlamak gayet mantıklı.

import chromadb

client = chromadb.PersistentClient(path="./chroma_db")
collection = client.get_or_create_collection("my-rag-collection")

# Upsert
collection.add(
    ids=["doc-1", "doc-2"],
    embeddings=[[0.1, 0.2, ...], [0.3, 0.4, ...]],
    metadatas=[{"source": "readme.md"}, {"source": "guide.md"}],
    documents=["İçerik metni 1", "İçerik metni 2"]
)

# Sorgu
results = collection.query(
    query_embeddings=[[0.1, 0.2, ...]],
    n_results=5,
    where={"source": "readme.md"}
)

Qdrant: Performans Odaklı Açık Kaynak

Qdrant, Rust ile yazılmış ve yüksek performansı birinci öncelik olarak tasarlanmış açık kaynak bir vektör veritabanı. 2026 itibarıyla production vektör veritabanları arasında en olgun açık kaynak seçenek.

HNSW indeksi üzerine kendi optimizasyonlarını ekleyen Qdrant, scalar ve product quantization ile depolama maliyetini önemli ölçüde düşürürken doğruluk kaybını minimize tutuyor. Payload filtreleme sistemi çok detaylı: JSON alanlarına karmaşık sorgular yazabilir, filtre + ANN aramasını aynı anda yürütebilirsiniz. Hibrit arama (sparse + dense) ve multi-vector desteği de mevcut.

GraphRAG mimarisi gibi karmaşık retrieval pattern’larında çok sayıda koleksiyon ve arama stratejisini bir arada yönetmek gerekir. Qdrant bu tür pipeline’lar için gereken esnekliği sağlıyor.

Qdrant Artıları ve Eksileri

Artılar:

• Benchmark’larda yüksek QPS ve düşük gecikme (özellikle filtrelenmiş aramalarda)
• Güçlü quantization: binary, scalar, product seçenekleri
• Açık kaynak + self-hosted + Qdrant Cloud (yönetilen) seçeneği bir arada
• Hibrit arama ve multi-vector koleksiyon desteği
• Rust tabanlı mimari, bellek ayak izini düşük tutuyor

Eksiler:

• ChromaDB’ye göre kurulum ve konfigürasyon daha fazla dikkat ister
• Qdrant Cloud fiyatlandırması Pinecone’a kıyasla biraz daha karmaşık
• Ekosistem entegrasyonları Pinecone kadar geniş değil (fark kapanıyor)

Ne Zaman Qdrant?

Performans SLA’niz varsa, büyük koleksiyonlarla çalışıyorsanız veya gelecekte self-hosted’dan cloud’a geçiş yapmayı planlıyorsanız Qdrant ideal. RAG kalite artırımı için reranker kullanan pipeline’larda vektör arama katmanının güçlü filtreleme yapması gerekir; Qdrant’ın payload filter sistemi bu ihtiyacı tam karşılıyor.

from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct, Filter, FieldCondition, MatchValue

client = QdrantClient(url="http://localhost:6333")

# Koleksiyon oluştur
client.create_collection(
    collection_name="rag-docs",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)

# Upsert
client.upsert(
    collection_name="rag-docs",
    points=[
        PointStruct(id=1, vector=[0.1, 0.2, ...], payload={"source": "policy.pdf", "year": 2026}),
    ]
)

# Filtrelenmiş sorgu
results = client.search(
    collection_name="rag-docs",
    query_vector=[0.1, 0.2, ...],
    query_filter=Filter(must=[FieldCondition(key="year", match=MatchValue(value=2026))]),
    limit=5
)

pgvector: PostgreSQL’e Gömülü Vektör

pgvector, mevcut PostgreSQL veritabanınıza vektör tipi ve indeks desteği ekleyen bir eklenti. Yeni bir altyapı kurmak yerine zaten varolan Postgres’inize CREATE EXTENSION vector; yazarak benzerlik araması yapabilirsiniz.

Bu yaklaşım, vektör verisini ilişkisel tablolarla bir arada yönetmek isteyenler için ciddi bir avantaj. Örneğin kullanıcı tablosuna doğrudan bağlı belge vektörleri, SQL join’leriyle filtrelenmiş arama, mevcut yetkilendirme ve yedekleme altyapısının vektörleri de kapsaması: bunların hepsi pgvector’da sorunsuz çalışır.

0.7 sürümüyle gelen HNSW indeks desteği performans açığını büyük ölçüde kapattı. Ancak Qdrant veya Pinecone’un milyon-ötesi vektördeki QPS rakamlarına ulaşmak hâlâ zor.

pgvector Artıları ve Eksileri

Artılar:

• Mevcut Postgres altyapısına eklenti olarak kurulur; sıfır ekstra sistem
• SQL ile tam güçlü filtreleme ve join; ilişkisel + vektör mantığını tek sorguda yürütme
• Supabase, Neon, RDS gibi yönetilen Postgres hizmetleri pgvector destekliyor
• Lisans maliyeti yok; mevcut Postgres maliyetine dahil
• Açık kaynak ve portabl

Eksiler:

• Büyük koleksiyonlarda (10M+ vektör) Qdrant veya Pinecone’a kıyasla daha düşük QPS
• Hibrit arama için ayrı FTS (full-text search) entegrasyonu gerekiyor
• Vektöre özgü yük dengeleme ve replikasyon, Postgres mimarisinden miras alınıyor; vektör-spesifik optimizasyon sınırlı

Ne Zaman pgvector?

Zaten PostgreSQL üzerinde çalışan bir uygulamanız varsa ve koleksiyon boyutu 5-10 milyon vektörü aşmıyorsa pgvector en az dirençli yol. Ekstra bir sisteme ihtiyaç olmadan vektör araması eklemiş olursunuz. Supabase kullananlar için durum özellikle cazip: Supabase pgvector’ı kutudan çıkar çıkmaz destekliyor.

import psycopg2
import numpy as np

conn = psycopg2.connect("postgresql://user:pass@localhost/mydb")
cur = conn.cursor()

# Eklentiyi etkinleştir (bir kez)
cur.execute("CREATE EXTENSION IF NOT EXISTS vector;")

# Tablo oluştur
cur.execute("""
    CREATE TABLE IF NOT EXISTS documents (
        id SERIAL PRIMARY KEY,
        content TEXT,
        source TEXT,
        embedding vector(1536)
    );
""")

# HNSW indeksi
cur.execute("""
    CREATE INDEX IF NOT EXISTS docs_embedding_idx
    ON documents USING hnsw (embedding vector_cosine_ops);
""")

# Upsert
embedding = np.random.rand(1536).tolist()
cur.execute(
    "INSERT INTO documents (content, source, embedding) VALUES (%s, %s, %s)",
    ("Belge içeriği", "policy.pdf", embedding)
)

# Benzerlik sorgusu
query_vec = np.random.rand(1536).tolist()
cur.execute("""
    SELECT content, source, 1 - (embedding <=> %s) AS similarity
    FROM documents
    WHERE source = 'policy.pdf'
    ORDER BY embedding <=> %s
    LIMIT 5;
""", (query_vec, query_vec))

results = cur.fetchall()
conn.commit()

Performans Karşılaştırması

Birkaç bağımsız benchmark (Ann-Benchmarks, Qdrant’ın kendi ölçümleri, Pinecone yayınları) 2025-2026 döneminde tutarlı bir tablo çiziyor:

Quantization önemli bir değişken: Qdrant’ın binary quantization’ı 32 kat küçültülmüş indeks boyutuyla çalışabiliyor ve recall kaybı minimal kalıyor. Pinecone serverless da kendi sıkıştırma katmanını otomatik uygular. pgvector 0.7+ scalar quantization ekledi ama henüz Qdrant olgunluğuna ulaşmadı.

vLLM gibi yüksek throughput inference engine’larıyla üretim pipeline’ı kuruyorsanız vektör veritabanının p99 gecikmesi kritik. Qdrant ve Pinecone bu kanalda güvenilir.

Maliyet Analizi

Pinecone’un Serverless modelinde maliyet, sorgu sayısı ve depolama boyutuyla birlikte değişiyor. Yüksek yazma hacmi veya büyük indekslerde Pod planları daha öngörülebilir. Qdrant Cloud aylık sabit ücretle çalışır ve iş yükü büyüdükçe cluster boyutunu artırırsınız.

ChromaDB ve Qdrant self-hosted seçenekleri altyapı maliyetini kendiniz yönetmenizi gerektiriyor. Küçük ekipler için Qdrant Cloud veya Pinecone Serverless yönetim yükünü önemli ölçüde azaltıyor.

Hangisini Seçmeliyim?

Senaryo bazlı karar rehberi:

Hızla production’a taşımak istiyorum, ops kapasitem yok: → Pinecone. Yönetilen servis, hibrit arama desteği, güvenilir SLA. Maliyet kontrolü için Serverless ile başlayın.

Prototip veya araştırma projesi, koleksiyon küçük (<1M vektör): → ChromaDB. Tek pip install, sıfır yapılandırma, bol örnek kod. Büyürseniz Qdrant’a geçiş nispeten basit.

Açık kaynak istiyorum, performans SLA önemli, self-hosted veya cloud ikisi de tamam: → Qdrant. Rust performansı, güçlü payload filtreleme, quantization seçenekleri, cloud veya self-hosted esnekliği. Mid-to-large üretim için en dengeli seçim.

Zaten Postgres kullanıyorum, ek sistem istemiyorum, koleksiyon 5-10M vektör altında: → pgvector. SQL gücünü vektör aramasıyla birleştirin; Supabase veya Neon ile yönetilen seçenek de var.

GraphRAG veya karmaşık multi-hop retrieval gerekiyor: → Qdrant veya Pinecone. Güçlü filtreleme ve hibrit arama bu tür karmaşık retrieval pipeline’larında kritik.

Çok-kiracılı (multi-tenant) SaaS ürünü, her müşteri izole olmalı: → Pinecone (namespace) veya Qdrant (collection + payload filter). ChromaDB çok koleksiyonu yönetmekte zorlanır; pgvector için şema izolasyonu elle yazılır.

Dört araç arasında net bir “herkese uyan” yok. Prototip ChromaDB ile başlar, ölçek Qdrant’a taşır, ops yükünü sıfırlamak isteyen Pinecone’u seçer, mevcut Postgres’i olanlar pgvector’a uzanır. Karar genellikle şu soruya bağlı: ne kadar vektörünüz var, altyapıyı kendiniz yönetmek istiyor musunuz ve p99 gecikmesinin ne olması gerekiyor?