Vektör Veritabanı Seçimi 2026: Qdrant, pgvector, Pinecone ve Milvus Kıyaslaması

TL;DR — 2026'da vektör veritabanı seçimi, "hangisi en hızlı" sorusundan çok "benim iş yüküme hangisi uyuyor" sorusuna dönüştü. Qdrant, saf hız ve düşük gecikmede öne çıkıyor (p50 ~4ms); pgvector, mevcut Postgres'inize sıfır yeni altyapıyla vektör araması ekliyor ve 10 milyon vektöre kadar rahat çalışıyor; Pinecone en kolay işletilen yönetilen deneyimi sunuyor; Milvus ise milyarlarca vektörlü dev ölçekler için. Bu yazıda bu dört seçeneği gerçek kıyaslama verileriyle, karar çerçevesiyle ve Türkiye'deki KVKK/veri konumu kısıtlarıyla ele alıyorum. Altın kural değişmedi: sentetik kıyaslamalar yalan söyler; kendi verinizle test edin.

Sahada en sık karşılaştığım manzara, ekiplerin blog yazılarındaki kıyaslama tablolarına bakıp "en hızlı olan buymuş" diyerek karar vermesi. Bu, neredeyse her zaman yanlış karar. Çünkü vektör veritabanı performansı; veri boyutuna, sorgu desenine, filtreleme ihtiyacına, gecikme toleransına ve operasyonel kapasitenize göre kökten değişiyor. Birinin iş yükünde zirvede olan bir çözüm, sizinkinde vasat kalabilir.

2026 itibarıyla ekosistem olgunlaştı ve seçenekler netleşti. Ama bu netlik, "tek doğru cevap" anlamına gelmiyor; aksine, doğru cevabın bağlama bağlı olduğu anlamına geliyor. Bu yazının amacı size "şunu seç" demek değil; kendi doğru cevabınızı bulmanız için çerçeve vermek.

"

Bir müşterime şunu söylemiştim: "Vektör veritabanı seçimi bir din savaşı değil, bir mühendislik kararı. Ve mühendislik kararları, inançla değil, ölçümle verilir."

Qdrant. Rust ile yazılmış, sıfırdan vektör araması için tasarlanmış açık kaynaklı bir çözüm. Saf hızda lider: amaca özel vektör veritabanları arasında en düşük p50 gecikmesine sahip (yaklaşık 4ms, p99 ~25ms). 10 milyon vektörde p99 gecikmesi genellikle ~12ms civarında; Weaviate (~16ms) ve Milvus'un (~18ms) önünde. Zengin filtreleme (payload filtering) ve güçlü bir sorgu API'si sunuyor. Performans ve açık kaynak esnekliği önceliğinizse güçlü aday.

pgvector. Mevcut Postgres veritabanınıza vektör araması ekleyen bir uzantı. En büyük avantajı: sıfır yeni altyapı. Zaten Postgres kullanıyorsanız, verinizi taşımadan, yeni bir sistem öğrenmeden vektör aramasına başlıyorsunuz. 10 milyon vektöre kadar rahat çalışıyor; pgvectorscale eklentisiyle 50 milyon vektörde 99% recall'da 471 QPS gibi ciddi rakamlara ulaşabiliyor. Postgres sizin veri platformunuzsa, varsayılan tercih bu olmalı.

Pinecone. En kolay işletilen yönetilen deneyim. Altyapı yönetimi gerektirmiyor, sub-10ms p50 gecikme sunuyor. Kendi altyapınızı kurmak ve bakımını yapmak istemiyorsanız, en pürüzsüz yol. Bedeli, yönetilen bir hizmete bağımlılık ve maliyet; ama operasyonel yükü tamamen devretmek isteyen ekipler için mantıklı.

Milvus. Dev ölçekler için tasarlanmış. Dağıtık mimarisi milyarlarca vektörü kaldırabiliyor; GPU hızlandırma desteğiyle büyük veri kümelerinde daha da hızlanıyor. En büyük RAG uygulamaları için başvurulan seçenek. Ama bu güç, operasyonel karmaşıklıkla geliyor; küçük bir proje için Milvus, fazla ağır bir çekiç.

Veritabanı	Öne çıkan	İdeal senaryo
Qdrant	En düşük gecikme, açık kaynak hız	Performans-öncelikli, açık kaynak
pgvector	Sıfır yeni altyapı	Zaten Postgres kullananlar, ≤10M vektör
Pinecone	En kolay işletim	Operasyon yükü istemeyen ekipler
Milvus	Milyarlarca vektör, GPU	Dev ölçekli RAG

