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

TL;DR — Vektör veritabanı seçimi bir "en iyi ürün" yarışması değil; ölçek, gecikme (latency), operasyonel olgunluk ve maliyet arasında verdiğiniz bir denge kararıdır. Sahadaki gözlemim net: 10 milyon vektöre kadar çoğu kurum için en akıllıca başlangıç pgvector'dür, çünkü zaten var olan Postgres'inize sıfır yeni altyapıyla vektör araması ekler. Düşük gecikme ve gelişmiş filtreleme istiyorsanız Rust ile yazılmış Qdrant öne çıkar (p50 ~4ms civarı). Milyar vektör ölçeğinde, GPU hızlandırma ve en zengin indeks yelpazesiyle Milvus devreye girer. Hiç altyapı yönetmek istemiyorsanız ve veri ikametgahı (data residency) sizin için sorun değilse Pinecone en pürüzsüz yönetilen seçenektir. Türkiye ve KVKK bağlamında ise self-hosted seçenekler (pgvector, Qdrant, Milvus) veri ikametgahı açısından yönetilen Pinecone'a göre elinizi güçlendirir. Aşağıda her birini dürüstçe, güçlü ve zayıf yanlarıyla, bir karar çerçevesiyle ve senaryolara göre bir seçim rehberiyle anlatıyorum. Tüm kıyaslama sayıları yönlendirici (directional) ve konfigürasyona bağlıdır; kendi verinizle, güncel sürümlerde yeniden ölçün.

Son iki yılda danışmanlık verdiğim neredeyse her kurumda aynı sahneyi gördüm: Bir ekip RAG (Retrieval-Augmented Generation) projesine heyecanla başlıyor, bir demo çalıştırıyor, sonra üretime geçme vakti geldiğinde "hangi vektör veritabanını kullanalım?" sorusunda takılıp kalıyor. İnternette çelişkili kıyaslamalar, her birinin kendini bir numara ilan ettiği pazarlama sayfaları, forumlarda birbirini yalanlayan tecrübeler... Sonuçta karar, çoğu zaman o hafta kimin blog yazısını okuduğuna ya da hangi satıcının en agresif e-postayı gönderdiğine kalıyor.

Bu yazıda amacım, o gürültüyü kesmek. Size "şu en iyisidir" demeyeceğim, çünkü öyle bir cevap yok. Bunun yerine, kendi kararınızı verebilmeniz için bir düşünme çerçevesi vereceğim. Dört ana oyuncuyu (pgvector, Qdrant, Milvus, Pinecone) sahadan gözlemlerimle, dürüst güçlü ve zayıf yönleriyle ele alacağım. En baştan bir uyarı: Buradaki tüm performans sayıları yönlendiricidir. 2026'da bu motorların hepsi büyük bir sürüm çıkardı; bir benchmark'ta gördüğünüz sayı, sizin donanımınızda, sizin veri dağılımınızda, sizin indeks ayarlarınızda tamamen farklı çıkabilir. O yüzden bu yazıyı bir "karar haritası" olarak okuyun, bir "kesin skor tablosu" olarak değil.

Vektör veritabanı seçimini bir mühendislik kararı olarak ele aldığınızda, dört eksen üzerinde düşünmeniz gerekir. Bu dört eksen, yazının geri kalanının da iskeletini oluşturuyor:

1. Ölçek (Scale): Kaç vektör saklayacaksınız? 1 milyon mu, 10 milyon mu, 1 milyar mı? Bu, en belirleyici tek faktör. Çünkü bir motorun 1 milyonda mükemmel çalışması, 500 milyonda da mükemmel çalışacağı anlamına gelmez. Ölçek büyüdükçe indeks yapısı, bellek yönetimi ve dağıtık mimari kritikleşir.

