Vektör Veritabanı Karşılaştırması: pgvector, Qdrant, Milvus, Weaviate (2026)

TL;DR — Vektör veritabanı seçimi, insanların sandığı gibi bir "hangi benchmark daha hızlı" yarışı değil. Sahada gördüğüm gerçek şu: doğru karar dört eksende veriliyor — yönetilen mi (managed) yoksa kendi sunucunda mı (self-host) çalışacak, hangi ölçek katmanındasın, hibrit aramaya ne kadar ihtiyacın var, ve ekibinin mevcut veri platformu taahhütleri neler. Manşetteki milisaniyeler işin en önemsiz kısmı. Pratik reçetem çoğu Türk kurumu için net: zaten Postgres kullanıyorsanız ve ~50M vektörün altındaysanız pgvector ile başlayın, hız gerçekten kritikse Rust tabanlı Qdrant'a geçin, hibrit arama (vektör + BM25 tek sorguda) önemliyse Weaviate, milyarlarca vektör ve gerçek bir operasyon ekibiniz varsa Milvus. KVKK açısından ise mesele daha da keskin: Pinecone gibi yönetilen bulut çözümlerinde veri çoğu zaman yurt dışına çıkar; veri egemenliği önemliyse kendi sunucunuzda çalışan açık kaynak çözümler (pgvector, Qdrant, Milvus, Weaviate) masada kalan tek seçenektir. Bu yazıda sekiz veritabanını, arkalarındaki indeks kavramlarını ve karar çerçevesini sahadan örneklerle tek tek açıyorum.

RAG (Retrieval-Augmented Generation) ve ajan (agent) projelerine giren çoğu ekip, vektör veritabanını "bir kutu, içine embedding'leri atıyoruz, arıyoruz" diye görüyor. Bu görüntü yanlış değil ama eksik. Gelin işin özünü net koyalım.

Bir metin parçasını (chunk) bir embedding modeline verdiğinizde, size bir sayı dizisi döner — 384, 768, 1024 ya da 1536 boyutlu bir vektör. Bu vektör, o metnin "anlamını" çok boyutlu bir uzayda bir nokta olarak temsil eder. Anlamca benzer iki metin, bu uzayda birbirine yakın iki nokta olur. Vektör veritabanının tek işi şu: milyonlarca, hatta milyarlarca bu tür noktanın içinden, verdiğiniz sorgu vektörüne en yakın olanları hızlıca bulmak.

Kulağa basit geliyor ama burada bir tuzak var. 10 milyon vektörünüz varsa ve her sorguda hepsiyle tek tek mesafe hesaplarsanız (buna "brute force" ya da tam arama diyoruz), bu doğru ama korkunç yavaş bir yöntemdir. İşte vektör veritabanlarını sıradan bir veritabanından ayıran şey tam olarak burada devreye giriyor: yaklaşık en yakın komşu (Approximate Nearest Neighbor — ANN) indeksleri. Bu indeksler, %100 doğruluktan azıcık taviz vererek aramayı yüzlerce, binlerce kat hızlandırır.

Bu tavizin adı recall (geri çağırma). Recall, gerçek en yakın komşuların ne kadarını yakaladığınızın ölçüsüdür. %95 recall demek, gerçekten en yakın 100 komşudan 95'ini bulabildiniz demek. Vektör veritabanı dünyasının bütün mühendisliği aslında üç şey arasındaki gerginlikten ibaret: recall (kalite), latency (gecikme) ve cost (maliyet). Birini iyileştirirseniz genelde diğerinden taviz verirsiniz. İşin sanatı, sizin senaryonuz için doğru dengeyi bulmaktır. Bu yazının geri kalanını bu üçgeni anlamak üzerine kuracağız çünkü seçtiğiniz veritabanı bu dengeyi ne kadar iyi ayarlamanıza izin verdiğine göre değerlenir.

Vektör veritabanlarının kalbinde indeks yatar. Piyasadaki neredeyse her ürün, iki temel indeks ailesinden birini ya da her ikisini kullanır. Bunları anlamadan doğru seçim yapamazsınız, o yüzden sabırla açalım.

