Vektör Veritabanı Seçimi 2026: pgvector, Qdrant ve Milvus'u Ne Zaman Kullanmalı?

TL;DR — 2026'da vektör veritabanı seçimi artık "hangisi en havalı" sorusu değil; "işim için hangisi en az sürtünmeyle üretime çıkar" sorusu. Kısa cevabım şu: Zaten PostgreSQL kullanıyorsanız pgvector (veya Supabase) üretime en hızlı yoldur ve ~10M vektöre kadar rahatça idare eder. En düşük gecikme önceliğinizse Qdrant raporlanan benchmark'larda tutarlı biçimde en hızlısı (~4ms p50). Milyar ölçekli, dağıtık bir yük ve özel bir ops ekibiniz yoksa Milvus'a bulaşmayın. Hibrit arama ve GraphQL ergonomisi istiyorsanız Weaviate'e bakın. Aşağıdaki sayıların hepsi 2026'da raporlanan benchmark'lar; kendi verinizde yeniden ölçün. Bu yazı, sahada bu kararı defalarca verdikten sonra biriktirdiğim bir seçim rehberi.

Danışmanlık yaptığım ekiplerin belki yarısı bana aynı soruyla geliyor: "Şükrü, RAG sistemimiz için hangi vektör veritabanını kurmalıyız?" Ve neredeyse her seferinde, sorunun kendisi biraz yanlış. Çünkü asıl mesele "hangi veritabanı" değil, "hangi kısıt beni gerçekten sıkıştırıyor" mesele.

Vektör veritabanı seçiminde üç eksen var ve bu üçü arasında sürekli bir gerilim yaşarsınız:

• Gecikme (latency): Kullanıcı arama kutusuna yazdı, embedding'i çıkardınız, en yakın komşuları buluyorsunuz. Bu p50 ve özellikle p99 gecikmesi, kullanıcının "bu sistem hızlı" mı yoksa "bu sistem takılıyor" mu hissini doğrudan belirler.
• Ölçek (scale): 100 bin döküman mı, 10 milyon mu, yoksa 2 milyar mı vektörünüz var? Bu sayı, seçim uzayınızı acımasızca daraltır.
• Operasyon yükü (ops burden): Bu şeyi kim ayakta tutacak? Ayrı bir cluster mı yönetiyorsunuz, yoksa zaten yönettiğiniz Postgres'e bir extension mı ekliyorsunuz? Bu, aylık faturanızdan çok daha fazla, nöbet tuttuğunuz geceleri belirler.

Sahadan bir gözlem: ekiplerin çoğu gecikme ve ölçeği abartıp operasyon yükünü küçümsüyor. "Milyar vektöre çıkabilelim" diye Milvus kuran, ama gerçekte 400 bin dökümanı olan ve o dağıtık cluster'ı ayakta tutmak için gece 3'te uyanan ekipler gördüm. Bu, klasik bir aşırı mühendislik (over-engineering) tuzağı. Az sonra buna ayrı bir başlık açacağım çünkü hak ediyor.

Şunu baştan söyleyeyim: doğru seçim, "en iyi veritabanı" değil, sizin bugünkü kısıtınıza en iyi oturan veritabanıdır. Ve bu bir yıl sonra değişebilir. İyi haber şu ki, doğru soyutlamaları kurarsanız geçiş göründüğü kadar acı verici olmuyor.

Sözü uzatmadan, sahada kafamda tuttuğum tabloyu paylaşayım. Bunu duvara asılacak kutsal bir metin gibi değil, "nereden başlamalıyım" pusulası gibi okuyun. Sayılar 2026'da raporlanan benchmark'lardan; kendi iş yükünüzde mutlaka yeniden doğrulayın.

