Kurumsal RAG Sistemleri İçin Veritabanı Seçimi: PostgreSQL, Azure SQL ve Vektör Veritabanları

Kurumsal bir RAG (Retrieval-Augmented Generation) sistemi için veritabanı seçerken asıl soru “hangi vektör veritabanı?” değil, “kurumsal veri nerede duruyor ve kim neye erişebilir?” sorusudur. Çoğu kurum için en doğru başlangıç, verinin zaten bulunduğu PostgreSQL (pgvector) veya SQL Server ve Azure SQL veritabanına vektör aramayı eklemektir. Ayrı bir vektör veritabanı veya arama motoru; çok büyük ölçek, çok sayıda veri kaynağı veya gelişmiş arama ihtiyacı olduğunda gündeme gelmelidir.

Bu rehber, kurumsal belgeleri ve veritabanlarını yapay zekâ asistanlarına bağlamayı planlayan BT yöneticileri ve mimarlar için hazırlandı. Teknoloji tercihlerini ölçek, güvenlik, KVKK ve işletim maliyeti açısından karşılaştırıyoruz.

Kısaca: Seçenekler

Bir RAG Sisteminin Katmanları

Veritabanı seçimi, RAG mimarisinin yalnızca bir katmanıdır. Kararı doğru verebilmek için tüm akışı görmek gerekir:

Karar Kriterleri

1. Veri nerede duruyor?

Verinin çoğu zaten bir ilişkisel veritabanındaysa (ERP, CRM, ürün kataloğu, destek kayıtları), vektörleri aynı veritabanında tutmak senkronizasyon, tutarlılık ve yetki sorunlarını büyük ölçüde ortadan kaldırır. Kaynaklar çok çeşitliyse (dosya sunucuları, e-postalar, wiki sayfaları, birden fazla veritabanı), merkezi bir arama katmanı daha uygun olabilir.

2. Ölçek

3. Erişim kontrolü

Kurumsal RAG’in en kritik ve en sık ihmal edilen gereksinimi budur. Kullanıcının yalnızca yetkisi olan içeriğin parçalarını görmesi gerekir. İlişkisel veritabanlarında Row-Level Security ile bu filtre doğrudan arama sorgusuna uygulanabilir. Ayrı bir vektör sistemi kullanılıyorsa, kaynak sistemdeki yetkilerin bu sisteme doğru ve güncel olarak taşınması gerekir.

4. KVKK ve veri konumu

Veri konumu gereksinimlerinin sıkı olduğu kurumlarda, dil modelini ve embedding modelini kurum içinde çalıştırmak ve tüm RAG katmanlarını kendi veri merkezinde tutmak giderek yaygınlaşan bir seçenektir. Bu durumda veritabanı olarak kurum içinde çalışan PostgreSQL veya SQL Server 2025 doğal bir tercihtir.

5. İşletim maliyeti

Her yeni sistem; kurulum, yedekleme, izleme, güvenlik yaması, yetki yönetimi ve uzmanlık demektir. Mevcut veritabanı platformunuzu kullanmak, ekibinizin zaten bildiği operasyon süreçlerini RAG için de geçerli kılar.

Örnek: pgvector ile Vektör Araması

PostgreSQL’de pgvector eklentisi, vektörleri iş verisiyle aynı tabloda saklamayı ve HNSW indeksiyle hızlı yaklaşık arama yapmayı sağlar. Aşağıdaki örnek, kavramı göstermek için üç boyutlu vektörler kullanıyor:

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE doc_chunks (
    id         bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    department text NOT NULL,
    content    text NOT NULL,
    embedding  vector(3) NOT NULL
);

INSERT INTO doc_chunks (department, content, embedding) VALUES
  ('it',      'Yedekleme politikası',     '[0.9, 0.1, 0.0]'),
  ('it',      'Geri yükleme prosedürü',   '[0.8, 0.2, 0.1]'),
  ('finance', 'Bütçe onay süreci',        '[0.0, 0.2, 0.9]');

CREATE INDEX ON doc_chunks USING hnsw (embedding vector_cosine_ops);

-- Nearest chunks by cosine distance, only within the user's department
SELECT content, embedding <=> '[0.85, 0.15, 0.05]' AS distance
FROM doc_chunks
WHERE department = 'it'
ORDER BY embedding <=> '[0.85, 0.15, 0.05]'
LIMIT 2;

Örnekteki department filtresi basit bir erişim kontrolünü temsil ediyor. Gerçek sistemlerde bu filtre, Row-Level Security politikasıyla veritabanı düzeyinde zorunlu hale getirilmelidir. SQL Server ve Azure SQL tarafındaki karşılığını Azure SQL’de vektör arama yazımızda gösterdik.

Karar Ağacı

1. Veri konumu şartınız var mı? Varsa, tüm katmanların (model dahil) uygun lokasyonda çalışabildiği seçeneklerle sınırlanın.
2. Veri çoğunlukla tek bir ilişkisel veritabanında mı? Evetse, o veritabanının vektör desteğiyle başlayın.
3. Parça sayısı milyonları aşıyor mu? Aşıyorsa, vektör indeksi kullanın ve performansı ölçün.
4. Çok sayıda farklı kaynak ve gelişmiş tam metin araması gerekiyor mu? Gerekiyorsa, vektör destekli bir arama katmanı değerlendirin.
5. Ölçümler ilişkisel veritabanının yetmediğini gösteriyor mu? Ancak bu durumda özel bir vektör veritabanına geçin.

Aryasoft ile Kurumsal RAG

Aryasoft, SQL Server, Azure SQL ve PostgreSQL üzerindeki deneyimiyle RAG projelerinizin veri katmanını tasarlar: verinin hangi platformda kalacağı, vektör aramanın nasıl yapılacağı, erişim kontrolünün aramaya nasıl taşınacağı ve kişisel verilerin nasıl korunacağı. Sahada gördüğümüz en büyük risk, maskelenmemiş verilerle beslenen RAG uygulamalarının yetki sınırlarını aşan yanıtlar üretmesidir; bu yüzden güvenliği ilk günden mimarinin parçası yaparız. Ayrıntılar için veri analitiği ve yapay zekâ hizmetlerimize, veri yönetişimi tarafı için veri yönetişimi yazımıza göz atabilirsiniz.

Sıkça Sorulan Sorular

Kaynaklar

Bu rehberdeki teknik bilgiler Kasım 2026’da aşağıdaki kaynaklarla karşılaştırıldı.

1. pgvector
2. PostgreSQL dokümantasyonu: Row Security Policies
3. Microsoft Learn: Vector Search and Vector Index
4. Microsoft Learn: Row-level security
5. Microsoft Learn: Retrieval Augmented Generation overview