2. Gecikme ve Throughput (p99 latency & QPS): Kullanıcı bir sorgu attığında ne kadar sürede cevap dönmeli? Ortalama (p50) gecikme yanıltıcıdır; asıl önemli olan p99'dur, yani en yavaş yüzde birlik dilim. Aynı anda kaç sorguyu (QPS — queries per second) karşılamanız gerekiyor? Bir sohbet botu ile bir toplu (batch) analiz işi çok farklı gereksinimlere sahiptir.

3. Operasyonel Hazırlık (Operational readiness): Yüksek erişilebilirlik (HA), çok kiracılılık (multi-tenancy), rol tabanlı erişim kontrolü (RBAC), yedekleme, izleme... Bunları kim yönetecek? Ekibinizde bunu ayağa kaldıracak ve gece 3'te alarm çaldığında müdahale edecek insan var mı? Bu, çoğu kurumun hafife aldığı ama sonradan en çok yaktığı eksendir.

4. Maliyet (Cost): Sadece lisans veya abonelik değil; sunucu, bellek, mühendislik zamanı, bakım... Yönetilen bir servis ilk bakışta pahalı görünür ama kendi altyapınızı yönetmenin gizli maliyetini (özellikle mühendis saatini) genellikle unutuyoruz.

"

Sahadan bir tavsiye: Bu dört ekseni bir toplantıda beyaz tahtaya yazın ve her birine kendi projeniz için bir sayı ya da net bir cümle koyun. "Ölçek: 18 ay içinde 40 milyon vektör", "p99 hedefi: 50ms altı", "Ops: 2 kişilik platform ekibi var", "Bütçe: aylık X". Bu tabloyu doldurduğunuz an, dört seçenekten ikisi zaten elenmiş oluyor. Karar sandığınızdan kolaylaşıyor.

Şimdi bu çerçeveyi aklınızda tutarak dört motoru tek tek ele alalım.

pgvector, benim "önce buradan başla" dediğim seçenek. Neden? Çünkü çoğu kurumun zaten bir PostgreSQL veritabanı var. pgvector, bu mevcut Postgres'inize bir eklenti olarak vektör arama yeteneği ekliyor. Yani sıfır yeni altyapı. Yeni bir servis ayağa kaldırmıyorsunuz, yeni bir operasyonel yük almıyorsunuz, ekibinizin öğrenmesi gereken tamamen yeni bir sistem yok.

Güçlü yanları:

• Operasyonel sadelik. Zaten Postgres'i yönetiyorsanız, pgvector'ü de yönetiyorsunuz demektir. Yedekleme, replikasyon, izleme, erişim kontrolü — hepsi tanıdık araçlarla, tanıdık süreçlerle.
• ACID garantileri. Vektörlerinizi, ilişkisel verilerinizle (kullanıcı bilgileri, meta veriler, izinler) aynı transaction içinde tutarlı biçimde yönetebilirsiniz. Bu, birçok kurumsal senaryoda göz ardı edilen ama muazzam bir avantaj. Vektör ve iş verisi tek yerde, tek tutarlılık modeliyle.
• SQL ekosistemi. JOIN'ler, filtreler, mevcut sorgularınız... Hepsi olduğu gibi çalışıyor. Vektör aramasını normal bir SQL sorgusunun içine gömebiliyorsunuz.
• ~10 milyon vektöre kadar gayet iyi. Bu, dürüst olalım, kurumların büyük çoğunluğunun ihtiyacını fazlasıyla karşılayan bir ölçek.

Sınırları:

• Ölçek çok büyüdüğünde (onlarca-yüzlerce milyon vektör, yüksek eşzamanlı sorgu yükü) purpose-built (yalnızca vektör için tasarlanmış) motorların gerisinde kalabiliyor. Ham vektör throughput'unda özel motorlar daha ileride.
• Çok yüksek QPS gerektiren, saf vektör-yoğun iş yüklerinde Postgres'in genel amaçlı mimarisi bir tavan oluşturabiliyor.
• pgvectorscale gibi eklentiler bu tavanı ciddi şekilde yukarı çekiyor (aşağıda benchmark bölümünde buna değineceğim), ama bu da ek bir konfigürasyon ve öğrenme eğrisi demek.

