Kurumsal RAG için Vektör Veritabanı Seçimi 2026: pgvector mı, dedicated çözüm mü?

TL;DR — Eğer zaten PostgreSQL kullanıyorsanız ve vektör sayınız birkaç milyonun altındaysa, 2026'da bile cevabınız büyük olasılıkla pgvector. Yeni bir servis kurmadan, aynı tabloda, ACID garantisiyle yola devam edebilirsiniz. Ama ölçeğiniz 50-100 milyon vektörü aşıyorsa, ağır metadata filtrelemeniz veya ciddi hibrit arama ihtiyacınız varsa, ya da p95 gecikmeniz kritik bir SLA'ya bağlıysa, Qdrant, Weaviate veya Milvus gibi dedicated bir çözüme geçmenin zamanı gelmiş olabilir. Pinecone operasyonel kolaylık sunar ama fatura kurumsal ölçekte hızla şişer. Türkiye'de KVKK ve veri yerleşimi (data residency) söz konusuysa, self-hosted seçenekler (pgvector, Qdrant, Milvus, Weaviate) genellikle en güvenli liman. Aşağıda bütün bunları sahadan örneklerle ve bir karar matrisiyle açıyorum.

Müşterilerimle yaptığım ilk toplantıların neredeyse hepsinde aynı soru geliyor: "Hangi vektör veritabanı en iyisi?" Ben de her seferinde aynı şeyi söylüyorum: Bu soru, "hangi araba en iyisi?" sorusu kadar anlamsız. Şehir içinde park yeri arayan biriyle, çocuklarını okula bırakan biriyle, off-road'a çıkan biri için "en iyi" farklı bir şey.

Vektör veritabanları da böyle. 2026'da elimizde olgunlaşmış, ciddi bir seçenek yelpazesi var: bir uçta PostgreSQL'in içine yerleşen pgvector, diğer uçta milyarlarca vektör için tasarlanmış Milvus. Aralarında Pinecone (tam yönetilen, sıfır ops), Qdrant (filtrelemede çok hızlı), Weaviate (hibrit aramada en güçlü hikaye) duruyor. Doğru cevap, sizin ölçeğinize, ekibinizin büyüklüğüne, regülasyon yükünüze ve şu an elinizde ne olduğuna bağlı.

Bu yazıda ben size hangi seçeneği seçeceğinizi tek bir cümleyle söylemeyeceğim, çünkü öyle bir cümle yok. Bunun yerine, kararı kendi başınıza verebilmeniz için ihtiyacınız olan çerçeveyi vereceğim. Sahada gördüğüm tipik tuzakları, faturayı şişiren detayları ve özellikle Türkiye bağlamında ihmal edilen KVKK boyutunu da işin içine katacağım.

Kısa bir tazeleme yapalım, çünkü kararın mantığını anlamak için bu şart. Kurumsal bir RAG (Retrieval-Augmented Generation) sisteminde akış kabaca şöyle: Şirketin dokümanlarını (sözleşmeler, prosedürler, ürün kılavuzları, destek kayıtları) parçalara bölersiniz, her parçayı bir embedding modeliyle sayı dizisine — yani vektöre — dönüştürürsünüz. Kullanıcı bir soru sorduğunda, sorusunu da aynı modelle vektöre çevirir ve veritabanından "bu soruya en yakın anlamdaki parçaları getir" dersiniz. O parçaları büyük dil modeline bağlam olarak verir, cevabı ona ürettirirsiniz.

İşte bu "en yakın anlamdaki parçaları getir" kısmı, vektör veritabanının işi. Teknik adıyla yaklaşık en yakın komşu araması (ANN — Approximate Nearest Neighbor). Milyonlarca vektör arasında, milisaniyeler içinde, anlamca en benzer olanları bulması gerekiyor. Bunu yaparken çoğunlukla HNSW (Hierarchical Navigable Small World) adlı bir indeks yapısı kullanılıyor; HNSW'nin güzel tarafı, arama karmaşıklığının vektör sayısıyla logaritmik büyümesi, yani milyarlarca vektörde bile teorik olarak iyi ölçeklenmesi. Ama "teorik olarak" derken bir parantez açmak lazım; pratikte bellek ve indeksleme süresi konusunda ciddi sınırlar var. Birazdan bu sınırlara geleceğiz.