Veritabanı	Gecikme (raporlanan)	Ölçek tatlı noktası	Öne çıkan güçler	Ne zaman kullanmalı
pgvector	Postgres'e bağlı; ~10M'e kadar iyi	~10M vektöre kadar	Zaten Postgres'te; sıfır yeni altyapı; SQL ile join	Ekip zaten PostgreSQL'deyse; üretime en hızlı yol
Qdrant	~4ms p50, ~25ms p99 (bazı yerlerde p99 <15ms)	Orta-büyük; on milyonlar	Rust + özel HNSW; tutarlı en düşük gecikme	Gecikme birinci önceliğse; managed veya self-host
Milvus	~6ms p50	Milyar ölçek, dağıtık	GPU hızlandırma; en çok index algoritması	Gerçekten milyar ölçek + özel ops ekibi varsa
Weaviate	Rekabetçi	Orta-büyük	Hibrit arama, GraphQL ergonomisi	Hibrit arama ve API ergonomisi önceliğinizse

Bu tabloda benim için en kritik sütun, çoğu kişinin en son baktığı sütun: "Ne zaman kullanmalı". Çünkü gecikme farkları milisaniye düzeyinde ve çoğu uygulamada kullanıcı bu farkı hissetmez. Ama operasyonel model farkı, ekibinizin haftalık gerçekliğini belirler.

Eğer bir kısım açıp "hangisiyle başlayayım" diye sorarsanız, cevabım büyük olasılıkla pgvector olacak. Nedeni romantik değil, pragmatik: çoğu ekip zaten PostgreSQL kullanıyor.

Düşünün: uygulama verileriniz zaten Postgres'te. Kullanıcılar, siparişler, dökümanların metadata'sı, hepsi orada. pgvector bir extension olarak geliyor ve embedding'lerinizi aynı veritabanına, aynı transaction sınırlarına, aynı yedekleme ve replikasyon hattına koyuyor. Yeni bir servis yok, yeni bir cluster yok, öğrenilecek yeni bir sorgu dili yok. CREATE EXTENSION vector; ve devam.

Bunun ne kadar büyük bir avantaj olduğunu üretime çıkana kadar tam anlamıyorsunuz. Çünkü vektör aramayı ilişkisel filtrelerle birleştirmek istediğinizde — "bu kullanıcının erişebildiği, son 30 gün içinde güncellenmiş dökümanlar arasında en yakın komşuları bul" — pgvector'da bu tek bir SQL sorgusu. Ayrı bir vektör veritabanında bu, iki sistemi konuşturmak, ID'lerle jonglörlük yapmak ve tutarlılık dertleriyle boğuşmak demek.

pgvector nerede sınıra dayanıyor? Raporlanan verilere göre yaklaşık 10 milyon vektöre kadar gayet iyi çalışıyor. Bunun ötesinde, özellikle yüksek recall gerektiren yükte, saf pgvector zorlanmaya başlıyor. İşte tam burada önemli bir nüans var: pgvectorscale. Bu, ölçeklenme için ayarlanmış (tuned) bir extension ve rakamlar dramatik. 50 milyon vektörde, %99 recall'da Qdrant ~41.47 QPS verirken, pgvectorscale ~471 QPS'e ulaşıyor — bir büyüklük mertebesi (order-of-magnitude) fark.

Bu rakamı ilk gördüğümde iki kez okudum. Ama bağlamı doğru kurmak lazım: bu, ayarlanmış pgvectorscale ile karşılaştırma ve belirli bir kurulum. Çıkarılacak ders "pgvector her zaman kazanır" değil; çıkarılacak ders şu: Postgres ekosistemi terk etmeniz gereken noktayı çoğu ekibin sandığından çok daha ileriye itiyor. 10 milyonda tıkandığınızı sanıp koca bir migrasyona girişmeden önce, pgvectorscale'i denediniz mi?

Türkiye bağlamında bir ek not: pek çok kurumda zaten yönetilen bir PostgreSQL var (kendi veri merkezinde veya yerel bir bulutta). Vektör aramayı oraya koymak, veriyi hiç yeni bir sisteme taşımadan KVKK ve veri ikametgahı (data residency) açısından da en az sürtünmeli yol. Buna aşağıda ayrı döneceğim.