HNSW (Hierarchical Navigable Small World). Bunu çok katmanlı bir yol haritası gibi düşünün. En üst katmanda az sayıda "otoban" düğüm var, aşağı indikçe daha yoğun "sokaklar" beliriyor. Arama en üstten başlar, kabaca doğru bölgeye otobanla hızlıca ulaşır, sonra alt katmanlara inip komşuları tek tek gezerek hassaslaşır. HNSW'nin güzelliği çok yüksek recall'u çok düşük gecikmeyle verebilmesi. Kötü tarafı ise bellek açlığı: bütün o katman katman bağlantıları RAM'de tutmak gerekir, bu yüzden büyük veri setlerinde bellek maliyeti hızla artar. Qdrant, Weaviate ve pgvector'ın modern sürümü hep HNSW'ye yaslanır.

IVF (Inverted File Index). Bu farklı bir felsefe. Önce bütün vektörleri kümelere (cluster) ayırır — diyelim 4096 küme. Her kümenin bir merkezi (centroid) var. Bir sorgu geldiğinde, önce sorguya en yakın birkaç kümeyi bulur, sonra sadece o kümelerin içinde arama yapar. Yani bütün veriyi taramak yerine küçük bir alt kümeye odaklanır. IVF belleği HNSW kadar tüketmez, o yüzden devasa ölçeklerde (milyarlarca vektör) daha ekonomiktir. Ama ayarı daha hassastır: kaç küme yoklayacağınız (nprobe) recall'u doğrudan etkiler. Milvus ve Faiss dünyası IVF varyantlarında güçlüdür.

Pratik özet olarak sahada şunu söylüyorum:

"

Onlarca milyona kadar vektörde ve düşük gecikme istiyorsanız HNSW neredeyse her zaman doğru cevap. Milyarlar seviyesine çıkıp bellek maliyeti sizi boğmaya başladığında IVF (ve türevleri) devreye girer. Çoğu Türk kurumu ilk gruptadır — abartılı ölçek varsayımıyla gereksiz karmaşık sistem kurmayın.

Bir de bu iki ailenin dışında hızla yaygınlaşan melez indeksler var. Örneğin IVF ile PQ'yu (çarpımsal kuantizasyon) birleştiren varyantlar, hem küme mantığından hem sıkıştırmadan aynı anda faydalanarak devasa veri setlerini makul bellekte tutabiliyor. Bir başka pratik gerçek de şu: HNSW'nin ayar parametreleri (M ve ef_construction) recall ile bellek/hız arasındaki dengeyi doğrudan belirler. M değerini büyütürseniz her düğüm daha çok komşuya bağlanır, recall yükselir ama bellek ve inşa süresi artar. Bu ayarları körlemesine varsayılan bırakmak yerine kendi veri dağılımınıza göre bir-iki deney yapmak, çoğu zaman ürün değiştirmekten daha büyük kazanç sağlar. Sahada gördüğüm gerçek şu: ekipler genelde "yanlış veritabanı seçtik" derken, aslında doğru veritabanını yanlış ayarlamış oluyorlar.

Vektör veritabanı maliyetinin büyük kısmı bellektir, çünkü hızlı arama için indeksin RAM'de olması gerekir. Burada hayat kurtaran teknik kuantizasyon (quantization). Fikir basit: her vektör bileşenini daha az bitle temsil et, böylece daha az yer kaplasın.

• Scalar quantization (skaler): Genelde 32-bit float değerleri 8-bit tam sayıya (int8) indirger. Bellek dörtte bire düşer, doğruluk kaybı çoğu senaryoda ihmal edilebilir. Çoğu ekip için ilk uğrak burasıdır.
• Product quantization (çarpımsal, PQ): Vektörü küçük alt parçalara böler ve her parçayı bir kod kitabındaki (codebook) en yakın örnekle temsil eder. Bellek tasarrufu çok daha agresiftir (8x, 16x, hatta daha fazla) ama doğruluk kaybı ve ayar karmaşıklığı artar. Devasa ölçekler için biçilmiş kaftandır.
• Binary quantization (ikili): En uç nokta. Her bileşeni tek bir bite indirger (pozitif mi negatif mi). Bellek 32x'e kadar düşer, arama Hamming mesafesiyle inanılmaz hızlanır. Ama doğruluk kaybı ciddidir; genelde bir "yeniden puanlama" (rescoring) aşamasıyla birlikte kullanılır — kaba filtreyi binary yapar, en iyi adayları tam vektörle yeniden sıralar.