"

Benim pratik kuralım: Eğer zaten Postgres kullanıyorsanız ve vektör sayınız öngörülebilir gelecekte 10 milyonun altında kalacaksa, başka bir şey aramadan pgvector ile başlayın. Prematüre bir şekilde özel bir vektör veritabanı kurmak, çözmediğiniz bir problem için operasyonel karmaşıklık satın almaktır. İhtiyaç doğduğunda göç edersiniz; o gün gelmeyebilir de.

Qdrant, purpose-built vektör veritabanları arasında benim en çok sevdiğim dengeyi kuran motor. Rust ile yazılmış olması, ona bellek güvenliği ve öngörülebilir, düşük gecikmeli performans kazandırıyor. Rakamlarla konuşursak: Qdrant, amaca yönelik vektör veritabanları arasında en düşük p50 gecikmelerinden birine sahip — yaklaşık 4ms civarında, p99 ise ~25ms seviyesinde. 10 milyon vektörlük bir kıyaslamada p99 tarafında Qdrant ~12ms, Weaviate ~16ms, Milvus ~18ms olarak ölçülmüş. Bu sayılar elbette konfigürasyona bağlı ve yönlendirici, ama Qdrant'ın gecikme tarafındaki karakterini iyi yansıtıyor.

Güçlü yanları:

• Düşük ve öngörülebilir gecikme. Rust'ın getirdiği performans, özellikle p99 gibi kuyruk gecikmelerinde (tail latency) kendini gösteriyor. Yaygın iş yüklerinde Weaviate ve Milvus'a göre ~%10–25 daha hızlı olabiliyor.
• Gelişmiş payload filtreleme. Bu, Qdrant'ın gerçek yıldızı. Vektör aramasını, meta veriler (payload) üzerindeki karmaşık filtrelerle birleştirmekte çok iyi. "Bu kategoride, şu tarihten sonra, şu kullanıcıya ait belgeler arasında en benzer 10 sonuç" gibi sorgular Qdrant'ın doğal alanı.
• Quantization (nicemleme) desteği. Bellek ayak izini ciddi biçimde düşürüp maliyeti optimize etmenizi sağlıyor. Skalar ve binary quantization ile büyük veri setlerini daha küçük belleğe sığdırabiliyorsunuz.
• Self-hosted çalıştırabildiğiniz gibi, Qdrant Cloud ile yönetilen bir seçenek de mevcut.

Sınırları:

• pgvector'e kıyasla yine de yeni bir servis; onu ayağa kaldırmak, izlemek, ölçeklemek ekibinize ek operasyonel yük getiriyor.
• Milyar-vektör ölçeğinde Milvus'un GPU hızlandırma ve indeks çeşitliliği avantajlarına sahip değil; o uç noktada Milvus daha uygun.

"

Qdrant'ı özellikle şu durumlarda öneriyorum: Karmaşık meta veri filtrelemesi ile vektör aramasını yoğun biçimde birleştiriyorsanız ve p99 gecikme sizin için kritik bir SLA maddesi ise. Filtreli arama tarafında sahadaki deneyimim çok olumlu.

Milvus, "büyük"ün ötesinde "devasa" ölçekten bahsettiğimizde masaya oturan motor. Eğer milyarlarca vektörle çalışıyorsanız — düşünün: dev bir e-ticaret kataloğunun tüm ürün embedding'leri, ulusal ölçekte bir görüntü arama sistemi, ya da devasa bir bilimsel makale/patent koleksiyonu — Milvus'un sunduğu ölçeklenebilirlik ve esneklik ciddi bir fark yaratıyor.

Güçlü yanları:

• GPU hızlandırma. Milvus, indeksleme ve arama işlemlerinde GPU'dan faydalanabiliyor. Bu, çok büyük veri setlerinde hem indeks inşa süresini hem de sorgu throughput'unu dramatik biçimde iyileştirebiliyor.
• En zengin indeks algoritması yelpazesi. IVF varyantları, HNSW, disk-tabanlı indeksler ve daha fazlası... Milvus size iş yükünüze göre indeks tipini ince ayarlama özgürlüğü veriyor. Bu esneklik, aşırı büyük ölçekte performansı sıkıştırmak için gerçekten değerli.
• Dağıtık mimari. Yatay ölçeklenmek (horizontal scaling) için baştan tasarlanmış. Depolama ve hesaplamayı ayırabiliyor, bileşenleri bağımsız ölçekleyebiliyorsunuz.

Sınırları:

• Operasyonel karmaşıklık. Milvus'un gücü, aynı zamanda onun maliyeti. Dağıtık, çok bileşenli bir sistem; onu doğru kurmak, ayarlamak ve işletmek ciddi bir platform mühendisliği yatırımı gerektiriyor. Küçük bir ekip için bu ağır bir yük olabilir.
• Küçük ölçekte aşırı mühendislik. 5 milyon vektörünüz varsa Milvus kurmak, bir bisiklet yolculuğu için tır kiralamaya benzer. Gücünü kullanamayacağınız bir karmaşıklık satın almış olursunuz.

"

Milvus için net kuralım: Ölçeğiniz yüz milyonları aşıp milyara doğru gidiyorsa ve bu ölçeği işletecek bir platform ekibiniz varsa, Milvus güçlü bir tercih. Aksi halde, muhtemelen ihtiyacınızdan fazlasını kurmuş olursunuz.

Pinecone, tamamen yönetilen (fully-managed) bir vektör veritabanı servisi. Buradaki temel vaat basit ve güçlü: Hiçbir altyapı yönetmeyin. Sunucu yok, indeks ayarı derdi yok, ölçekleme baş ağrısı yok. API'yi çağırırsınız, gerisiyle Pinecone ilgilenir. Sub-10ms p50 gecikme seviyeleriyle, çoğu uygulama için fazlasıyla hızlıdır.

Güçlü yanları:

• Sıfır altyapı yönetimi. Bu, küçük ekipler ve hızlı hareket etmek isteyen ürün takımları için muazzam bir avantaj. Ekibiniz vektör veritabanı işletmek yerine ürününe odaklanabiliyor.
• Pürüzsüz operasyon. Ölçekleme, yüksek erişilebilirlik, güncellemeler — hepsi servisin sorumluluğunda. Gece 3'te alarm çalmıyor.
• Sub-10ms p50 gecikme. Performans, çok geniş bir uygulama yelpazesi için gayet yeterli.
• Hızlı başlangıç: Fikirden çalışan bir prototipe geçiş süresi çok kısa.

Sınırları:

• Veri ikametgahı ve kontrol. Verileriniz üçüncü taraf yönetilen bir bulutta. Türkiye ve KVKK bağlamında, hassas verilerde bu ciddi bir mesele (buna aşağıda ayrı bir bölüm ayırdım).
• Maliyet modeli ve bağımlılık. Ölçek büyüdükçe yönetilen servis maliyeti hızla artabilir. Ayrıca satıcıya bağımlılık (vendor lock-in) riski var; ileride göç etmek isterseniz bu bir maliyet.
• Daha az düşük seviye kontrol. İndeks parametrelerinde, altyapı yerleşiminde self-hosted seçeneklerin verdiği ince ayar özgürlüğüne sahip değilsiniz.

"

Pinecone'u şu durumda öneriyorum: Küçük ya da altyapı yönetmek istemeyen bir ekipseniz, hızlı çıkmanız gerekiyorsa ve verileriniz veri ikametgahı açısından bir kısıt taşımıyorsa. "Vektör veritabanı işletmek benim işim değil" diyebiliyorsanız, Pinecone tam da bu felsefeyi satıyor.

Aşağıdaki tablo, dört motoru bu yazıda ele aldığımız eksenler üzerinden özetliyor. Önemli uyarı: Buradaki gecikme değerleri yönlendiricidir ve konfigürasyona bağlıdır; kendi donanımınızda, kendi verinizle, güncel sürümlerde mutlaka yeniden ölçün.