"

Sahadan pratik kural: İlk RAG sisteminizi kuruyorsanız ve zaten Postgres'iniz varsa, pgvector ile başlayın. "Yeterince ölçeklenmez" korkusuyla gün 1'de dağıtık bir sistem kurmak, çözmediğiniz bir problemi çözmeye çalışmaktır.

pgvector "basit başla" ise, Qdrant "hızlı olması gerektiğinde" cevabı. Raporlanan 2026 benchmark'larında, amaca özel (purpose-built) vektör veritabanları arasında en düşük p50 gecikmesi ~4ms ile Qdrant'a ait. p99 tarafında bazı benchmark'lar ~25ms, bazıları 15ms'nin altını raporluyor. Ve bu bir tesadüf değil: Qdrant tutarlı biçimde benchmark'larda en hızlısı olarak çıkıyor.

Bu hızın altında bir mühendislik tercihi var: Qdrant Rust ile yazılmış ve kendi özel HNSW implementasyonunu kullanıyor. Rust, çöp toplayıcı (garbage collector) duraklamaları olmadan öngörülebilir düşük gecikme demek — ki p99'un dümdüz kalması için bu kritik. Özel HNSW implementasyonu da genel amaçlı bir kütüphaneye bağlı kalmak yerine, filtreleme ve index davranışını kendi ihtiyaçlarına göre şekillendirebilmelerini sağlıyor.

Qdrant'ı pratikte sevdiğim yanı, hem managed (Qdrant Cloud) hem self-hosted seçeneği sunması. Bu ikili, Türkiye'deki müşterilerim için özellikle değerli: prototipi managed'da hızlıca çıkar, veri hassasiyeti gerektiğinde aynı motoru kendi altyapında self-host et. Motor aynı olduğu için geçiş, tamamen farklı iki ürün arasında geçiş gibi acı vermiyor.

Ne zaman Qdrant? Şu senaryoda net: pgvector'ın rahat bölgesini aştınız (on milyonlarca vektör), gecikme kullanıcı deneyiminde birinci öncelik ve ayrı bir vektör servisi yönetmeye hazırsınız. Örneğin gerçek zamanlı bir öneri sistemi ya da her tuş vuruşunda arama yapan bir arayüz kuruyorsanız, o ~4ms p50 gerçekten hissedilir.

Bir uyarı: Qdrant'ı da fetişleştirmeyin. Eğer 200 bin dökümanınız varsa ve sorgularınız saniyede birkaç taneyse, Qdrant'ın gecikme avantajını kullanıcı asla fark etmez ama siz ayrı bir servis yönetme yükünü her gün hissedersiniz. Hız, sizin gerçekten hıza ihtiyacınız olduğunda bir özelliktir; öbür türlü çözülmemiş bir operasyon yüküdür.

Milvus'u konuşurken tonumu değiştiriyorum çünkü burası çoğu ekip için bir tuzak. Milvus muhteşem bir mühendislik ürünü — ama yanlış ekibin elinde muhteşem bir baş ağrısı.

Rakamlarla başlayalım: Milvus ~6ms p50 gecikme veriyor, GPU hızlandırma destekliyor ve ayarlama (tuning) için en çok index algoritmasına sahip. En güçlü olduğu yer, büyük ölçekli dağıtık kurulumlar — milyar ölçekli (billion-scale) yükler. Yani gerçekten milyarlarca vektörünüz varsa ve bunu yatay olarak ölçeklemeniz gerekiyorsa, Milvus'un mimarisi bunun için tasarlanmış.

Ama işte kritik nokta: Milvus'un gücü aynı zamanda operasyonel maliyeti. Dağıtık bir Milvus kurulumu, koordinatörleri, worker node'ları, obje deposu, mesaj kuyruğu gibi hareketli parçalardan oluşan bir sistem. Bunu üretimde sağlıklı tutmak, bir Postgres extension'ı bakmakla kıyaslanamayacak bir uzmanlık ister. Bu yüzden tavsiyem net: Gerçekten milyar ölçeğe ihtiyacınız yoksa ve bu işe adanmış bir ops ekibiniz yoksa Milvus'tan kaçının.