Sahada kullandığım karar çerçevesi birkaç net soruya dayanıyor. Bunları sırayla yanıtlamak, seçenekleri hızla daraltıyor.

Zaten Postgres kullanıyor musunuz? Evetse ve veri boyutunuz 10 milyon vektörün altındaysa, pgvector neredeyse her zaman en akıllı başlangıç. Yeni bir sistem eklemenin operasyonel maliyeti, çoğu zaman marjinal performans kazancından ağır basar.

Altyapı yönetmek istiyor musunuz? İstemiyorsanız ve yönetilen bir hizmete bütçeniz varsa, Pinecone pürüzsüz yolu sunar. Küçük bir ekipseniz ve DevOps kapasiteniz sınırlıysa, bu değerli.

Ölçeğiniz ne kadar büyük? Milyarlarca vektöre gidiyorsanız, Milvus'un dağıtık mimarisi devreye girer. On milyonlar seviyesindeyseniz, Qdrant ya da pgvectorscale fazlasıyla yeter.

Filtreleme ne kadar kritik? Vektör aramasını yoğun meta veri filtreleriyle birleştiriyorsanız (örneğin "yalnızca şu tarihten sonraki, şu kategorideki belgeler"), Qdrant'ın payload filtreleme yetenekleri öne çıkar.

Bu dört soru, çoğu ekibi hızla iki-üç seçeneğe indiriyor. Geri kalanı, kendi verinizle yapılacak test.

Bloglarda dolaşan kıyaslama tablolarına karşı sağlıklı bir şüphe geliştirmeniz gerekiyor. Bu tabloların çoğu, sentetik veri kümeleri ve idealize sorgu desenleriyle üretiliyor. Oysa sizin gerçek verinizin dağılımı, gerçek embedding'lerinizin geometrisi ve gerçek kullanıcılarınızın filtre koşulları, o sentetik dünyayla örtüşmüyor. Bir veritabanı, kâğıt üzerinde 471 QPS verirken, sizin filtreleme ağırlıklı iş yükünüzde bambaşka bir tablo çizebilir.

Doğru yaklaşım tek cümlede özetlenir: kendi verinizle, kendi sorgu deseninizle, kendi filtre koşullarınızla test edin. Küçük bir temsili veri kümesi alın — diyelim yüz bin ya da bir milyon gerçek vektör — ve iki-üç aday veritabanını aynı koşullarda kıyaslayın. Recall'ı (getirmenin isabetini), gecikmeyi ve QPS'i kendi bağlamınızda ölçün. Bu bir günlük çalışma, ama sizi aylarca yanlış bir seçimin operasyonel yükünden kurtarır.

Sahada gördüğüm en pahalı hatalardan biri, blog kıyaslamasına güvenip yanlış veritabanına aylarca yatırım yaptıktan sonra göç etmek zorunda kalmak. Vektör veritabanı göçü, embedding'lerin yeniden indekslenmesini, sorgu katmanının yeniden yazılmasını ve üretim kesintisi riskini içerir. Bu acıdan kaçınmanın yolu, baştan kendi verinizle test etmek.

Vektör aramasında gizli bir ödünleşim var: recall (isabet) ile hız çoğu zaman ters yönde çekişir. Yaklaşık en yakın komşu (ANN) algoritmaları, hızı artırmak için isabetten biraz feda eder. Bir veritabanını "hızlı" diye överken, hangi recall seviyesinde hızlı olduğunu sormak şart. %99 recall'da hızlı olmak ile %90 recall'da hızlı olmak, çok farklı şeyler.