Neden önemli? Çünkü embedding boyutu doğrudan depolama maliyetidir. 1536 boyutlu bir OpenAI embedding'i, 10 milyon belge için yaklaşık 60 GB ham float alanı demektir. Aynı veriyi int8 skaler kuantizasyonla 15 GB'a, binary ile 2 GB'ın altına indirebilirsiniz. TL bazında bulut sunucu kiralarken bu fark, aylık faturanızı ikiye üçe katlayan ya da yarıya indiren şeydir. Sahada gördüğüm bir kural: önce embedding boyutunu sorgulayın. 1536 yerine 768 boyutlu bir modelle benzer kaliteyi alabiliyorsanız, depolama ve gecikmenizi baştan yarıya indirmişsiniz demektir.

Gerçek dünyada saf vektör araması nadiren yeterlidir. Genelde şöyle bir sorgu gelir: "Bu kullanıcının erişebileceği, 2025 yılına ait, İK departmanına ait belgeler içinde şu soruya en yakın olanları bul." Buradaki tarih, departman ve erişim kısıtları metadata filtreleridir ve vektör benzerliğiyle birlikte çalışmaları gerekir.

Burada bir tuzak var: filtrelemeyi önce mi yaparsınız (pre-filter), sonra mı (post-filter)? Önce filtreleyip sonra ararsanız, ANN indeksinin verimi bozulabilir çünkü indeks tüm veri için kuruldu, filtre onu delik deşik ediyor. Sonra filtrelerseniz, indeksten dönen ilk k aday filtreden geçtikten sonra elinizde yeterli sonuç kalmayabilir. İyi vektör veritabanları bu problemi zarifçe çözer — Qdrant'ın "filterable HNSW" yaklaşımı ve Weaviate'in filtreli aramaları bu konuda olgundur. pgvector tarafında ise Postgres'in kendi WHERE koşullarıyla birleşme, hem güçlü hem de bazı sürümlerde recall açısından dikkat isteyen bir konudur.

Sahadaki tavsiyem net: filtreleme ihtiyacınızı gün birden ciddiye alın. Çünkü çok kiracılı (multi-tenant) bir kurumsal RAG sisteminde erişim kontrolü metadata filtresiyle yapılır ve bu yanlış kurulursa, bir kullanıcı başka bir departmanın belgesini görebilir. Bu artık bir performans meselesi değil, bir KVKK ihlali meselesidir.

Türkçe içerikle çalışan herkesin bilmesi gereken bir şey var: saf vektör araması, nadir ve spesifik terimlerde zayıftır. Ürün kodları, kanun madde numaraları ("6698 sayılı kanun madde 11"), özel isimler, kısaltmalar... Bunlarda semantik benzerlik genel anlamı yakalar ama tam terim eşleşmesini kaçırabilir.

İşte burada hibrit arama devreye giriyor: vektör benzerliği (anlamı yakalar) ile BM25 gibi klasik anahtar kelime aramasını (kelimeyi yakalar) birleştirmek. Bu iki dünyanın sonuçları genelde Reciprocal Rank Fusion (RRF) gibi bir yöntemle harmanlanır.

Burada veritabanları arasında büyük fark var. Weaviate, vektör benzerliğini ve BM25'i tek bir sorguda birleştirebilme yeteneğiyle öne çıkar — hibrit aramayı ürünün kalbine koymuştur. Bu, özellikle çok kriterli, terim-yoğun kurumsal sorgularda hayat kurtarır. Milvus ve Qdrant da hibrit desteği sunar ama Weaviate'in bu alandaki olgunluğu belirgindir. pgvector tarafında hibrit arama mümkündür ama Postgres'in tam metin arama (full-text search) altyapısını elle birleştirmeniz gerekir; entegre değildir, ama Postgres zaten elinizdeyse bu bir avantaja dönüşebilir.

Tek bir sunucuda çalışan bir vektör veritabanı, POC (kavram kanıtı) için harikadır ama üretimde iki soru sizi bekler: ya sunucu çökerse (yüksek erişilebilirlik) ve ya veri tek makineye sığmazsa (yatay ölçek)?

• Çoğaltma (replication): Aynı veriyi birden fazla düğümde tutmak. Biri düşerse diğeri devralır. Aynı zamanda okuma yükünü dağıtır.
• Sharding (parçalama): Veriyi mantıksal parçalara bölüp farklı düğümlere dağıtmak. Milyarlarca vektörünüz varsa tek makineye sığmaz; sharding zorunlu hale gelir.