Sahadan bir hikâye: bir ekip, "büyüyünce hazır olalım" diye Milvus'la başlamıştı. Altı ay sonra 900 bin vektörleri vardı — Milvus için gülünç derecede küçük — ama cluster'ın operasyonu ekibin en tecrübeli iki mühendisinin zamanının önemli kısmını yiyordu. Onları pgvector'a taşıdık; hem gecikme yeterliydi hem de o iki mühendis nihayet asıl ürüne dönebildi. Milvus kötü değildi; sadece yanlış problem için doğru araçtı.

Weaviate'i tabloya koymamın nedeni, belirli bir ihtiyaçta gerçekten parladığı: hibrit arama (vektör + anahtar kelime birlikte) ve GraphQL API ergonomisi. Eğer aramanız salt semantik benzerlikle değil, kesin anahtar kelime eşleşmesiyle de zenginleşmeliyse — ki hukuki, tıbbi veya ürün kataloğu aramalarında bu çok yaygın — Weaviate bu harmanı zarif yapıyor. GraphQL arayüzü de bazı ekiplerin geliştirici deneyimi açısından çok sevdiği bir şey.

Weaviate benim varsayılanım değil, ama "hibrit arama bizim için hayati" diyen bir ekibe onu değerlendirme listesine koymalarını mutlaka söylerim. Doğru araç, doğru ihtiyaçta.

Şimdi bu yazının belki en önemli başlığına geldik ve bunu biraz sertçe söyleyeceğim çünkü tekrar tekrar aynı hatayı görüyorum: Elinizde olanla başlayın.

Ekiplerin vektör veritabanı seçiminde yaptığı bir numaralı hata, henüz sahip olmadıkları bir ölçek için mühendislik yapmak. "Ya viral olursak?", "Ya milyar dökümana çıkarsak?" Bu sorular meşru görünüyor ama pratikte, henüz doğmamış bir problemi bugünkü hızınızı yavaşlatarak çözmeye çalışıyorsunuz.

Gerçek şu: çoğu RAG ve semantik arama projesi, ömrü boyunca 10 milyon vektörün altında kalıyor. Bu da demek oluyor ki, pgvector'ın rahat bölgesindesiniz. O bölgede, ayrı bir vektör veritabanı kurmak size gecikme açısından belki birkaç milisaniye kazandırır ama karşılığında operasyon yükü, ikinci bir veri sistemi, senkronizasyon dertleri ve ekibinizin öğrenme eğrisi getirir. Bu takas, çoğu ekip için kaybettiren bir takas.

Benim önerdiğim zihniyet şu: En sıkıcı, en az hareketli parçalı çözümle başla; ölçüm seni zorlayana kadar orada kal. Ölçüm seni zorladığında — yani gerçek verinde, gerçek yükünde gecikme ya da recall hedeflerini tutturamadığında — o zaman bir sonraki araca geç. Bu geçiş, doğru soyutlamaları kurmuşsan (embedding üretimini ve vektör deposunu arayüz arkasına almışsan) sandığından çok daha ucuz.

"

Sahadan pratik kural: "İhtiyacımız olacak" bir mühendislik gerekçesi değildir. "Şu anki yükümüzde şu metriği tutturamıyoruz" bir mühendislik gerekçesidir. İkincisini görene kadar birincisine göre karar vermeyin.

Hangi veritabanını seçerseniz seçin, muhtemelen bir HNSW indeksi kullanacaksınız (Hierarchical Navigable Small World). Ve burada anlamanız gereken temel bir gerçek var: recall ve gecikme arasında sürekli bir takas var, ve bu takası siz ayarlıyorsunuz.

Kabaca üç parametre kaderinizi belirliyor:

• m — Her düğümün graf içindeki bağlantı sayısı. Daha yüksek m, daha zengin bir graf, daha iyi recall, ama daha fazla bellek ve daha yavaş inşa.
• ef_construction — İndeks inşa edilirken ne kadar geniş arama yapılacağı. Yüksek değer, daha kaliteli indeks, ama daha uzun inşa süresi.
• ef_search (veya ef) — Sorgu anında ne kadar geniş arama yapılacağı. İşte gecikme/recall takasını canlı olarak ayarladığınız yer burası. Yüksek ef_search daha iyi recall ama daha yüksek gecikme.

Pratikte ne yapıyorum: bir recall hedefi belirliyorum (diyelim %95), sonra ef_search'ü o hedefi tutturan en düşük değere ayarlıyorum. Çünkü %99 recall kulağa %95'ten iyi geliyor ama gecikmeyi ikiye katlıyorsa ve kullanıcı farkı hissetmiyorsa, o ekstra recall için ödediğiniz bedel boşa gidiyor.

Kritik uyarı: bu parametrelerin "doğru" değeri, verinizin dağılımına, embedding boyutuna ve sorgu desenlerinize bağlı. Blog yazılarından kopyaladığınız değerler başlangıç noktası olabilir ama nihai değer sizin verinizde ölçümle bulunur. Bu da beni bir sonraki başlığa getiriyor.

Sık yapılan bir hata: vektör veritabanını embedding modelinden bağımsız seçmek. Oysa bu ikisi bir bütün. Veritabanına koyduğunuz vektörlerin kalitesi, embedding modelinizden geliyor; veritabanı sadece o vektörleri hızlı buluyor. Çöp vektör koyarsanız, dünyanın en hızlı veritabanı size çöp komşular bulur — sadece çok hızlı bulur.

Birlikte düşünülmesi gereken noktalar:

• Boyut (dimensionality): 384 boyutlu bir embedding mi, 1536 mı, 3072 mü? Yüksek boyut daha çok bellek, daha yavaş arama demek. Bazı modeller Matryoshka tarzı kısaltmaya izin veriyor — daha küçük boyutta hala iyi recall. Bu, veritabanı maliyetinizi doğrudan etkiler.
• Mesafe metriği: Kosinüs mü, iç çarpım mı, L2 mi? Embedding modelinizin eğitildiği metrikle veritabanı indeksinizin metriği uyumlu olmalı. Uyumsuzluk sessiz bir recall katilidir.
• Normalizasyon: Bazı modeller normalize edilmiş vektör üretir, bazıları etmez. Yanlış varsayım, benzerlik skorlarınızı bozar.

Yani "hangi veritabanı" sorusundan önce, "hangi embedding modeli ve hangi boyut" sorusunu netleştirin. İkisi el ele karar verilir.

Bu yazı boyunca sayılar verdim ama size en önemli tavsiyem şu: bu sayıların hiçbirine benim verdiğim için güvenmeyin. Kendi verinizde ölçün.

Benchmark'lar standart veri setlerinde, standart kurulumlarda, çoğu zaman ideal koşullarda çalışır. Sizin veriniz farklı dağılıma sahip, sorgularınız farklı desende, altyapınız farklı yapılandırılmış. "Qdrant ~4ms" cümlesi bir başlangıç hipotezi; üretim kararı değil.

Basit bir değerlendirme protokolü öneriyorum:

1. Bir gerçek-doğru (ground truth) küme hazırlayın. Kendi verinizden 100-500 tane temsili sorgu alın ve her biri için doğru sonuçların ne olması gerektiğini (brute-force tam arama ile) hesaplayın.
2. Recall@k ölçün. Adayınız olan her veritabanı ve parametre kombinasyonu için, gerçek komşuların yüzde kaçını bulduğunu ölçün.
3. Gerçekçi yükte gecikme ölçün. Tek sorgu değil; eşzamanlı yük altında p50, p95, p99. Çünkü üretimde tek sorgu yapmıyorsunuz.
4. Kaynağı ölçün. Bellek, CPU, disk. O ~4ms belki 64GB RAM ile geliyordur; bütçenizde o var mı?
5. Takası tabloya koyun. Recall, gecikme ve maliyeti yan yana yazın; kararı bir his değil, bir tablo versin.