Motor	Tipik p50 gecikme	Ölçek tatlı noktası	Operasyonel yük	Dağıtım modeli	En uygun olduğu senaryo
pgvector	Postgres'e bağlı, iş yüküne göre değişir	~10M vektöre kadar	Çok düşük (mevcut Postgres)	Self-hosted (Postgres eklentisi)	Zaten Postgres varsa, operasyonel sadelik, ACID
Qdrant	~4ms (p99 ~25ms)	10M+ , düşük gecikme odaklı	Orta (yeni servis)	Self-hosted veya Qdrant Cloud	Düşük p99 gecikme + gelişmiş filtreleme
Milvus	~18ms (10M kıyaslamada)	Yüz milyon–milyar	Yüksek (dağıtık sistem)	Self-hosted (ve yönetilen seçenekler)	Milyar ölçek, GPU, indeks çeşitliliği
Pinecone	Sub-10ms	Geniş yelpaze, yönetilen	Neredeyse sıfır (managed)	Fully-managed bulut	Altyapı yönetmeden hızlı çıkış

Bu tabloyu bir "kim kazandı" listesi gibi değil, bir "hangisi hangi ihtiyaca oturuyor" haritası gibi okuyun. Her satır farklı bir kurumun doğru cevabı olabilir.

Şimdi en tehlikeli bölüme geldik: kıyaslama sayıları. Neden tehlikeli? Çünkü benchmark'lar, bağlamından koparıldığında yanıltıcıdır — hatta kasıtlı olarak yanıltıcı kılınabilir. Size birkaç somut sayı vereceğim ama her birinin başına kalın harflerle "yönlendirici ve konfigürasyona bağlı" yazacağım.

Gecikme tarafı (10M vektör civarı):

• Qdrant p99 ~12ms, Weaviate ~16ms, Milvus ~18ms. Qdrant'ın Rust temelli mimarisi, kuyruk gecikmelerinde ona avantaj sağlıyor. Genel olarak Qdrant, yaygın iş yüklerinde Weaviate ve Milvus'a göre ~%10–25 daha hızlı ölçülebiliyor.

Yüksek ölçek tarafı (50M vektör):

• Bir kıyaslamada, %99 recall (geri çağırma oranı) hedefinde Qdrant ~41.47 QPS verirken pgvectorscale ~471 QPS vermiş — yani bir büyüklük mertebesi (order of magnitude) fark. Bu çarpıcı bir sonuç, ama son derece konfigürasyona bağlı. pgvectorscale'in bu senaryodaki performansı, doğru ayarlanmış Postgres tabanlı bir çözümün ne kadar güçlü olabileceğini gösteriyor.

Bu iki veri noktası bile size şunu anlatıyor: Tek bir "kazanan" yok. Gecikme kritikse ve orta ölçekteyseniz Qdrant parlıyor; belli bir yüksek-recall throughput senaryosunda ise pgvectorscale şaşırtıcı biçimde öne geçebiliyor. Sayılar, sorunun çerçevesine göre bambaşka hikayeler anlatıyor.

"

En önemli uyarım: 2026'da bu motorların hepsi büyük bir sürüm çıkardı. Yani internette bulduğunuz — bu yazı dahil — her benchmark, siz okurken bile eskimiş olabilir. Bu sayıları asla bir satın alma kararının tek dayanağı yapmayın. Yapmanız gereken tek doğru şey: Kendi verinizle, kendi donanımınızda, güncel sürümlerde, kendi sorgu desenlerinizle yeniden benchmark almak. Bir hafta ayırıp bir PoC (proof of concept) kurmak, altı ay yanlış motorla yaşamaktan çok daha ucuzdur.

Benchmark okurken şu soruları sorun: Hangi sürüm? Hangi donanım (CPU/GPU, bellek)? Hangi recall hedefi? Hangi vektör boyutu ve sayısı? Filtreli mi filtresiz mi? Tek düğüm mü dağıtık mı? Bu soruların cevabını bilmiyorsanız, o benchmark size hiçbir şey söylemiyor demektir.