Bu noktada Milvus ayrışır. Milvus, hesaplama ve depolamayı ayıran, Kubernetes üzerinde çalışan, sharding ve replication'ı ciddiye almış dağıtık bir mimariye sahiptir. Milyarlarca vektör ölçeğinde ve GPU hızlandırmasıyla parlar. Ama bunun bir bedeli var: Milvus'u üretimde doğru çalıştırmak gerçek bir operasyon ekibi ister. Sahada gördüğüm en büyük hatalardan biri, aslında 5 milyon vektörü olan bir ekibin Milvus kümesi kurup altında ezilmesidir. Ölçeğiniz gerektirmiyorsa Milvus'un karmaşıklığını taşımayın.

Qdrant ve Weaviate de dağıtık modda çalışır ve çoğu kurumsal ihtiyaç için fazlasıyla yeter. pgvector ise Postgres'in çoğaltma mekanizmalarını miras alır — ki bu, mevcut Postgres operasyon bilginizin doğrudan işe yaraması demektir, çoğu ekip için gizli bir süper güç.

Burada gözden kaçan bir maliyet daha var: tutarlılık modeli. Vektör veritabanınıza yeni belgeler eklediğinizde, bu belgeler ne kadar sürede aranabilir hale geliyor? Kimi sistemler anlık (real-time) indeksleme sunarken, kimileri toplu (batch) indeksleme yapar ve yeni veri saniyeler hatta dakikalar sonra aramaya girer. Sık güncellenen bir bilgi tabanınız varsa — diyelim günlük binlerce yeni belge — bu gecikme kullanıcı deneyimini doğrudan etkiler. Redis'in indeksleme hızında öne çıkması tam da bu senaryolar için önemli. Buna karşılık, verisi nadiren değişen bir arşiv ararken indeksleme hızı neredeyse hiç önemli değildir. Yani "hangi veritabanı daha iyi" sorusunun cevabı, verinizin ne sıklıkla değiştiğine göre bile değişir.

Şimdi piyasadaki başlıca sekiz oyuncuyu tek tek, dürüstçe konumlandıralım. Her birinin bir "kişiliği" var ve doğru seçim, sizin senaryonuzun o kişilikle ne kadar örtüştüğüne bağlı.

Pinecone — Yönetilen liderin rahatlığı. Pinecone tamamen yönetilen (fully managed) bir servistir. Sunucu, indeks, ölçekleme derdine hiç girmezsiniz; bir API çağırırsınız, gerisiyle onlar ilgilenir. Hız-kalite dengesi olgun, operasyon yükü neredeyse sıfır. Ama iki bedeli var: veriniz onların bulutunda yaşar (KVKK açısından kritik nokta) ve maliyet, ölçek büyüdükçe kendi sunucunuza göre pahalılaşabilir.

Qdrant — Rust tabanlı açık kaynak hız lideri. Qdrant, Rust ile yazılmış olmanın verdiği ham performansla öne çıkar. Benchmark'larda en düşük gecikmeleri o tutar. Açık kaynak, kendi sunucunuzda çalıştırabilirsiniz, filtreli arama olgunluğu çok iyi. Hız sizin için gerçekten önemliyse ve kontrolü elde tutmak istiyorsanız ilk bakacağınız yer burası.

Weaviate — Hibrit arama ve GraphQL. Weaviate'in ayırt edici özelliği hibrit aramayı (vektör + BM25) tek sorguda birleştirmesi ve GraphQL tabanlı zengin bir sorgu arayüzü sunması. Karmaşık, terim-yoğun kurumsal aramalarda güçlüdür.

Milvus — Devasa ölçeğin veritabanı. Milyarlarca vektör, GPU hızlandırma, dağıtık mimari. Büyük ölçekte parlar ama gerçek bir operasyon ekibi ister.

Chroma — Geliştirici deneyiminin lideri. Chroma, "beş dakikada başla" felsefesini benimser. Yerel geliştirmede, prototiplemede, küçük projelerde inanılmaz rahattır. Üretim ölçeğinde diğerleri kadar iddialı değildir ama bir fikri hızlıca denemek için eşsizdir.