Bu protokolü bir kez kurduğunuzda, sadece bugünkü seçiminizi doğrulamakla kalmaz; altı ay sonra "acaba geçmeli miyiz" sorusunu da veriye dayalı yanıtlayabilecek bir aracınız olur.

Türkiye'deki müşterilerimle çalışırken vektör veritabanı seçimine giren, teknik olmayan ama son derece belirleyici bir eksen var: veri nerede duracak?

KVKK ve pek çok sektörel düzenleme (bankacılık, sağlık, kamu) verinin belirli sınırlar içinde kalmasını, bazen ülke içinde tutulmasını gerektiriyor. RAG sisteminizde ne var? Genellikle kurumun en hassas iç dökümanları: sözleşmeler, müşteri kayıtları, iç prosedürler. Bu dökümanların embedding'leri de hassas veridir — embedding'den orijinal metne dair çok şey sızabilir. Yani "sadece sayılar, önemli değil" diye düşünmeyin.

İşte bu noktada self-hosted seçenek bir lüks değil, çoğu zaman bir zorunluluk oluyor. İyi haber: bu yazıdaki araçların üçü de (pgvector, Qdrant, Milvus) kendi altyapınızda çalıştırılabilir.

• pgvector zaten kendi Postgres'inizde; hassas veri için ekstra bir sistem eklemeden, mevcut uyumluluk çerçevenizin içinde kalırsınız. Türkiye bağlamında en az sürtünmeli yol genellikle bu.
• Qdrant self-hosted olarak kurulabilir; managed'da prototip yapıp hassas üretimi self-host'a almak, motor aynı kaldığı için temiz bir geçiş.
• Milvus de self-host edilebilir ama yukarıda anlattığım operasyon yükü burada da geçerli; veri ikametgahı için Milvus seçiyorsanız o ops maliyetini kabul ediyorsunuz demektir.

Pratik tavsiyem: seçim kriterlerinize teknik eksenlerin (gecikme, ölçek, ops) yanına açıkça bir "veri ikametgahı ve uyumluluk" ekseni ekleyin. Bazı ekiplerde bu eksen, teknik olarak "daha iyi" olan managed bir bulut hizmetini masadan kaldırır — ve bu tamamen doğru bir karardır. Uyumluluk, sonradan eklenen bir özellik değil, en baştan bir kısıttır.

Bütün bunları tek bir akış hâline getireyim. Bir sonraki vektör veritabanı seçiminizde bu soruları sırayla sorun.

1. Zaten PostgreSQL kullanıyor musunuz? Evetse ve vektör sayınız ~10M'in altında (ya da pgvectorscale ile daha üstünde) olacaksa: pgvector ile başlayın. Karar büyük olasılıkla burada bitiyor. Zaman kazandınız.

2. Gecikme birinci önceliğiniz mi ve pgvector'ın bölgesini aştınız mı? Evetse: Qdrant. En düşük gecikme, Rust motoru, managed veya self-host esnekliği.

3. Gerçekten milyar ölçekte misiniz VE adanmış bir ops ekibiniz var mı? Her iki koşul da evetse: Milvus. Değilse — özellikle ikinci koşul yoksa — Milvus'tan kaçının.

4. Hibrit arama (vektör + anahtar kelime) sizin için hayati mi? Evetse: Weaviate'i değerlendirme listenize alın.

5. Veri ikametgahı / KVKK bir kısıt mı? Evetse: self-hosted seçenekleri filtreleyin. Bu, managed-only hizmetleri masadan kaldırabilir ve bu doğru bir karardır.

6. Seçiminizi KENDİ verinizde ölçtünüz mü? Ölçmediyseniz, henüz karar vermediniz demektir; sadece bir hipoteziniz var. Ground truth küme, recall@k, gerçekçi yükte p99. Sonra karar.

