[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-multi-tenancy::tr":3,"gloss-cluster-multi-tenancy::tr":20,"gloss-next-multi-tenancy::tr":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"multi-tenancy","data-infra","Çok Kiracılılık (Multi-Tenancy)","Multi-tenancy (çok kiracılılık), bir uygulamanın tek bir deploy edilmiş örneğinin — tek bir kod tabanı, çoğunlukla tek bir veritabanı — birçok ayrı müşteriye (\"kiracı\" ya da \"tenant\", genellikle şirketler veya hesaplar) hizmet verdiği bir yazılım mimarisi desenidir; bu kiracıların her birinin verisi diğer tüm kiracılardan izole tutulmak zorundadır. Bunun karşıtı, her müşterinin tamamen ayrı bir deployment aldığı single-tenant (tek kiracılı) mimaridir. AI\u002FSaaS geliştiricileri için neden önemli: neredeyse her B2B SaaS, zorunlu olarak multi-tenant'tır — binlerce müşteriye binlerce ayrı altyapı yığını kurup işletmeden hizmet vermenin tek ekonomik olarak sürdürülebilir yoludur bu — ve izolasyon sınırını yanlış kurmak, büyüyen bir SaaS'ın yapabileceği en sonuçları ağır hatalardan biridir; çünkü kiracılar arası veri sızıntısı bug'ı genellikle diğer birçok bug'ın aksine felaket boyutundadır (bir destek talebi bir güvenlik olayına, bir kurumsal anlaşma bir davaya dönüşebilir). AI özellikleri, bunun yanlış gidebileceği yeni bir yüzey ekler: paylaşılan bir vektör indeksi, paylaşılan bir prompt-caching katmanı veya paylaşılan bir fine-tune edilmiş model, izolasyon yalnızca ana ilişkisel veritabanında değil her katmanda zorunlu kılınmazsa bir kiracının verisini kazara başka bir kiracının sonuçlarına sızdırabilir. Nasıl çalışır: izolasyon ve operasyonel maliyet açısından artan sırayla üç yaygın desen vardır: paylaşılan veritabanı, paylaşılan şema (her kiracının satırları aynı tablolarda yaşar, yalnızca bir `tenant_id` sütunuyla ayırt edilir — işletmesi en ucuz olan ama izolasyonu tamamen her tek sorgunun doğru şekilde tenant'a göre filtrelenmesine bağlı olan, bir geliştirici unutursa yapısal bir güvenlik ağı bulunmayan yaklaşım); paylaşılan veritabanı, ayrı şema (her kiracı tek bir veritabanı içinde kendi Postgres şemasını alır — daha güçlü izolasyon, orta düzey operasyonel maliyet); ve kiracı başına ayrı veritabanı (en güçlü izolasyon, en yüksek operasyonel maliyet, genellikle katı uyumluluk gereksinimleri olan büyük kurumsal müşteriler için ayrılır). Row-level security (satır düzeyinde güvenlik, bir Postgres özelliği), paylaşılan şema desenine veritabanı tarafından zorunlu kılınan bir güvenlik ağı eklemek için giderek daha fazla kullanılıyor; böylece `WHERE tenant_id = ?` koşulunu unutan bir sorgu bile başka bir kiracının satırlarını döndüremez. Somut örnek: bir AI CRM SaaS'ı, ilişkisel verisi için paylaşılan veritabanı, paylaşılan şema desenini kullanır (en ucuz, mevcut ölçeklerinde gayet iyi çalışır) ama her tabloya yapısal bir güvenlik ağı olarak row-level security politikaları ekler; ayrıca AI destekli kişi aramasında kiracı başına ayrı namespace'ler kullanır vektör veritabanında — yani ilişkisel sorguda ya da vektör sorgusunda `tenant_id` filtresini atlayan bir bug bile veri sızdıramaz, çünkü izolasyon yalnızca bir geliştiricinin gelecekte yanlış yazabileceği uygulama kodunda değil, altyapı katmanında zorunlu kılınmıştır.","Multi-tenancy, tek bir uygulama örneğinin birden fazla müşteriye (\"kiracıya\") hizmet verirken her kiracının verisini izole tuttuğu mimaridir.",null,[11,14,17],{"slug":12,"name":13},"namespace","Ad Alanı (Namespace)",{"slug":15,"name":16},"postgresql","PostgreSQL",{"slug":18,"name":19},"sharding","Sharding (Parçalama)",[21,25,28,31,34,38,41,44,47,50,54,57],{"slug":22,"category":5,"name":23,"updated_at":24},"acid","ACID","2026-08-24T02:46:37+00:00",{"slug":26,"category":5,"name":27,"updated_at":24},"ann-search","ANN Arama (Yaklaşık En Yakın Komşu)",{"slug":29,"category":5,"name":30,"updated_at":24},"backpressure","Geri Basınç (Backpressure)",{"slug":32,"category":5,"name":33,"updated_at":24},"batch-processing","Toplu İşleme (Batch Processing)",{"slug":35,"category":5,"name":36,"updated_at":37},"bm25","BM25","2026-08-24T02:46:38+00:00",{"slug":39,"category":5,"name":40,"updated_at":24},"cache","Önbellek (Cache)",{"slug":42,"category":5,"name":43,"updated_at":24},"cap-theorem","CAP Teoremi (CAP Theorem)",{"slug":45,"category":5,"name":46,"updated_at":24},"change-data-capture","Değişiklik Veri Yakalama (CDC)",{"slug":48,"category":5,"name":49,"updated_at":24},"chroma","Chroma",{"slug":51,"category":5,"name":52,"updated_at":53},"chunk-overlap","Parça Örtüşmesi","2026-08-24T03:30:02+00:00",{"slug":55,"category":5,"name":56,"updated_at":24},"columnar-storage","Sütun Tabanlı Depolama",{"slug":58,"category":5,"name":59,"updated_at":24},"connection-pooling","Bağlantı Havuzlama (Connection Pooling)"]