pgvector — Postgres'e entegre varsayılan. Eğer zaten Postgres kullanıyorsanız (ki Türkiye'de çoğu kurum kullanıyor), pgvector bir eklentidir. Vektörleri, ilişkisel verilerinizin yanında, aynı veritabanında, aynı transaction içinde, aynı yedekleme ve erişim kontrolüyle tutarsınız. Bu entegrasyon, düşündüğünüzden çok daha büyük bir avantajdır.

Vertex Vector Search — GCP'nin çözümü. Google Cloud ekosistemindeyseniz, Vertex'in yönetilen vektör arama servisi doğal bir seçenektir. GCP servisleriyle sıkı entegre, ölçeklenebilir. Yönetilen olmanın rahatlığı ve veri egemenliği pazarlığı Pinecone'unkine benzer.

Vespa — Devasa ölçekli hibrit. Vespa, hem çok büyük ölçek hem de zengin hibrit sıralama (ranking) yetenekleri sunan, kökeni arama motorlarına dayanan güçlü bir platformdur. Karmaşıktır ama en zorlu, büyük ölçekli hibrit senaryolarda ciddi bir seçenektir.

Şimdi herkesin merak ettiği rakamlara gelelim. Ama baştan uyarayım: bu sayılar bir bağlamda ölçülmüştür (10 milyon vektör mertebesi, belirli donanım, belirli ayar) ve sizin gerçeğinizi birebir yansıtmayabilir. Yine de göreceli bir his verir.

Veritabanı	p50 gecikme	p99 gecikme (10M vektör)	Öne çıkan özellik
Qdrant	~4 ms (en düşük)	~12 ms (en düşük)	Rust tabanlı ham hız
Redis	~5 ms	—	En yüksek indeksleme hızı (~15k–40k vektör/sn)
Milvus	~6 ms (GPU ile)	~18 ms	GPU hızlandırma, devasa ölçek
Weaviate	—	~16 ms	Hibrit arama + GraphQL

Bu tablodan çıkaracağınız dersler şunlar:

• Qdrant gecikme şampiyonu. Hem p50'de (~4 ms) hem p99'da (~12 ms) en düşük değerleri o tutuyor. Rust tabanlı mimarinin meyvesi.
• Redis indeksleme hızında öne çıkıyor. ~5 ms p50 gecikmeyle birlikte, saniyede ~15 bin–40 bin vektör indeksleyebilen en yüksek yazma hızını sunuyor. Verinizi sık sık ve hızlı güncelliyorsanız bu önemli.
• Milvus GPU ile ~6 ms p50'ye iniyor ve devasa ölçekte GPU hızlandırmasının farkını gösteriyor.
• Weaviate ~16 ms p99 ile makul bir gecikmeyi hibrit arama yetenekleriyle birleştiriyor.

Ama işte kritik uyarı: 10 milyon vektörde 4 ms ile 18 ms arasındaki fark, çoğu kurumsal RAG uygulamasında kullanıcının fark edemeyeceği bir farktır. Çünkü asıl gecikme, embedding üretiminde ve LLM'in cevap yazmasında (saniyeler mertebesinde) yatar. Vektör aramanın 14 ms'lik farkı, toplam boru hattında gürültüde kaybolur. Bu yüzden benchmark'ları seçim kriterinizin merkezine koymak, sahada gördüğüm en yaygın hatadır.

Manşet rakamlar değilse, karar neye göre veriliyor? Sahada işe yarayan dört eksen şunlar:

1. Yönetilen mi, kendi sunucunda mı (managed vs self-host)? Bu genelde ilk ve en belirleyici sorudur. Operasyon ekibiniz yoksa, hızlı başlamak istiyorsanız, veriniz yurt dışına çıkabilirse — yönetilen (Pinecone, Vertex) rahatlık sunar. Kontrolü elde tutmak, maliyeti optimize etmek ve özellikle KVKK gereği veriyi yurt içinde tutmak zorundaysanız — kendi sunucunuzda çalışan açık kaynak (pgvector, Qdrant, Weaviate, Milvus) tek gerçekçi yoldur.

2. Ölçek katmanı. Yüz binler mi, milyonlar mı, on milyonlar mı, milyarlar mı? Bu eksen ürünleri doğal olarak eler. Milyarlarca vektör Milvus/Vespa dünyasıdır. On milyonlara kadar pgvector ve Qdrant rahatça yeter. Yüz binler seviyesinde Chroma bile yeter.