Ve son olarak, bu çerçevenin ruhu: En sıkıcı çözümle başlayın, ölçüm sizi zorlayana kadar orada kalın, zorladığında veriye dayanarak taşının. Vektör veritabanı seçimi tek seferlik, geri dönülemez bir evlilik değil; embedding üretimini ve depoyu doğru soyutlamaların arkasına alırsanız, yarın ihtiyacınız değişirse geçiş yapabilirsiniz. En büyük risk yanlış veritabanını seçmek değil; henüz sahip olmadığınız bir problem için bugün kendinizi yavaşlatmaktır.

Bir sonraki sistemi kurarken, bu kontrol listesini açın, ilk soruyla başlayın ve dürüst cevaplar verin. Çoğu zaman ikinci soruya bile gelmeden en doğru kararı vermiş olacaksınız — ve o karar, çoğu ekip için, elinizde zaten olanı kullanmak olacak.

Atölyelerde ve danışmanlıklarda bu başlıkta topladığım sorular sürekli tekrar ediyor. Kısa, dürüst cevaplarımı buraya bırakıyorum çünkü çoğu ekibin gerçek karar anında takıldığı yer tam da bunlar.

"Vektör veritabanını sonradan değiştirmek ne kadar acı verici?" Doğru kurgularsanız düşündüğünüzden çok daha az. Anahtar, embedding üretimini ve depoyu bir arayüz (interface) arkasına almak: upsert, search, delete gibi birkaç metotluk ince bir soyutlama. Uygulama kodunuz doğrudan Qdrant client'ına ya da doğrudan SQL'e bağlı olmamalı; sizin tanımladığınız arayüze bağlı olmalı. Bunu yaptığınızda, pgvector'dan Qdrant'a geçiş bir arka uç değişikliği olur, bir yeniden yazım değil. Bu tek disiplin, "yanlış seçim yaparsam mahvolurum" korkusunu neredeyse tamamen ortadan kaldırır ve sizi gün 1'de aşırı mühendislik yapmaktan kurtarır.

"Embedding'lerimi yeniden üretmem gerekir mi geçişte?" Genellikle hayır — vektörlerin kendisi taşınabilir; embedding modeli aynı kaldığı sürece aynı sayıları yeni depoya yüklersiniz. Ama embedding modelini değiştirirseniz, o zaman tüm korpusu yeniden embed etmeniz gerekir çünkü farklı modellerin vektör uzayları uyumlu değildir. Bu yüzden embedding modeli seçimi, veritabanı seçiminden daha kalıcı bir karardır; ona daha çok özen gösterin.

"Managed mi self-hosted mi?" Bu, teknik değil kurumsal bir karar. Sorular şunlar: Veri ikametgahı kısıtınız var mı (KVKK, sektörel düzenleme)? Ops kapasiteniz var mı? Maliyet modeliniz neye izin veriyor? Türkiye'deki pek çok kurumsal müşterimde, hassas veri için self-hosted zaten tek seçenek. Ama hassas olmayan, halka açık bir bilgi tabanı için managed, ekibinizi ops yükünden kurtarıp ürüne odaklar. İkisini aynı kurumda karıştırmak da tamamen meşru: hassas iş yükü self-host, gerisi managed.

"Recall hedefim ne olmalı?" Bu, uygulamanıza bağlı ve çoğu ekip bunu fazla yükseğe koyuyor. Bir hukuki döküman aramasında %99 recall hayati olabilir çünkü kaçırdığınız bir emsal karar gerçek bir risk. Ama bir "ilgili makaleler" widget'ında %90 recall fazlasıyla yeterli ve size gecikme ile maliyette ciddi tasarruf sağlar. Recall hedefinizi iş etkisiyle belirleyin, mühendislik gururuyla değil. "Daha yüksek daha iyidir" burada geçerli bir kural değil.