Şimdi baştaki dört ekseni somut bir karar akışına dönüştürelim. Projenizde şu soruları sırayla cevaplayın:

1. Ölçek sorusu — Kaç vektör?

• < 10M ve zaten Postgres var: pgvector ile başlayın. Tartışma bitti, en azından şimdilik.
• 10M–100M arası: Qdrant (gecikme/filtreleme odaklıysanız) veya iyi ayarlanmış pgvector/pgvectorscale. Pinecone da güçlü bir yönetilen alternatif.
• 100M–milyar+: Milvus'u ciddi biçimde değerlendirin, özellikle GPU ve indeks esnekliği gerekiyorsa.

2. Gecikme ve throughput sorusu — p99 hedefiniz ve QPS'iniz ne?

• Katı bir p99 SLA'niz varsa (örn. 25ms altı) ve filtreli arama yapıyorsanız, Qdrant güçlü.
• Çok yüksek QPS ve yüksek recall birlikte gerekiyorsa, pgvectorscale ve Milvus'u kendi verinizle test edin. Ortalama değil, p99'a ve yük altındaki davranışa bakın.

3. Operasyon sorusu — Kim işletecek?

• Platform ekibiniz yok veya küçük mü? Yönetilen bir yol seçin: Pinecone ya da Qdrant Cloud. Ya da hiç yeni servis eklemeyin, pgvector'de kalın.
• Güçlü bir platform ekibiniz var ve kontrol istiyor musunuz? Self-hosted Qdrant veya Milvus mantıklı.
• HA, multi-tenancy, RBAC gereksinimlerinizi baştan listeleyin. Her motorun bu konudaki olgunluğu farklı; seçtiğiniz motorun bu özellikleri sizin ihtiyaç seviyenizde karşıladığını doğrulayın.

4. Maliyet sorusu — Toplam sahip olma maliyeti (TCO) ne?

• Yönetilen servisin abonelik faturasını, self-hosted'ın gizli maliyetiyle (sunucu + bellek + mühendis saati + bakım + nöbet) yan yana koyun.
• Küçük ölçekte yönetilen genellikle daha ucuza gelir (mühendis zamanı pahalıdır). Çok büyük ölçekte self-hosted maliyet avantajı sağlayabilir, ama ancak onu verimli işletebiliyorsanız.

Bu dört soruyu dürüstçe cevapladığınızda, dört seçenek genellikle bir ya da ikiye iniyor. İşte o zaman PoC kurup kendi benchmark'ınızı alma vakti.

Türkiye'de çalışan bir kurumsanız, bu bölüm sizin için teknik performanstan bile önemli olabilir. Vektör veritabanınızda ne saklıyorsunuz? Çoğu RAG uygulamasında bu embedding'ler, şirket içi belgelerden, müşteri kayıtlarından, sözleşmelerden, e-postalardan türetiliyor. Yani hassas veri. Ve bu veri, embedding'e dönüşse bile, çoğu zaman orijinal içerikle güçlü biçimde ilişkili kalıyor.

KVKK (Kişisel Verilerin Korunması Kanunu) çerçevesinde, kişisel veri içeren embedding'leri yurt dışındaki yönetilen bir servise göndermek, veri aktarımı ve ikametgahı açısından ciddi hukuki sorular doğurur. İşte bu noktada self-hosted seçenekler avantaj kazanıyor:

• pgvector, Qdrant ve Milvus kendi altyapınızda — kendi veri merkezinizde ya da Türkiye'deki bir bulut bölgesinde — çalıştırılabiliyor. Bu, veri ikametgahı gereksinimlerini karşılamayı ve verinin sınırlar içinde kalmasını çok daha kolay hale getiriyor.
• Pinecone gibi tamamen yönetilen bir servis pürüzsüz operasyon sunuyor ama verileriniz sağlayıcının bulutunda konumlanıyor. Hassas kişisel veri söz konusuysa, bu on-prem vs. bulut takasını hukuk ve uyum ekibinizle mutlaka konuşmanız gerekiyor.