İş bağlamınız bu dengeyi belirler. Bir hukuki belge aramasında, kritik bir emsal kararı kaçırmak kabul edilemez; yüksek recall şart, gecikmeden biraz feda edilebilir. Bir ürün öneri sisteminde ise, birkaç ilgili ürünü kaçırmak felaket değil; hız öne çıkabilir. Doğru ayar, veritabanının kendisinde değil, sizin iş gereksiniminizde gizli. İndeks parametrelerini (HNSW'nin ef ve M değerleri gibi) bu dengeye göre ayarlamak, çoğu zaman veritabanını değiştirmekten daha etkili.

Türkiye'de vektör veritabanı seçimi, KVKK ve veri konumu boyutunu da içeriyor. Vektörler zararsız sayılar gibi görünse de, aslında kaynak verinin — belgelerin, mesajların, kişisel bilgilerin — anlamsal izini taşıyor. Üstelik vektörlerden yaklaşık olarak kaynak metni geri çıkarmaya yönelik saldırılar (embedding inversion) literatürde tartışılıyor. Yani vektör deposu, kişisel veri barındıran bir sistem olarak değerlendirilmeli.

Bu, yönetilen bulut hizmetlerinde veri konumu sorusunu öne çıkarıyor. Pinecone gibi bir yönetilen hizmet kullanıyorsanız, verilerinizin hangi bölgede tutulduğunu ve KVKK aktarım kurallarına uygunluğunu netleştirmelisiniz. Hassas veri işleyen bankacılık, sağlık ve kamu uygulamalarında birçok kurum, kendi altyapısında barındırabildiği pgvector ya da Qdrant gibi açık kaynak seçenekleri tercih ediyor — çünkü veri hiç kurumsal sınırın dışına çıkmıyor. Bu, açık kaynak çözümlerin Türkiye bağlamındaki gizli avantajı: performansın ötesinde, veri egemenliği.

Seçimde sık atlanan bir kalem, toplam maliyet. Yönetilen hizmetler (Pinecone) öngörülebilir bir abonelik sunar ama ölçekte pahalılaşabilir. Açık kaynak çözümler (Qdrant, pgvector, Milvus) lisans maliyeti taşımaz ama barındırma, ölçekleme ve bakımın operasyonel yükünü size yükler. Bu yükü taşıyacak DevOps kapasiteniz yoksa, "ücretsiz" açık kaynak aslında gizli bir maliyet üretir.

Karar kuralı basit: operasyonel kapasitenizi dürüstçe değerlendirin. Güçlü bir platform ekibiniz varsa, açık kaynak hem daha ucuz hem daha esnek. Küçük bir ekipseniz ve odağınız ürünse, yönetilen bir hizmetin devrettiği operasyonel yük, ödediğiniz primi haklı çıkarabilir. En pahalı seçenek, kapasitesi olmayan bir ekibin karmaşık bir açık kaynak sistemi yarım yamalak işletmesidir.

Sonuçta vektör veritabanı seçimi, bir moda ya da popülerlik yarışması değil; iş yükünüze, ölçeğinize, operasyonel kapasitenize ve KVKK bağlamınıza dayanan bir mühendislik kararı. Zaten Postgres'iniz varsa pgvector ile başlayın; performans ve filtreleme kritikse Qdrant'a bakın; operasyon istemiyorsanız Pinecone'u değerlendirin; dev ölçekteyseniz Milvus'u. Ama hangisini düşünürseniz düşünün, kararı vermeden önce bu hafta kendi verinizden küçük bir örnekle iki adayı yan yana test edin. O test, blog tablolarının asla veremeyeceği tek gerçeği verecek: sizin bağlamınızda hangisinin gerçekten çalıştığını.

2026'da vektör veritabanı seçimini etkileyen bir başka boyut, saf vektör aramasının çoğu üretim senaryosunda tek başına yetmemesi. En iyi sonuçlar, anlamsal vektör aramasını klasik anahtar kelime aramasıyla (BM25 gibi) birleştiren hibrit yaklaşımdan geliyor. Vektör araması anlamı yakalar ama tam terim eşleşmelerini — bir ürün kodu, bir özel isim, bir kısaltma — kaçırabilir; anahtar kelime araması bu boşluğu doldurur. Seçtiğiniz veritabanının hibrit aramayı yerel olarak destekleyip desteklemediği, artık kritik bir kriter.

Bunun üstüne bir de yeniden sıralama (reranking) katmanı geliyor. Veritabanı hızlı bir ilk getirmeyle diyelim yirmi aday döndürür; daha pahalı ama isabetli bir reranker bunları yeniden sıralayıp en iyi beşini seçer. Bu iki aşamalı mimari, hem hızı hem kaliteyi dengeler. Veritabanı seçerken, bu hibrit + reranking hattına ne kadar kolay entegre olduğuna bakmak, salt gecikme rakamına bakmaktan çok daha isabetli bir değerlendirme.

Bütün bunları birleştirdiğimizde, doğru vektör veritabanı, en yüksek benchmark skoruna sahip olan değil; sizin iş yükünüze, ölçeğinize, filtreleme ve hibrit arama ihtiyacınıza, operasyonel kapasitenize ve KVKK bağlamınıza en iyi oturan. Bu değerlendirmeyi kendi verinizle yapmak, bir günlük yatırımla aylık göç acısından kaçınmanın yolu. Karar sizin bağlamınızda saklı; onu ortaya çıkarmanın tek yolu, blog tablosuna değil, kendi testinize güvenmek.