# Vektör Veritabanı Karşılaştırması 2026: Pinecone, Weaviate, Qdrant, Milvus, pgvector > Source: https://sukruyusufkaya.com/blog/vektor-veritabani-karsilastirma-2026 > Updated: 2026-07-25T15:51:59.953Z > Type: blog > Category: yapay-zeka **TLDR:** 2026 vektör veritabanı rehberi: Pinecone, Weaviate, Qdrant, Milvus, pgvector karşılaştırma tablosu, karar çerçevesi, maliyet, KVKK ve 'önce pgvector' tavsiyesi. **TL;DR —** Vektör veritabanı seçimi, manşet benchmark'larla değil kararınızın boyutlarıyla yapılır: yönetilen mi self-host mu, hangi ölçek katmanı, hibrit arama derinliği ve mevcut veri platformunuza bağlılık. Kısa cevabım net: **birkaç milyon vektörün altındaki çoğu RAG iş yükü için önce pgvector ile başlayın.** Pinecone işletmesi en kolay yönetilen seçenek; Weaviate hibrit aramada ve gömme üreten yerleşik modüllerde güçlü; Qdrant en hızlı açık kaynak ve en cömert ücretsiz katman; Milvus ise milyar ölçekli aramaya ve ayrı bir ops ekibine ihtiyacınız yoksa gereğinden karmaşık. Bu yazıda beşini karşılaştırıyor, bir karar çerçevesi çiziyor, maliyet ile KVKK/veri ikametgahı boyutunu ve ölçeklenince göç stratejisini sahadan örneklerle ele alıyorum. ## Önce şu soruyu soralım: gerçekten vektör veritabanı mı lazım? Danışmanlık yaptığım ekiplerin belki yarısı, daha ilk gün "hangi vektör veritabanını kullanalım?" diye soruyor. Bense her seferinde bir adım geri atıp şunu soruyorum: kaç vektörünüz var, ne kadar hızlı büyüyecek, ve arama gecikmesi (latency) bütçeniz ne? Çünkü vektör veritabanı seçimi bir moda tercihi değil, bir mühendislik kararıdır ve yanlış katmanda başlamak size aylar kaybettirir. Sahadaki en yaygın hata, henüz elli bin dokümanı bile olmayan bir ekibin, milyar ölçekli dağıtık sistemler için tasarlanmış bir altyapıyı kurmaya çalışıp operasyonel karmaşıklığın altında ezilmesi. Tersi de doğru: gerçekten büyük ölçekte çalışan bir ekibin, tek düğümlü bir çözüme sıkışıp performans duvarına toslaması. Doğru cevap "en popüler olan" değil, "sizin ölçeğinize ve ekibinize uyan"dır. > Vektör veritabanı seçiminde en pahalı hata, benchmark tablosundaki en hızlı rakamı görüp onu seçmektir. Manşet benchmark'lar kontrollü koşullarda, sizin veri dağılımınızdan bağımsız üretilir. Kararınızı hız rakamıyla değil, dört gerçek boyutla verin. ## Kararın dört boyutu Yıllardır bu kararı verirken kullandığım çerçeve dört eksene dayanıyor. Hız, bu eksenlerin sadece biri; ve çoğu zaman en az belirleyici olanı. - **Yönetilen mi, self-host mu?** Altyapı yönetecek bir ekibiniz var mı? Yoksa tam yönetilen bir servise para ödeyip mühendislik yükünden kurtulmak mı istiyorsunuz? Bu, bütçe kadar ekip olgunluğuyla da ilgili. - **Ölçek katmanı.** Binlerce mi, milyonlarca mı, yoksa milyarlarca vektör mü? Katmanlar arasında sıçrama, tamamen farklı mimarileri gerektirir. Bir milyonun altı ile bir milyarın üstü, aynı sorunun farklı gezegenleridir. - **Hibrit arama derinliği.** Sadece anlamsal (vektör) arama mı yetiyor, yoksa anahtar kelime (keyword) aramasıyla birleşen hibrit aramaya mı ihtiyacınız var? Kurumsal doküman aramasında hibrit arama çoğu zaman şart; çünkü kullanıcı bir ürün kodunu ya da özel bir terimi tam eşleşmeyle arar. - **Mevcut veri platformuna bağlılık.** Zaten PostgreSQL mi kullanıyorsunuz? Veriniz nerede yaşıyor? Yeni bir sistem eklemek, bir bağımlılık daha, bir yedekleme stratejisi daha, bir güvenlik yüzeyi daha demektir. Mevcut yığınınıza yaslanmak çoğu zaman en akılcı yoldur. ## Beş oyuncu, tek tek ### Pinecone — işletmesi en kolay Pinecone, tam yönetilen ve kapalı kaynak bir servis. Otomatik ölçeklenir, siz sadece API çağırırsınız; sunucu, indeks bakımı, yük dengeleme gibi dertler sizin değil. Eğer bütçeniz varsa ve altyapı yönetmeye hiç niyetiniz yoksa, Pinecone hayatınızı basitleştirir. Bedeli iki türlü: doğrudan maliyet (kullanım başına ücret, USD bazında) ve kapalı kaynak olmanın getirdiği bağımlılık (vendor lock-in). Verinizin üçüncü taraf bir bulutta yaşamasının, KVKK açısından ayrı bir değerlendirme gerektirdiğini de aklınızda tutun. ### Weaviate — hibrit aramanın kralı Weaviate'in iki güçlü yanı var. Birincisi, **hibrit arama** konusunda en olgun seçeneklerden biri: vektör ve anahtar kelime aramasını doğal biçimde harmanlar. İkincisi, **gömme (embedding) üreten yerleşik modüller**: ham metni verirsiniz, Weaviate onu sizin için vektörleştirir. Bu, boru hattınızda ayrı bir embedding servisi çalıştırma yükünü ortadan kaldırır; küçük ekipler için ciddi bir kolaylık. Kurumsal, karışık (metin + anahtar kelime) aramanın ağır bastığı senaryolarda Weaviate'i öne çıkarırım. ### Qdrant — en hızlı açık kaynak, en iyi ücretsiz katman Qdrant, açık kaynak dünyasında hem performans hem de erişilebilirlik açısından öne çıkıyor. Ölçümlerde genellikle en hızlı açık kaynak seçenek; kabaca yüzde 10-25 daha hızlı olabiliyor. Somut bir örnek vermek gerekirse, 10 milyon vektörlük bir kurulumda p99 gecikmesi Qdrant'ta yaklaşık 12 ms iken, Weaviate'te yaklaşık 16 ms, Milvus'ta yaklaşık 18 ms seviyesinde ölçülebiliyor. Üstelik en cömert ücretsiz katmanlardan birini sunar; prototip ve orta ölçek için nefes aldırır. Rust ile yazılmış olması, bellek verimliliği ve öngörülebilir performans açısından hoşuma gidiyor. Self-host etmek isteyen ama operasyonel yükü düşük tutmak isteyen ekipler için tatlı bir orta nokta. ### Milvus — milyar ölçek, ama dikkatli olun Milvus, milyar ölçekli vektör aramasına gerçekten ihtiyaç duyan ekipler için tasarlanmış, ağır silah bir sistem. Dağıtık mimarisi devasa ölçeklerde parlar. Ama bu gücün bir bedeli var: **operasyonel karmaşıklık**. Milvus'u sağlıklı işletmek çoğu zaman ona ayrılmış bir ops/altyapı ekibi gerektirir. Tavsiyem net: milyar ölçekli aramaya ve bunu besleyecek bir ekibe gerçekten ihtiyacınız yoksa Milvus'tan kaçının. Gücünü kullanamayacağınız bir sistemin karmaşıklığını taşımak, kazanç değil yüktür. ### pgvector — çoğu RAG iş yükünün gizli kahramanı Ve geldik benim çoğu ekibe ilk önerdiğim seçeneğe: **pgvector**. Bu, PostgreSQL'e vektör arama yeteneği ekleyen bir eklenti. Sihri şurada: embedding'lerinizi, dokümanlarınızı ve meta verilerinizi *tek bir Postgres içinde* tutar; ve hepsini tanıdık SQL ile, hatta join'lerle sorgularsınız. Birkaç milyon vektörün altındaki çoğu RAG iş yükü için en güçlü seçim budur. Neden? Çünkü zaten Postgres'i biliyorsunuz, zaten yedekliyorsunuz, zaten güvenliğini kurmuşsunuz. Yeni bir sistem, yeni bir bağımlılık eklemeden RAG'i hayata geçirirsiniz. "Vektör verisi ayrı bir yerde, meta veri başka yerde" senkronizasyon derdi de yok; her şey tek işlem (transaction) içinde tutarlı. ## Karşılaştırma tablosu | Veritabanı | Model | En güçlü yönü | Ne zaman seçmeli | |---|---|---|---| | pgvector | Postgres eklentisi (self-host / yönetilen Postgres) | Tek Postgres'te embedding+doküman+metadata, SQL join | Birkaç milyon vektörün altındaki çoğu RAG; zaten Postgres kullanıyorsanız | | Qdrant | Açık kaynak (self-host / bulut) | En hızlı açık kaynak, en cömert ücretsiz katman | Düşük ops yüküyle self-host; hız kritik; bütçe dar | | Weaviate | Açık kaynak (self-host / bulut) | En iyi hibrit arama, yerleşik embedding modülleri | Vektör+anahtar kelime hibrit arama ağır basıyorsa | | Pinecone | Kapalı kaynak, tam yönetilen | İşletmesi en kolay, otomatik ölçekleme | Bütçe var, altyapı yönetmek istemiyorsanız | | Milvus | Açık kaynak, dağıtık | Milyar ölçekli arama | Gerçekten milyar ölçek ve ayrı ops ekibiniz varsa | ## Karar çerçevesi: adım adım akış Sahada bir ekiple otururken kabaca şu akışı takip ediyorum. Bunu bir karar ağacı gibi düşünün. **Adım 1 — Ölçeğinizi netleştirin.** Bugün kaç vektörünüz var, 12 ay sonra ne olacak? Eğer tahmininiz birkaç milyonun altındaysa, doğrudan **pgvector**'e bakın. Bu eşik altında çoğu ekip için ayrı bir vektör veritabanı kurmak gereksiz karmaşıklıktır. **Adım 2 — Mevcut yığınınıza bakın.** Zaten PostgreSQL kullanıyorsanız, pgvector kararı neredeyse kendiliğinden verilir; yeni bağımlılık sıfır. Postgres yoksa ve self-host'a açıksanız, **Qdrant** güçlü bir başlangıç. **Adım 3 — Hibrit arama ihtiyacınızı ölçün.** Kullanıcılarınız tam-eşleşme (ürün kodu, özel terim, isim) ile mi arıyor? Anlamsal aramayla anahtar kelimeyi ciddi biçimde harmanlamanız gerekiyorsa, **Weaviate** öne çıkar. (pgvector de tam-metin aramayı destekler; orta düzey hibrit ihtiyaçlarını çoğu zaman karşılar.) **Adım 4 — Ekip ve bütçe gerçeğinizi kabul edin.** Altyapı yönetecek kimse yok, bütçe var mı? **Pinecone**. Milyar ölçek ve buna adanmış bir ekip var mı? **Milvus**. Bu iki uç dışında kalan çoğu ekip, ilk üç seçenekten birinde karar kılar. **Adım 5 — Veri ikametgahını sorgulayın.** Verileriniz Türkiye'de ya da kurum içinde kalmak zorunda mı? Öyleyse yönetilen bulut seçenekleri elenebilir; on-prem **pgvector** veya **Qdrant** öne çıkar. ## Maliyet ve KVKK: es geçilemez ikili ### Maliyet Yönetilen servislerin (Pinecone, Weaviate Cloud, Qdrant Cloud) faturaları USD bazındadır. Türkiye'deki kurumlar için bu, döviz kuru dalgalanmasına açık bir gider kalemi demek; bütçe planlarken kur riskini mutlaka hesaba katın. Self-host çözümlerde (pgvector, Qdrant, Milvus) doğrudan lisans maliyeti yoktur ama donanım, bakım ve mühendislik zamanı maliyeti vardır. Küçük-orta ölçekte, mevcut Postgres'inize pgvector eklemek çoğu zaman marjinal maliyetle RAG'i hayata geçirmenin en ucuz yoludur; yeni bir sunucu, yeni bir servis, yeni bir fatura kalemi eklemezsiniz. ### KVKK ve veri ikametgahı Bu, Türkiye bağlamında en kritik boyut ve maalesef en sık atlanan. Birkaç somut nokta: - **Veri ikametgahı (data residency):** RAG boru hattınıza koyduğunuz dokümanlar sıklıkla kişisel veri içerir (müşteri sözleşmeleri, destek kayıtları, İK belgeleri). Bu vektörlerin ve ham metnin nerede tutulduğu KVKK açısından belirleyicidir. Yurt dışındaki bir yönetilen buluta veri aktarmak, yurt dışına veri aktarım kurallarını devreye sokar. On-prem pgvector veya Qdrant, veriyi kurum içinde tutarak bu sorunu kökten çözer. - **Erişim kontrolü:** Kurum içi doküman aramasında herkesin her dokümanı görmemesi gerekir. Meta veriyle filtreleme (metadata filtering) burada kritik: kullanıcının yetkisine göre arama sonuçlarını kısıtlayabilmelisiniz. pgvector'ün SQL join'leri bu tür satır düzeyli erişim kontrolünü doğal biçimde yapmanızı sağlar; bu, sahada hafife alınan ama çok değerli bir avantaj. - **Silme ve saklama:** KVKK'nın "unutulma hakkı" ve saklama süresi ilkeleri, bir kaydı sildiğinizde onun vektör temsilinin de silinmesini gerektirir. Vektör ve kaynak veri ayrı sistemlerdeyse bu senkronizasyon bir risk; tek Postgres'te tutmak silme işlemini tek transaction'a indirger. ## "Önce pgvector ile başla" — neden bu kadar ısrarcıyım? Bir kuruma girip RAG kurarken varsayılan önerim neredeyse her zaman pgvector'dür ve bunun pragmatik bir gerekçesi var. Çoğu ekip, kendi ölçeğini abartır. "Milyonlarca dokümanımız olacak" diye başlayan projelerin büyük kısmı, altı ay sonra hâlâ birkaç yüz bin vektördedir. Bu ölçekte pgvector fazlasıyla yeter; hem de tek bir yeni sistem eklemeden. pgvector ile başlamanın üç somut kazancı: - **Sıfır yeni operasyonel yük.** Zaten işlettiğiniz Postgres'e bir eklenti kurarsınız. Yeni yedekleme, yeni izleme, yeni güvenlik yüzeyi yok. - **Bütünsel sorgu.** Embedding, doküman metni ve meta veri tek yerde; erişim kontrolü ve filtreleme SQL'le doğal. - **Basit tutarlılık.** Silme, güncelleme, senkronizasyon tek transaction içinde; iki sistem arasında veri kayması derdi yok. > Sahadaki mottom şu: "En iyi vektör veritabanı, ekibinizin zaten işletmeyi bildiği veritabanıdır." Çoğu Türk kurumunda bu Postgres'tir. Karmaşıklığı, ancak ölçüp gerektiğine ikna olduğunuzda satın alın. ## Ölçeklenince: göç stratejisi Peki ya gerçekten büyürseniz? pgvector'ün de bir tavanı var; birkaç-on milyon vektörün ötesinde, ANN indeks performansı ve bellek yönetimi zorlaşmaya başlar. İyi haber şu: pgvector ile başlamak sizi bir yere hapsetmez, çünkü göç yolu nettir. - **Erken sinyaller.** p99 gecikmeniz bütçenizi aşmaya başladıysa, indeks yeniden oluşturma süreleri kabul edilemezse, ya da bellek baskısı Postgres'inizin diğer işlerini etkiliyorsa, göç zamanı yaklaşıyor demektir. - **İlk durak genelde Qdrant.** Self-host kalmak istiyorsanız ve hız kritikse, pgvector'den Qdrant'a geçmek doğal bir adım. Embedding modeliniz aynı kaldığı için vektörlerinizi yeniden hesaplamanıza gerek yok; sadece indeksi yeni sisteme taşırsınız. - **Hibrit arama ağırlaştıysa Weaviate.** İhtiyacınız hızdan çok zengin hibrit aramaya kaydıysa, Weaviate'e geçmek mantıklı olabilir. - **Milyar ölçeğe dayandıysanız Milvus.** Bu noktaya gelen ekip zaten ayrı bir altyapı ekibine sahip olmalıdır; değilse önce o ekibi kurun, sonra Milvus'u. Göçü kolaylaştıran en önemli mimari karar, uygulama kodunuzu vektör veritabanının arkasına bir soyutlama katmanı (repository/adapter deseni) koyarak yazmaktır. Böylece pgvector'den Qdrant'a geçiş, tek bir arayüz uygulamasını değiştirmeye iner; iş mantığınıza dokunmazsınız. ## Üretim notları: sahadan pratik uyarılar Hangi veritabanını seçerseniz seçin, üretimde başınızı ağrıtacak ortak noktalar var. Biriktirdiğim notlar: - **Embedding modeli, veritabanından daha önemlidir.** Arama kalitenizi asıl belirleyen, hangi embedding modelini kullandığınızdır; veritabanı sadece o vektörleri saklayıp arar. Türkçe içerikte, Türkçeyi iyi temsil eden bir embedding modeli seçmek, veritabanı seçiminden daha çok fark yaratır. - **İndeks parametrelerini ayarlayın.** HNSW gibi ANN indekslerinin ayarları (ör. bağlantı sayısı, arama derinliği), hız ile geri-çağırma (recall) arasında bir denge kurar. Varsayılanlarla başlayın ama kendi verinizle ölçüp ayarlayın. - **Meta veri filtrelemeyi baştan tasarlayın.** Erişim kontrolü ve tarih/kategori filtrelerini sonradan eklemek acı vericidir. Şemanızı bunları düşünerek kurun. - **Yeniden indeksleme maliyetini hesaba katın.** Embedding modelinizi değiştirirseniz tüm vektörleri yeniden hesaplamanız gerekir; bu, milyonlarca dokümanda ciddi bir zaman ve maliyet kalemidir. Model seçimini erken ve dikkatli yapın. - **Geri-çağırmayı ölçün, sadece hızı değil.** Hızlı ama yanlış sonuç veren bir arama işe yaramaz. Kendi veri setinizde bir değerlendirme kümesi oluşturup geri-çağırma/isabet metriklerini düzenli ölçün. - **Yedekleme ve felaket kurtarma.** Vektör indeksiniz de bir veridir; yedekleme ve kurtarma planınıza dahil edin. pgvector'de bu zaten Postgres yedeğinizin parçasıdır; ayrı sistemlerde ayrı plan gerekir. Bu kararı verirken kendinize sürekli sormanız gereken tek soru şu: "Bu sistemi altı ay sonra, gece yarısı bir sorun çıktığında, kim ve nasıl ayağa kaldıracak?" Cevabı en net olan seçenek, çoğu zaman en doğru seçenektir. Teknolojiyi ölçeğinize göre değil, hevesinize göre seçerseniz, o karmaşıklığın bedelini üretimde ödersiniz. ## Sahadan bir vaka: 400 bin dokümanlı bir sigorta şirketi Somutlaştırmak için gerçek bir senaryoyu (detaylar anonimleştirilmiş) paylaşayım. Bir sigorta şirketi, poliçe belgeleri, hasar dosyaları ve iç prosedür dokümanlarından oluşan yaklaşık 400 bin dokümanlık bir arşiv üzerinde çalışan bir soru-cevap asistanı istiyordu. İlk toplantıda ekibin ön kabulü şuydu: "Bu ölçek için mutlaka ciddi bir vektör veritabanı, belki Milvus lazım." Oturup dört boyutu birlikte gözden geçirdik. Ölçek: 400 bin doküman, chunk'lara bölününce belki birkaç milyon vektör; ama birkaç yılda bile milyar sınırına yaklaşmıyor. Mevcut yığın: kurum zaten kritik verilerini PostgreSQL'de tutuyordu. Hibrit arama: poliçe numaraları ve özel terimler için tam-eşleşme gerekiyordu ama ileri düzey değil. Veri ikametgahı: sigorta verisi kişisel veri barındırdığı için yurt içinde, tercihen kurum içinde kalmalıydı. Bu dört cevap, kararı neredeyse kendiliğinden verdirdi: **pgvector, on-prem PostgreSQL üzerinde.** Poliçe numarası araması için Postgres'in tam-metin arama yeteneğini vektör aramayla birleştirdik; erişim kontrolünü, kullanıcının departmanına göre satır düzeyinde SQL filtresiyle kurduk. Sonuç: yeni bir sistem, yeni bir fatura, yeni bir güvenlik denetimi olmadan, altı hafta içinde üretime çıkan bir RAG asistanı. Ekip başta "bu kadar basit mi?" diye şaşırdı; sahada en iyi mimarilerin çoğu zaman en sıkıcı görünenler olduğunu bir kez daha teyit ettik. ## Vektör veritabanı, RAG boru hattının sadece bir parçası Burada altını çizmem gereken bir yanılgı var: ekipler enerjilerinin çoğunu vektör veritabanı seçimine harcarken, arama kalitesini asıl belirleyen diğer halkaları ihmal ediyor. Vektör veritabanı, bir RAG boru hattının yalnızca bir bileşeni; ve dürüst olmak gerekirse çoğu zaman en az fark yaratanı. Kaliteli bir RAG için asıl belirleyici halkalar: - **Parçalama (chunking):** Dokümanları nasıl böldüğünüz, arama kalitesini doğrudan etkiler. Çok küçük parçalar bağlamı kaybettirir, çok büyük parçalar gürültü katar. Türkçe metinlerde cümle ve paragraf sınırlarına saygılı bir parçalama, isabeti belirgin artırır. - **Embedding modeli:** Yukarıda da söyledim ama tekrar vurgulayayım: Türkçeyi iyi temsil eden bir embedding modeli, veritabanı seçiminden çok daha fazla fark yaratır. Çok dilli modeller Türkçede değişken performans gösterebilir; kendi verinizle test edin. - **Yeniden sıralama (reranking):** Vektör araması ilk aday kümesini getirir; bir reranker modeli bu adayları sorguya uygunluğa göre yeniden sıralayarak isabeti ciddi artırır. Küçük bir ek gecikmeyle büyük kalite kazancı; sahada en çok tavsiye ettiğim iyileştirmelerden biri. - **Sorgu genişletme ve filtreleme:** Kullanıcının ham sorgusunu iyileştirmek, meta veriyle önceden filtrelemek, sonuçları belirgin düzeltir. Yani "hangi vektör veritabanı" sorusuna takılıp kalmadan önce, bu halkaların her birine hak ettiği ilgiyi verin. Mükemmel bir vektör veritabanı, kötü parçalama ve zayıf bir embedding modelini kurtaramaz. ## Hibrit arama neden bu kadar önemli? Kurumsal doküman aramasında hibrit aramanın neden sık sık şart olduğunu biraz açayım, çünkü bu boyut kararı gerçekten değiştirir. Salt anlamsal (vektör) arama, "anlamca benzer" içerikleri bulmakta harikadır; ama tam-eşleşme gereken durumlarda tökezler. Bir kullanıcı "POL-2024-88231" numaralı poliçeyi ararsa, anlamsal arama bu kodu "anlamaz"; ona benzer sayı dizileri getirebilir. Oysa anahtar kelime araması bu tam-eşleşmeyi kusursuz yakalar. Hibrit arama, iki dünyanın en iyisini birleştirir: anlamsal aramanın kavramsal esnekliği + anahtar kelime aramasının tam-eşleşme kesinliği. Sonuçlar genellikle bir birleştirme algoritmasıyla (ör. karşılıklı sıra füzyonu, reciprocal rank fusion) harmanlanır. | Senaryo | Salt vektör | Salt anahtar kelime | Hibrit | |---|---|---|---| | "İş kazası tazminatı nasıl hesaplanır?" | Güçlü | Zayıf | Güçlü | | "POL-2024-88231 poliçesi" | Zayıf | Güçlü | Güçlü | | "Deprem hasarında muafiyet var mı?" | Güçlü | Orta | Çok güçlü | Tablodan da görüleceği gibi, gerçek kurumsal kullanımda sorgular her iki türü de içerir. Bu yüzden Weaviate'in hibrit aramadaki olgunluğu bazı senaryolarda gerçek bir ayırt edici olabilir; pgvector'ün tam-metin + vektör kombinasyonu ise orta düzey ihtiyaçları çoğu zaman rahatça karşılar. ## Sık karşılaştığım sorular **"pgvector gerçekten 'gerçek' bir vektör veritabanı mı?"** Bu itirazı çok duyuyorum. Cevap: pgvector, Postgres'e HNSW gibi modern ANN indeksleri getiren olgun bir eklenti; birkaç milyon vektör ölçeğinde çoğu iş yükü için fazlasıyla yeterli. "Gerçek vektör veritabanı" tartışması çoğu zaman gereksiz bir saflık takıntısı; önemli olan işinizi görmesi. **"Birden fazla veritabanını aynı anda kullanabilir miyim?"** Teknik olarak evet ama genellikle önermem; her ek sistem, ek operasyonel yük ve ek tutarsızlık riski demek. Sadeliği, ölçüp gerçekten gerekene ikna olmadan bozmayın. **"Bulut mu, on-prem mi daha ucuz?"** Küçük-orta ölçekte, zaten Postgres işletiyorsanız on-prem pgvector neredeyse her zaman daha ucuzdur. Çok büyük ve değişken yüklerde, yönetilen bir servisin otomatik ölçeklemesi mühendislik zamanından tasarruf ettirebilir. KVKK/veri ikametgahı gereksinimi varsa denklem zaten on-prem lehine kayar. **"Hangi embedding boyutunu seçmeliyim?"** Daha yüksek boyut her zaman daha iyi değildir; depolama ve arama maliyetini artırır. Türkçe verinizle küçük bir değerlendirme yapıp isabet/maliyet dengesini kendiniz ölçün. ## İndeksleme sezgisi: neden HNSW ve neyi feda ediyoruz? Vektör veritabanı seçerken çoğu ekibin gözden kaçırdığı bir gerçek: bu sistemler aslında her aramada tüm vektörleri tek tek karşılaştırmaz; öyle olsa milyonlarca vektörde arama saatler sürerdi. Bunun yerine **yaklaşık en yakın komşu (approximate nearest neighbor, ANN)** indeksleri kullanırlar. Buradaki "yaklaşık" kelimesi kilit önemde: hızı, mükemmel isabetten küçük bir taviz karşılığında satın alıyorsunuz. Bugün fiili standart HNSW (hiyerarşik gezinilebilir küçük dünya) indeksidir; pgvector, Qdrant, Weaviate ve diğerleri bunu destekler. HNSW, vektörleri katmanlı bir grafik olarak düzenler ve aramayı bu grafikte akıllıca gezinerek yapar. İki ayar sonucu belirler: grafik ne kadar zengin bağlanacak (inşa maliyeti ve bellek) ve arama ne kadar derin gezinecek (hız ile geri-çağırma dengesi). Pratik tavsiyem: varsayılan HNSW ayarlarıyla başlayın, sonra kendi verinizde bir geri-çağırma testi yapın. Eğer isabetiniz düşükse arama derinliğini artırın; eğer aramanız yavaşsa azaltın. Bu ayarı körlemesine değil, kendi Türkçe veri setinizde ölçerek yapın; her veri dağılımı farklı davranır. pgvector'ün eski IVFFlat indeksi hâlâ mevcut ama çoğu yeni proje için HNSW daha iyi bir varsayılan. > Vektör aramasında "yüzde 100 doğru sonuç" diye bir hedef peşinde koşmayın; ANN dünyasında zaten yaklaşık çalışıyorsunuz. Doğru soru şu: "Kabul edilebilir geri-çağırmayı, bütçemdeki gecikmeyle nasıl elde ederim?" ## Çok-kiracılılık ve güvenlik: kurumsal gerçekler Kurumsal projelerde neredeyse her zaman karşıma çıkan iki konu var: çok-kiracılılık (multi-tenancy) ve güvenlik. Eğer birden fazla müşteriye ya da birden fazla departmana hizmet veren tek bir sistem kuruyorsanız, bir kiracının verisinin asla başka bir kiracının aramasında görünmemesi kritik. Bunu iki yolla yaparsınız: ya her kiracı için ayrı bir koleksiyon/indeks, ya da tek indekste kiracı kimliğine göre meta veri filtresi. pgvector'ün buradaki avantajı, satır düzeyli güvenliği (row-level security) doğrudan Postgres'in olgun yetkilendirme mekanizmasıyla kurabilmenizdir; onlarca yıllık, savaş-testinden geçmiş bir güvenlik altyapısına yaslanırsınız. Qdrant ve Weaviate de kiracı bazlı filtrelemeyi destekler ama güvenlik modelini uygulama katmanında daha dikkatli kurmanız gerekir. Güvenlik tarafında bir başka atlanan nokta: embedding'lerin kendisi de hassas olabilir. Bir vektör, kaynak metnin anlamsal bir parmak izidir; bazı koşullarda tersine mühendislikle içeriğe dair ipuçları sızabilir. Bu yüzden vektör deposunu da, ham veri kadar ciddiye alıp erişimini kısıtlayın ve şifreleyin. ## Somut eylem planı Bir kurumda RAG kurarken önümüzdeki birkaç haftaya yayacağım somut adımlar şöyle: 1. **Ölçeği ve büyüme eğrisini ölçün.** Bugünkü doküman/vektör sayısı ve 12 aylık projeksiyon. Birkaç milyonun altındaysanız pgvector'ü varsayılan alın. 2. **Veri ikametgahı ve KVKK kararını verin.** Kişisel veri var mı, yurt içinde/kurum içinde kalmalı mı? Bu cevap yönetilen bulut seçeneklerini eleyebilir. 3. **Embedding modelini Türkçe verinizle test edin.** Veritabanından önce bunu netleştirin; asıl kalite buradan gelir. 4. **Parçalama stratejinizi kurun** ve küçük bir değerlendirme seti oluşturun (gerçek sorular + beklenen dokümanlar). 5. **pgvector ile bir pilot çıkarın.** Erişim kontrolünü ve meta veri filtrelemeyi baştan tasarlayın; bir soyutlama katmanı arkasına yazın. 6. **Geri-çağırma ve gecikmeyi ölçün.** Reranking ekleyerek kaliteyi artırmayı deneyin. 7. **Ölçekleme sinyallerini izleyin.** p99 gecikme, indeks yeniden oluşturma süresi, bellek baskısı. Sinyal gelmeden Qdrant/Weaviate/Milvus'a geçmeyin. Bu planın ruhu tek bir cümlede özetlenebilir: **karmaşıklığı erken değil, ölçüp gerektiğine ikna olduğunuzda satın alın.** Sahada gördüğüm en sağlıklı RAG mimarileri, en gösterişli olanlar değil; ekibin gece yarısı bir sorun çıktığında rahatça ayağa kaldırabildiği, sıkıcı ama sağlam olanlardır. Vektör veritabanı kararınızı da bu gözle verirseniz, hem bütçenizi hem de uykunuzu korursunuz. Unutmayın: doğru seçim, en yeni ya da en hızlı olan değil, sizin ekibinizin bugün güvenle işletip yarın rahatça ölçekleyebileceği olandır.