Kritik nokta şu: Bir RAG sisteminin kalitesini sadece dil modeli belirlemez. Yanlış parçaları getiren bir retrieval katmanı, dünyanın en iyi modeline bağlandığında bile çöp üretir. Bu yüzden vektör veritabanı seçimi, sandığınızdan daha stratejik bir karar.

Gelelim işin en pragmatik tarafına. Çalıştığım kurumların ezici çoğunluğu zaten PostgreSQL kullanıyor. Müşteri verisi, sipariş kayıtları, kullanıcı tabloları... hepsi orada. Ve PostgreSQL'in pgvector eklentisi, vektörleri tam da bu verilerin yanına, aynı tabloya koymanıza izin veriyor.

Bunun ne kadar büyük bir avantaj olduğunu sahada görmeden tam anlayamıyorsunuz. Çünkü:

• Yeni bir servis yok. Ayrı bir vektör veritabanı kurmak, onu izlemek, yedeklemek, güncellemek, güvenliğini sağlamak — bunların hepsi operasyonel yük. pgvector ile bu yükün tamamı ortadan kalkıyor; zaten yönettiğiniz Postgres'in içinde her şey.
• ACID garantisi ve transaction tutarlılığı. Vektörünüz ile metadata'nız aynı transaction içinde güncelleniyor. Dedicated vektör veritabanlarının çoğunda bu tutarlılığı sağlamak için kendiniz dans etmeniz gerekiyor.
• SQL'in tüm gücü. Vektör benzerliğini, klasik WHERE koşullarıyla, JOIN'lerle, tarih filtreleriyle istediğiniz gibi birleştirebiliyorsunuz. Hibrit sorgular yazmak için ayrı bir DSL öğrenmeniz gerekmiyor.
• Maliyet. Eğer zaten Postgres'i ödüyorsanız, pgvector size ekstra sıfır lira. Bir araştırmaya göre pgvector'ı AWS üzerinde self-host etmek, karşılaştırılabilir iş yükleri için Pinecone'dan yaklaşık %75 daha ucuz çıkıyor.

Peki bedava öğle yemeği var mı? Tabii ki yok. pgvector, PostgreSQL'in ölçeklenme sınırlarını miras alıyor. Milyonlarca vektöre kadar gayet iyi çalışıyor, ama gerçekten devasa, yüksek boyutlu, milyar ölçekli veri setlerinde genellikle sharding stratejilerine ya da harici sistemlere ihtiyaç duyuyorsunuz.

Bir de bellek meselesi var ki bunu yeterince konuşmuyoruz. HNSW indeksi açgözlü bir yapı; iyi performans için indeksin sıcak (bellekte) kalması gerekiyor. Bir örneklemeye göre, halfvec(3072) tipinde 25 bin satır için HNSW indeksi 193 MB tutuyorsa, 10 milyon satırda bu yaklaşık 77 GB'a çıkıyor — ki bu çoğu sunucunun buffer pool'unun sıcak tutabileceğinin çok ötesi. İndeks belleğe sığmayınca diske düşersiniz ve gecikmeniz patlamaya başlar.

2026 itibarıyla bu tabloyu yumuşatan gelişmeler var. pgvectorscale (Timescale ekibinin geliştirdiği eklenti) ve DiskANN tabanlı indeksler, pgvector'ın belleğe sığmayan büyük veri setlerinde daha verimli çalışmasını sağlıyor. Hatta May 2025 benchmarklarında pgvectorscale'in 50 milyon vektörde %99 recall'da 471 QPS'e ulaştığı, aynı koşulda Qdrant'ın 41 QPS'inin yaklaşık 11 katı olduğu raporlandı. Bu sayılara dikkatle yaklaşmak lazım — benchmarklar daima konfigürasyona, donanıma ve veri dağılımına bağlıdır, bir pazarlama aracı olarak da kullanılabilir — ama gösterdiği yön net: pgvector ekosistemi artık "sadece küçük projeler için" damgasını ciddi biçimde sallıyor.