"

Pratik önerim: Projenin en başında hukuk/uyum ekibinizi masaya oturtun. "Bu embedding'ler kişisel veri sayılır mı, sayılırsa nerede durabilir?" sorusunun cevabı, teknik seçeneklerinizin yarısını daha kod yazmadan belirleyebilir. Ben sahada, mükemmel bir teknik kararın uyum aşamasında geri döndüğü projeler gördüm; bu, en pahalı hatalardan biri.

Bu, "yönetilen kötü, self-hosted iyi" demek değil. Bu bir takas. Yönetilen size operasyonel rahatlık verir, kontrol ve ikametgahtan ödün verir. Self-hosted size kontrol ve ikametgah verir, operasyonel yük yükler. Doğru cevap, verinizin hassasiyetine ve ekibinizin kapasitesine bağlı.

Şimdi somutlaştıralım. Sahada en sık karşılaştığım senaryoları ve benim o senaryoda hangi yöne baktığımı paylaşıyorum:

Senaryo 1 — "Postgres kullanan bir SaaS'ız, RAG özelliği ekliyoruz, birkaç milyon belge." → pgvector. Yeni altyapı eklemeyin. Mevcut Postgres'inize eklenti kurun, ACID tutarlılığından faydalanın, hızlıca çıkın. 10M'nin altında kaldığınız sürece bu en verimli yol.

Senaryo 2 — "Gerçek zamanlı bir öneri/arama sistemi, katı p99 SLA, yoğun meta veri filtreleme, ~30M vektör." → Qdrant. Düşük p99 gecikme ve gelişmiş payload filtreleme tam bu senaryo için. Self-hosted çalıştırıp kontrolü elde tutabilir, quantization ile maliyeti optimize edebilirsiniz.

Senaryo 3 — "Ulusal ölçekte görüntü/belge arama, milyarlarca embedding, güçlü platform ekibi var." → Milvus. GPU hızlandırma ve indeks çeşitliliği bu ölçekte fark yaratır. Operasyonel karmaşıklığı kaldıracak ekibiniz olduğu için mantıklı.

Senaryo 4 — "Küçük bir startup'ız, altyapı yönetecek insanımız yok, hızlı MVP çıkarmalıyız, veri hassasiyeti düşük." → Pinecone. Sıfır altyapı yönetimiyle en hızlı çıkış. Ekibiniz ürüne odaklanır, vektör veritabanı işletmekle uğraşmaz.

Senaryo 5 — "Türkiye'de finans/sağlık gibi düzenlemeye tabi bir sektördeyiz, veri yurt içinde kalmalı." → Self-hosted pgvector, Qdrant veya Milvus — ölçeğinize göre. Veri ikametgahı kısıtı, yönetilen Pinecone'u büyük olasılıkla masadan kaldırır. Ölçek 10M altındaysa pgvector, filtreleme/gecikme kritikse Qdrant, milyar ölçekteyseniz Milvus.

Bu senaryolar birer şablon; sizinki tam olarak bunlardan biri olmayabilir. Ama dört ekseni (ölçek/gecikme/ops/maliyet) ve ikametgah kısıtını üst üste koyduğunuzda, kendi senaryonuzun hangi yöne baktığını net göreceksiniz.

Sahadan gördüğüm, tekrar tekrar aynı olan hatalar. Bunları baştan bilirseniz çok zaman ve para kazanırsınız:

• Prematüre optimizasyon. 2 milyon vektörünüz varken milyar-ölçek bir Milvus kümesi kurmak. İhtiyacınız olmayan bir karmaşıklığı satın alıyorsunuz. Ölçek geldiğinde göç edersiniz; belki de hiç gelmez.
• Ortalama gecikmeye bakıp p99'u unutmak. Kullanıcı deneyimini bozan, ortalama değil, en yavaş yüzde birlik dilimdir. Her zaman p99'a ve yük altındaki davranışa bakın.
• Başkasının benchmark'ına körü körüne güvenmek. Bağlamı belirsiz bir blog sayısına dayanarak karar vermek. Kendi verinizle, güncel sürümde, kendi sorgularınızla ölçmediyseniz, o sayı sizin için bir şey ifade etmiyor.
• Operasyonel yükü hafife almak. "Kurarız çalışır" demek. HA, yedekleme, izleme, RBAC, güncelleme, nöbet... Bunları kimin nasıl yöneteceğini baştan planlamadan self-hosted'a girmek, altı ay sonra yanan bir köprüdür.
• KVKK/veri ikametgahını sona bırakmak. Teknik kararı verip mimariyi kurduktan sonra hukukun "bu veri yurt dışına çıkamaz" demesi. Bu konuşmayı en başa alın.
• Filtreleme ihtiyacını göz ardı etmek. Çoğu gerçek uygulama, saf vektör araması değil, filtreli vektör araması yapar. Motorun filtreleme performansını (özellikle ölçekte) ihmal ederseniz, üretimde sürprizle karşılaşırsınız.
• Vendor lock-in'i hesaba katmamak. Yönetilen bir servise derinlemesine bağlanmak kolaydır; çıkmak zordur. Baştan bir çıkış senaryosu düşünmek, gelecekteki esnekliğinizi korur.
• Embedding modelini ve boyutunu düşünmeden seçmek. Vektör boyutu, bellek maliyetini ve indeks performansını doğrudan etkiler. Veritabanı seçimini embedding stratejinizden bağımsız yapmak, yarım bir karardır.

Bu yazıyı okuyup "peki şimdi ne yapayım?" diyorsanız, işte size sahadan, adım adım bir başlangıç planı:

1. Dört ekseni doldurun. Beyaz tahtaya yazın: Ölçek (bugün ve 18 ay sonra), p99 hedefi ve QPS, operasyonel kapasiteniz, bütçe. Her birine somut bir sayı/cümle koyun.

2. İkametgah kısıtını netleştirin. Hukuk/uyum ekibiyle konuşun: Verileriniz kişisel veri mi, nerede durabilir? Bu cevap seçenek kümenizi daralttıysa, daraltsın — bu iyi bir şey.

3. İki finalist belirleyin. Dört ekseni ve ikametgahı süzdüğünüzde genellikle iki motor kalır. Bu yazıdaki senaryo rehberi ve tablo, o iki finalisti bulmanıza yardımcı olsun.

4. Kendi PoC benchmark'ınızı alın. Bir hafta ayırın. Kendi verinizin bir örneklemiyle, kendi sorgu desenlerinizle, güncel sürümlerde, kendi donanımınızda iki finalisti karşılaştırın. p99'a, yük altındaki davranışa ve filtreli sorgu performansına bakın.

5. Operasyonu tasarlayın. Seçtiğiniz motor için HA, yedekleme, izleme, RBAC, güncelleme ve nöbet planını yazın. Bu plan yoksa, karar tamamlanmamış demektir.

6. Küçük başlayın, göçü planlayın. İlk sürümde en basit yeterli çözümle çıkın (çoğu zaman pgvector). Ama embedding ve arama katmanınızı, gerektiğinde başka bir motora göç edebilecek şekilde soyutlayın. Bu, gelecekteki kararlarınızı ucuzlatır.

Vektör veritabanı seçimi, doğru çerçeveyle bakıldığında korkutucu değil. Dört ekseni netleştirin, ikametgahı çözün, iki finalisti kendi verinizle test edin, operasyonu tasarlayın ve küçük başlayın. Bu adımları izlerseniz, o hafta kimin blog yazısını okuduğunuza göre değil, kendi gerçekliğinize göre bir karar vermiş olursunuz — ve doğru karar, neredeyse her zaman bu şekilde ortaya çıkar.