3. Hibrit arama derinliği. Sorgularınız terim-yoğun mu? Kanun maddeleri, ürün kodları, özel isimler mi arıyorsunuz? Öyleyse hibrit arama olmazsa olmaz ve Weaviate öne çıkar. Sorgularınız daha çok kavramsal/semantikse, saf vektör yeterli olabilir.

4. Ekibin mevcut veri platformu taahhütleri. Bu en çok göz ardı edilen ama pratikte en belirleyici eksen. Zaten Postgres'e yaslanmış bir ekipseniz, pgvector size sıfır yeni operasyon yükü getirir. GCP'de yaşıyorsanız Vertex doğaldır. Halihazırda Redis kullanıyorsanız, Redis'in vektör yetenekleri ayrı bir sistem kurmaktan sizi kurtarabilir. Yeni bir veritabanı, yeni bir operasyon disiplini, yeni bir yedekleme stratejisi, yeni bir öğrenme eğrisi demektir. Bunu hafife almayın.

Şimdi bu yazının Türkiye'ye özel en önemli kısmına geldik. Kurumsal bir RAG projesinde vektör veritabanı, embedding'lerinizi tutar. Ve embedding'ler masum sayılar değildir — belgelerinizin, müşteri kayıtlarınızın, iç yazışmalarınızın anlamsal özünü taşırlar. Yeterince embedding ve doğru teknikle, orijinal metnin önemli kısmı geri çıkarılabilir. Yani vektör veritabanınız, aslında hassas verinizin bir türevini barındırır.

Bu, KVKK açısından şu soruyu doğrudan gündeme getirir: bu veri nerede duruyor?

• Yönetilen bulut (Pinecone gibi): Veriniz çoğu zaman yurt dışındaki bir bölgede, üçüncü tarafın altyapısında yaşar. Yurt dışına veri aktarımı, KVKK'nın en hassas ve en çok idari para cezası çıkan başlıklarından biridir. Açık rıza, yeterlilik kararı ya da uygun güvencelerin varlığı gibi şartlar gerekir. Bir belediyenin, bir bankanın, bir sağlık kuruluşunun vatandaş verisini bu şekilde yurt dışına taşıması, çoğu zaman baştan reddedilecek bir mimaridir.
• Kendi sunucunuzda açık kaynak (pgvector, Qdrant, Milvus, Weaviate): Veri hiç kurum sınırından çıkmaz. Türkiye'deki bir veri merkezinde, kendi kontrolünüzdeki sunucularda durur. Veri egemenliği (data sovereignty) açısından bu, çoğu kamu ve düzenlenmiş sektör projesi için tek uyumlu seçenektir.

Sahadaki net tavsiyem: Eğer düzenlenmiş bir sektördeyseniz (kamu, finans, sağlık, telekom) veya vatandaş/müşteri verisiyle çalışıyorsanız, seçim penceresini baştan kendi sunucunuzda çalışan açık kaynak çözümlerle sınırlayın. Bu, Pinecone'un kötü olduğu anlamına gelmez — teknik olarak mükemmel bir üründür — ama sizin uyum bağlamınıza uymayabilir. Mimari kararı, teknik hayranlıkla değil, hukuki gerçeklikle verin.

Maliyet tarafında da TL bazında düşünün. Yönetilen servisler dolar/euro faturalandırır ve kur dalgalanması bütçenizi öngörülemez kılar. Kendi sunucunuzda çalışan açık kaynak bir çözümde, maliyetiniz büyük ölçüde kiraladığınız sunucunun TL bedelidir — daha öngörülebilir ve genelde ölçekte daha ucuz. Bir int8 kuantizasyonuyla belleği dörtte bire indirdiğinizde, bu doğrudan aylık sunucu faturanıza yansır.

Sahada tekrar tekrar gördüğüm bir hata var: ekipler daha ilk POC'de "en ölçeklenebilir, en hızlı, en havalı" vektör veritabanını kurmaya çalışıyor. Sonra haftalarca operasyonel karmaşıklıkla boğuşuyor, asıl işe — RAG kalitesine — hiç sıra gelmiyor.

Benim önerdiğim yol şu: basit başlayın.