"GPU'ya ihtiyacım var mı?" Neredeyse kesinlikle hayır — en azından başlangıçta. GPU hızlandırma (ki Milvus'un öne çıkan bir özelliği) çok büyük ölçekte ve çok yüksek sorgu hacminde anlam kazanıyor. On milyonlarca vektörün altındaysanız, CPU üzerinde HNSW fazlasıyla yeterli ve GPU bütçesini başka yere harcayabilirsiniz. GPU'yu, ölçüm size gerektiğini gösterene kadar bekletin — tıpkı diğer her şeyde olduğu gibi.

Somutlaştırmak için hayali ama tipik bir ekip düşünelim: orta ölçekli bir Türk e-ticaret şirketi, ürün açıklamaları ve müşteri destek dökümanları üzerinde semantik arama kurmak istiyor. Yaklaşık 2 milyon dökümanları var, her biri 1024 boyutlu bir embedding'e dönüşüyor. Zaten AWS'nin İstanbul bölgesinde yönetilen bir PostgreSQL'leri var.

Bu ekip için doğru karar neredeyse kendini yazıyor. 2 milyon vektör, pgvector'ın rahat bölgesinin çok içinde. Zaten Postgres'leri var, zaten İstanbul bölgesinde, yani veri ikametgahı çözülmüş. Yeni bir vektör veritabanı eklemek onlara sıfır gecikme faydası, ama ikinci bir sistemin tüm ops yükünü getirirdi. Karar: pgvector, aynı Postgres örneğinde, HNSW indeksiyle. Toplam yeni altyapı: bir extension ve bir indeks.

Şimdi bu ekibin üç yıl sonra 80 milyon vektöre büyüdüğünü ve gerçek zamanlı öneri motorunun her sayfa görüntülemede p99 gecikmeyi zorladığını düşünelim. İşte artık ikinci soruya geçme zamanı: ölçüm onları zorluyor. Şimdi Qdrant'ı (veya pgvectorscale'i) değerlendirmek mantıklı. Ama dikkat edin — bu kararı gün 1'de değil, gün 1000'de veriyorlar, ve veriye dayanarak veriyorlar. Arayüz soyutlamasını gün 1'de kurdukları için de geçiş bir kâbus değil, planlı bir arka uç değişikliği.

Bu senaryonun ahlaki dersi tam da yazının omurgası: doğru vektör veritabanı zamanla değişebilir ve bu sorun değil. Sorun, gelecekteki bir kararı bugün, veri olmadan, korkuyla vermektir.

Eğer şu an bir vektör veritabanı seçimi önünüzdeyse, önerim şu: bu yazıyı kapatın ve üç şey yapın. Birincisi, elinizdeki gerçek vektör sayısını ve önümüzdeki 12 ayda gerçekçi olarak nereye varacağını yazın — tahmin değil, veriye dayalı bir aralık. İkincisi, veri ikametgahı ve KVKK kısıtınızın olup olmadığını netleştirin çünkü bu, seçim uzayınızı diğer her şeyden önce daraltabilir. Üçüncüsü, yukarıdaki değerlendirme protokolünü kurun ve en güçlü iki adayınızı kendi verinizde ölçün.

Bu üç adımı yaptığınızda, çoğu ekip için karar zaten kendini gösterecek: zaten Postgres'iniz varsa ve makul bir ölçektiyseniz, pgvector ile başlayın; gecikme sizi zorluyorsa Qdrant'a bakın; gerçekten milyar ölçekte ve adanmış bir ops ekibiniz varsa ancak o zaman Milvus'u masaya koyun. Ve her durumda, en sıkıcı çözümle başlayıp ölçüm sizi zorlayana kadar orada kalın. Sahada defalarca gördüm: bu disiplini uygulayan ekipler daha hızlı üretime çıkıyor, daha az gece nöbeti tutuyor ve gerektiğinde daha rahat geçiş yapıyor. En doğru mühendislik kararı, çoğu zaman en gösterişsiz olanıdır.