Şimdi madalyonun diğer yüzü. Bazı durumlarda pgvector'la inatlaşmak, kendinizi gereksiz yere zorlamak olur. Sahada "hadi artık ayrılalım" dediğim eşikler genelde şunlar:

1. Ölçek 50-100 milyon vektörü aşıyorsa. Araştırmalar oldukça tutarlı bir mesaj veriyor: bu eşiğin ötesinde, eklentiler purpose-built sistemlerin aşabildiği throughput ve gecikme sınırlarına çarpıyor. Mesela 5 milyon vektörde pgvector'ın p95 gecikmesi 80-140 ms bandına tırmanırken, Pinecone pod tabanlı dağıtımlarda 30 ms'nin altında kalabiliyor. Eğer kullanıcılarınıza saniyeler içinde cevap dönen bir asistan vaat ettiyseniz, bu fark hayati.

2. Gerçekten ağır metadata filtrelemeniz varsa. Burada Qdrant sahnede parlıyor. Qdrant'ın payload filtrelemesi cidden hızlı, çünkü filtreleme retrieval sonrası bir adım değil, indeksleme hattının bir parçası. Yani "sadece şu departmana ait, şu tarihten sonra yazılmış, şu etikete sahip dokümanlar arasında ara" dediğinizde, Qdrant graf içinde filtreleyerek büyük koleksiyonlarda öne çıkıyor. Pinecone ve Weaviate ağır metadata filtrelerinde yavaşlayabiliyor.

3. Ciddi hibrit aramaya ihtiyacınız varsa. Hibrit arama, yani vektör benzerliği ile klasik anahtar kelime aramasının (BM25) birleşimi, birçok üretim dağıtımında belirleyici özellik haline geldi. Burada en güçlü hikaye Weaviate'te; native hibrit arama ve zengin bir modül ekosistemi sunuyor. pgvector'da hibrit arama "SQL'de ne yazabiliyorsanız o" — en güçlüsü ama en manuel olanı.

4. Milyar ölçekli, yatay ölçeklenen bir mimariye ihtiyacınız varsa. Burası Milvus'un evi. Milvus baştan, okuma, yazma ve depolamanın bağımsız ölçeklenebildiği bir mimari için tasarlandı; 100 milyon vektörün üzerinde yatay ölçekleme için en olgun sharding ve partitioning'e sahip. Bedeli ise operasyonel karmaşıklık — Milvus'u Kubernetes üzerinde ayağa kaldırmak ve sağlıklı tutmak ciddi bir mühendislik işi.

5. Ekibiniz küçükse ve hız her şeyse, Pinecone. Pinecone tam yönetilen, satın al-bağlan tarzı bir çözüm. Erken aşama bir startup'ta, mühendislik ekibi küçükken, developer hızının altyapı maliyetinin önüne geçtiği durumlarda mantıklı. Ama unutmayın: kurumsal ölçekte aynı iş yükü self-hosted Qdrant veya Milvus'ta 5-10 kat daha ucuza mal olabiliyor.

Maliyet konusunu ayrı bir başlık altında konuşmak istiyorum, çünkü en çok burada sürpriz yaşanıyor. Yönetilen vektör veritabanlarının fiyatlandırma modelleri, ilk bakışta masum görünüp sonra faturayı 2.5-4 katına çıkarabilen kalemler içeriyor.

Güncel (2026) tabloya birkaç somut sayı koyalım — bunların hepsi yaklaşık ve konfigürasyona göre değişir, dolayısıyla kendi iş yükünüzle test etmeden bütçe bağlamayın:

Çözüm	Yaklaşık 10M vektör	Yaklaşık 100M vektör	Fiyatlandırma modeli
Pinecone Serverless	~70 USD/ay	700+ USD/ay	Depolama (0.30 USD/GB/ay) + write (4 USD/milyon) + read (16 USD/milyon)
Qdrant Cloud	~65 USD/ay	Ölçeğe göre, genelde Pinecone'dan ucuz	~0.28 USD/GB/ay, kredi tabanlı; 1 GB ücretsiz
Self-hosted pgvectorscale	~100-200 USD/ay (altyapı)	~300-500 USD/ay (altyapı)	Sadece çalıştırdığınız sunucu maliyeti
Self-hosted Qdrant/Milvus	Sunucu maliyeti	Sunucu maliyeti	SaaS "vergisi" ve sorgu başı ücret yok

Dikkat edilmesi gereken birkaç gerçek:

• Yönetilen servisler, 10M ölçeğinde self-hosted'a göre tipik olarak 1.5-3 kat daha pahalı; 100M'de bu fark 3-5 kata kadar açılabiliyor.
• Pinecone'un read/write unit modeli sinsi olabilir. Trafiğiniz arttıkça okuma birimleri faturayı sessizce büyütür; bir günde 10 milyon sorgu = 160 USD sadece okumadan. Yoğun bir asistanda bu hızla birikir.
• pgvector'ın "ekstra sıfır maliyet" avantajı, sadece zaten yeterince güçlü bir Postgres'iniz varsa geçerli. Vektörler için belleği şişirmek zorunda kalırsanız, o "bedava" giderek pahalılaşır.

Benim sahadaki kuralım basit: Önce kendi veriniz üzerinde, kendi sorgu profilinizle bir POC yapın, sonra fatura konuşun. Sağlayıcıların pazarlama sayfalarındaki örnek fiyatlar, sizin gerçek kullanımınızı neredeyse hiçbir zaman yansıtmaz.

Bu bölüm, çoğu uluslararası karşılaştırma yazısının atladığı ama benim müşterilerimle masada en çok konuştuğumuz konu. Türkiye'de bir kurumda RAG sistemi kuruyorsanız, teknik performanstan önce bir soruya cevap vermeniz gerekiyor: Bu veri nereye gidiyor?

Kurumsal RAG'in doğası gereği, en hassas verileri sisteme besliyorsunuz: çalışan özlük dosyaları, müşteri sözleşmeleri, finansal kayıtlar, sağlık verileri, hukuki yazışmalar. Bu veriler KVKK kapsamında kişisel veri içeriyorsa — ki büyük olasılıkla içeriyor — bunların nerede işlendiği, nerede saklandığı ve yurt dışına aktarılıp aktarılmadığı kritik bir mesele.

Buradaki temel ayrım şu:

"

Yönetilen (managed) SaaS vektör veritabanları, verinizi genellikle kendi bulut altyapılarında (çoğu zaman ABD veya AB bölgelerinde) işler. Bu, KVKK açısından yurt dışına veri aktarımı sorununu gündeme getirir ve ek hukuki yükümlülükler doğurabilir.

"

Self-hosted (kendi altyapınızda) çözümler ise veriyi hiç dışarı çıkarmadan, sizin kontrolünüzdeki sunucularda — hatta gerekirse fiziksel olarak şirket binanızdaki donanımda — tutmanıza imkân verir.

İyi haber şu: 2026'da self-hosted istiyorsanız seçenek bol. pgvector, Qdrant, Milvus ve Weaviate'in hepsi, yönetilen bir servise bağımlı olmadan kendi altyapınızda çalıştırılabiliyor. Compliance ihtiyacınıza göre kabaca şöyle bir haritalama yapabiliriz:

• Tek node, düşük operasyonel yük: Qdrant. Tek bir Docker binary'si, sub-30ms retrieval, sıfır dış veri çıkışı (egress) ve tam audit kontrolü. Sağlık, finans, savunma gibi mahremiyet-kritik uygulamalar için bare metal veya izole bir sunucuda Qdrant çok mantıklı; tek binary olması saldırı yüzeyini de küçültüyor.
• Milyar ölçek, kurumsal: Milvus'u Kubernetes üzerinde Helm ile. Bare metal'de Milvus çalıştıran bir finans kurumu, sınır ötesi veri aktarımı riskini tamamen ortadan kaldırabiliyor — veri fiziksel olarak binayı terk edemiyor.
• Çok kiracılı (multi-tenant) B2B SaaS: Weaviate, Kubernetes üzerinde, kiracı başına fiziksel indeks izolasyonu sağlıyor; kiracılar arası sorgu sızıntısı olmuyor.
• Zaten Postgres'iniz varsa ve veri egemenliği şart: pgvector. Veri zaten sizin kontrolünüzdeki veritabanında; vektörleri oraya eklemek, ayrı bir sisteme veri taşımak zorunda kalmamak demek. Türkiye bağlamında bunun değeri çok büyük.

Burada hukuki tavsiye vermediğimin altını çiziyorum — KVKK uyumu için mutlaka hukuk ekibinizle ve veri koruma görevlinizle çalışın. Ama mimari kararı verirken "self-hosted mı, managed mı?" sorusunun teknik olduğu kadar hukuki bir soru olduğunu baştan kabul edin. Çünkü yanlış bir başlangıç tercihi, üretime aldıktan sonra geri dönüşü çok pahalı bir borç yaratıyor.

Bir vektör veritabanını laptop'unuzda 10 bin vektörle denemek başka, onu 50 milyon vektörle, gerçek trafik altında, gece 3'te alarm çalmadan ayakta tutmak başka. Üretime alırken (production) tökezlenen tipik yerleri sıralayayım, çünkü karar verirken bunları da hesaba katmanız lazım:

İndeksleme süresi. HNSW iyi arama doğruluğu verir ama indeksleme süreleri uzun ve bellek tüketimi yüksek olabilir. 17 milyon vektör, 1536 boyutta bir HNSW indeksinin inşası saatlerce sürebiliyor. Verileriniz sık güncelleniyorsa bu ciddi bir operasyonel kısıt. Karar verirken "sadece arama hızı" değil, "yazma ve yeniden indeksleme maliyeti" de masada olmalı.

Bellek planlaması. Yukarıda değindim ama tekrar vurgulayayım: indeksiniz belleğe sığmıyorsa, en parlak benchmark sayıları size hiçbir şey ifade etmez. Üretim donanımınızı, indeksin sıcak kalacağı şekilde boyutlandırın. pgvector'da DiskANN, indeksiniz shared_buffers'ı aştığında doğru tercih olabiliyor.

Recall vs. hız dengesi. ANN'in "A'sı" yaklaşık demek. İndeks parametrelerini (HNSW'de ef_construction, ef_search, m) ayarlayarak hızı artırabilirsiniz ama recall düşer — yani bazı doğru sonuçları kaçırırsınız. RAG kalitesi doğrudan recall'a bağlı olduğu için bu ayar, bütün sistemin kalitesini belirleyen sessiz bir kol. Sahada gördüğüm en sık hata, hız için recall'ı feda edip sonra "asistan neden bazen aptallaşıyor?" diye şaşırmak.

Yedekleme, izleme, felaket kurtarma. Managed bir çözümde bunlar sağlayıcının işi. Self-hosted'da sizin. Bu, kararın görünmeyen maliyet kalemi. Küçük bir ekipseniz ve operasyon kapasiteniz darsa, managed'ın primini ödemek mantıklı olabilir. Büyük bir ekipseniz ve zaten Postgres/Kubernetes operasyonunuz olgunsa, self-hosted'ın tasarrufu çok cazip.

Bütün bu tartışmayı tek bir tabloda toplamaya çalışayım. Bunu bir başlangıç noktası olarak kullanın, dogma olarak değil:

Durumunuz	Önerilen yön	Neden
Zaten Postgres var, < ~5-10M vektör, ekstra servis istemiyorsunuz	pgvector	Sıfır ek operasyon, ACID, SQL hibrit, düşük maliyet
Postgres var ama veri büyüyor, belleğe sığmıyor	pgvector + pgvectorscale/DiskANN	Diske taşan büyük setlerde verimlilik
Ağır metadata filtreleme, 1-100M vektör, düşük gecikme şart	Qdrant	In-graph filtreleme, sub-30ms, self-host kolay
Güçlü hibrit arama (vektör + BM25), çok kiracılı SaaS	Weaviate	Native hibrit, kiracı izolasyonu
Milyar ölçek, yatay ölçekleme, büyük mühendislik ekibi	Milvus	Olgun sharding/partitioning, bağımsız ölçekleme
Küçük ekip, hız > maliyet, ops yükü istemiyorsunuz	Pinecone	Tam yönetilen, sıfır ops, hızlı başlangıç
KVKK / veri yurt içinde kalmalı, on-prem zorunlu	Self-hosted: pgvector, Qdrant, Milvus, Weaviate	Veri dışarı çıkmaz, tam kontrol

Ve sahadan birkaç pratik kural, tabloyu tamamlasın:

• Postgres'iniz varsa, kanıtın aksini gösterene kadar pgvector'la başlayın. Çoğu kurumsal RAG projesi, hayal edilenden çok daha küçük vektör hacmiyle yola çıkıyor. Önce sade başlayın, ölçek gerçekten geldiğinde göç edersiniz. Erken optimizasyon, vektör dünyasında da kötülüğün kaynağı.
• "Belki milyar vektöre çıkarız" diye Milvus'la başlamayın. O karmaşıklığı bugün omuzlamanın bedeli, muhtemelen hiç gelmeyecek bir ölçek için ödenen sigorta primidir. Ölçek geldiğinde göç teknik olarak yönetilebilir bir iştir.
• Yönetilen bir servis seçeceksiniz, faturayı gerçek trafiğinizle modelleyin. Read/write unit veya kredi tabanlı modellerde, demo'da masum görünen kalem üretimde fonu yer.
• KVKK sorusunu mimarinin ilk gününde sorun. Sonradan eklenen bir compliance kararı, baştan tasarlanmış bir mimariye göre kat kat pahalıdır.

Bana kalsa, 2026'da yeni bir kurumsal RAG projesine girerken yol haritam şöyle olurdu. Önce "zaten neyimiz var?" diye sorardım. Eğer kurumun olgun bir PostgreSQL operasyonu varsa — ki Türkiye'de çoğunlukla var — pgvector ile başlardım. Bir hafta içinde çalışan bir POC çıkarır, gerçek dokümanlarla, gerçek sorularla retrieval kalitesini ölçerdim. Çünkü asıl risk veritabanı seçiminde değil, retrieval kalitesinde; yanlış chunk'lama, kötü embedding modeli, ayarsız recall — sistemi asıl bunlar batırıyor.

POC çalışınca, iki soruyu net cevaplardım: Vektör hacmi nereye gidiyor (6 ay, 1 yıl)? Ve gecikme/filtreleme ihtiyaçları SLA'ya nasıl bağlanıyor? Eğer hacim 50 milyonu zorlamaya başlıyorsa, ağır filtreleme varsa veya hibrit arama belirleyici hale geliyorsa, o zaman Qdrant veya Weaviate'e göç planını masaya koyardım — ama planı, gerçek veri beni zorladığında, varsayımla değil. KVKK tarafında veri yurt içinde kalmak zorundaysa, baştan self-hosted ekseninde ilerler, managed seçenekleri ancak veri yerleşimini netleştirdikten sonra değerlendirirdim.

Özetin özeti: pgvector mı, dedicated mı sorusunun cevabı, sizin elinizdeki veriyle, ölçeğinizle ve regülasyon yükünüzle yazılır — benim ya da bir benchmark tablosunun cümlesiyle değil. Doğru hamle, en gösterişli aracı seçmek değil; en sade çalışan çözümle başlayıp, ölçek gerçekten kapıyı çaldığında soğukkanlılıkla göç etmektir.