Eğer zaten Postgres kullanıyorsanız ve ~50 milyon vektörün altındaysanız, pgvector ile başlayın. Neden?

• Sıfır yeni operasyon yükü. Yeni bir sistem, yeni bir yedekleme, yeni bir izleme kurmuyorsunuz. Postgres bilginiz doğrudan işe yarıyor.
• Aynı transaction, aynı erişim kontrolü. Vektörler ilişkisel verinizin yanında yaşıyor. Bir belgeyi silince embedding'i de aynı transaction'da gidiyor — tutarlılık bedava.
• KVKK dostu. Zaten kurum içi Postgres sunucunuzda, yurt içinde, kontrolünüzde.
• HNSW desteği olgun. Modern pgvector, HNSW indeksiyle onlarca milyon vektöre kadar makul gecikmeler verir.

Ne zaman mezun olursunuz? Şu sinyaller belirdiğinde:

"

Gecikmeleriniz kabul edilemez seviyeye çıktığında, vektör sayınız ~50 milyonu aştığında, ya da filtreli/hibrit arama ihtiyaçlarınız pgvector'ın konforlu bölgesini zorlamaya başladığında. İşte o zaman — ve ancak o zaman — Qdrant'a (hız için), Weaviate'e (hibrit için) ya da Milvus'a (devasa ölçek için) geçmeyi düşünün.

Bu "önce basit, sonra mezun ol" yaklaşımının güzelliği şu: embedding'leriniz taşınabilir. Vektörler nihayetinde sayı dizileridir; bir veritabanından diğerine taşımak, ilişkisel bir şemayı taşımaktan çok daha kolaydır. Yani pgvector ile başlamak sizi hapsetmez; sadece asıl işe — RAG kalitesine, doğru chunk'lamaya, iyi reranking'e — daha hızlı odaklanmanızı sağlar.

Bütün bu yazıyı tek bir işlem akışına indirgemek istersem, sahada müşterilerimle beraber yürüdüğüm karar çerçevesi şudur. Sırayla, yukarıdan aşağı cevaplayın:

1. Veri yurt dışına çıkabilir mi? Hayırsa (KVKK/düzenlenmiş sektör), yönetilen bulut seçeneklerini (Pinecone, Vertex) baştan eleyin. Kendi sunucunuzda açık kaynakla devam edin.

2. Zaten Postgres kullanıyor musunuz ve ~50M vektörün altında mısınız? Evetse, pgvector ile başlayın. Başka bir şeye gerek yok. Enerjinizi RAG kalitesine harcayın.

3. Ham hız ve düşük gecikme sizin için gerçekten kritik mi? (Yüksek trafikli, gecikmeye duyarlı bir üründe.) Evetse, Qdrant'a bakın — Rust tabanlı hız lideri.

4. Sorgularınız terim-yoğun mu, hibrit arama şart mı? (Kanun maddeleri, ürün kodları, özel isimler.) Evetse, Weaviate öne çıkıyor — vektör + BM25 tek sorguda.

5. Milyarlarca vektörünüz ve gerçek bir operasyon ekibiniz var mı? Evetse, Milvus (ya da Vespa) devasa ölçeğin ve GPU hızlandırmanın kapısını açar. Değilse, bu karmaşıklığı taşımayın.

6. Sadece hızlıca bir prototip mi deniyorsunuz? Chroma ile beş dakikada başlayın, üretim kararını sonra verin.

7. Belirli bir bulutun ekosistemine mi kilitlisiniz? GCP'deyseniz Vertex, mevcut Redis altyapınız varsa Redis'in vektör yetenekleri, ayrı sistem kurma yükünüzü ortadan kaldırabilir.

Bu yedi soruyu sırayla cevapladığınızda, çoğu zaman doğru veritabanı kendiliğinden ortaya çıkar. Ve dikkat edin: soruların hiçbiri "hangisi 2 ms daha hızlı" değil. Çünkü doğru seçim, manşet benchmark'larda değil — veri egemenliğinde, mevcut platform taahhütlerinizde, ölçek gerçeğinizde ve ekibinizin taşıyabileceği operasyon yükünde saklı. Vektör veritabanınızı bu gözle seçin, ve seçtiğiniz şeyin size RAG'ın asıl işine — kaliteli cevaplar üretmeye — odaklanacak zamanı bırakmasına izin verin.