Her SaaS müşterisine kendi içerik alanını vermek

Neredeyse herkes satır düzeyinde son bulur, çünkü diğer ikisinin operasyonel maliyeti gerçek ve katlanarak artan bir şey. Bu da son hücreyi sorunun tümü yapar: filtreyi unutan sorguyu ne durdurur?

#Filtre eninde sonunda hep unutulur

Ekibiniz dikkatsiz olduğu için değil. Aritmetik yüzünden.

Olgun bir ürünün yüzlerce sorgusu vardır. Bazıları bir yıldır kimsenin açmadığı raporlama işindedir. Bazıları bir olay sırasında yazılmış yönetim aracındadır. Bazıları bir müteahhidin eklediği ve bir incelemecinin şöyle bir göz gezdirdiği bir modüldedir. Bunların her biri WHERE tenant_id = $1 demeyi hatırlamak zorunda.

Başarısızlık sessiz ve tamdır. Eksik bir filtre hata fırlatmaz. Bir müşterinin içeriğini bir başkasına döndürür; biri, bir açılır menüde rakibinin yayınlanmamış fiyatlandırma sayfasını fark edene kadar gayet normal görünen bir yanıtta.

PostgreSQL satır düzeyi güvenliği, sınırı hatanın altına taşır. Tabloya bir politika iliştirir, kiracıyı oturumda ayarlarsınız ve veritabanı, yüklemi (predicate) her sorguya uygular — kimsenin incelemedikleri dahil:

Artık filtreyi unutan sorgu, başka herkesinki yerine sıfır satır döndürür. Hata, görünmez bir sızıntı yerine görünür bir yokluk hâline gelir — ve bu fark, tartışmanın tümüdür.

corpusctl bunu, auth ve modül kayıt defterinin yanında çekirdekte yapar. Her uygulama sorgusu hâlâ açıkça kiracı kapsamına alınır; RLS ikinci savunma hattıdır, birincisi değil. Bir ikinci hattın anlamı, birincisinin çöktüğü gün orada olmasıdır.

Tablolar ayrıca kiracıya göre hash-partition edilir; böylece büyük bir müşteri, herkesin sorgu planlarını bozmaz.

#Bir kullanıcı bir kiracı değildir

Sonradan en pahalıya patlayan modelleme hatası.

Gerçek bir SaaS'ta insanlar birden çok müşteriye aittir. Bir ajans kullanıcısı sizin üç müşterinizi yönetir. Bir destek mühendisinin bir hafta boyunca bir hesaba okuma erişimi gerekir. Bir müteahhit marka ikide çalışır ve marka biri görmemelidir.

Modeliniz "kullanıcı kiracıya aittir" ise, bunların her biri bir yinelenen (mükerrer) hesaba dönüşür ve yinelenen hesaplar bir denetim sorunu olur.

corpusctl'in modeli: bir kullanıcı her alanda ayrı bir rol taşır. Birinde sahip, başka birinde editör, üçüncüsünde görünmez. Tek kimlik, N üyelik ve panel yalnızca kişinin gerçekten ait olduğu alanları gösterir.

Üstte kasıtlı bir kural var: bir alanın son sahibi rütbesi düşürülemez ya da çıkarılamaz. Sahibi olmayan bir alan, kimsenin yönetemediği bir alandır — kilit dışarıda kalır.

#Proje başına fiyatlandırma bir SaaS marjına ne yapar

CMS seçiminin teknik bir karar olmaktan çıktığı yer burası.

Sağlayıcı fiyatlandırma sayfalarından 17 Ağustos 2026 tarihinde doğrulandı:

Dikkat edilecek desen: bu birimler müşteri sayınızla ölçeklenir, müşteri başına geliriniz ile değil. Aylık 29 dolarlık bir planla çalışan bir SaaS, müşteri başına aylık 35 dolarlık bir CMS satırını kaldıramaz. Aritmetik basitçe tutmaz ve hacimle daha da iyileşmez.

corpusctl tam da bu durum için inşa edildi. Alanlar bir faturalandırma birimi değildir.

#Okumalar ve neden onların da ölçülmemesi gerektiği

Müşterilerle ölçeklenen ikinci maliyet trafiktir. CMS'iniz API çağrılarını ölçüyorsa, her müşterinin ziyaretçileri sizin sayaçınızdadır ve en yoğun müşteriniz, size ne öderse ödesin, en pahalı olanıdır.

corpusctl'in okuma yolu, çağrıyı kaldırarak sayaçı kaldırır. Yayınlama, içeriği nesne deposunda değişmez, hash ile adreslenen bir dosyaya yazar ve bir manifesti yeniler. Okuyucunun istemcisi slug'ı yerel olarak bir manifest parçasına çözer, ardından o adresi nginx kenar önbelleğinden çeker. Adres bir içerik hash'idir, dolayısıyla asla farklı içerik döndüremez — hiçbir geçersizleştirme stratejisi olmadan otuz gün önbelleğe alınabilir.

Ziyaretçi trafiği API'ye veya PostgreSQL'e hiç ulaşmaz. Yazma yolunuz editörlerinize göre boyutlanır; okuma yolunuz önbelleğinize göre boyutlanır.

#Plan düşürmeleri veriyi silmemeli

Bir SaaS'ta planını düşüren, kesintiye uğrayan ve geri dönen müşterileriniz olacak. CMS'in o anda ne yaptığı, sizin devraldığınız bir ürün kararıdır.

corpusctl her özelliği bir modül yapar — medya, arama, webhook'lar, SEO, GraphQL, içe aktarma, analitik — iki durumla:

Bir plan düşürülmesi modülleri disabled yapar. Asla veri silmez. Bu, bir destek makalesinde vaat edilen değil, kod tabanında uygulanan bir şeydir — ki bu önemli, çünkü üç ay sonra geri dönen müşteri içeriğinin orada olmasını bekler ve bunda haklıdır.

Modüller ayrıca birbirini import edemez. Aralarındaki tek kanal bir servis kayıt defteri ve bir olay veriyoludur ve bu kural kırılırsa CI derlemeyi başarısız yapar. Pratik sonuç: bir özelliği kaldırmak sistemi bozamaz, dolayısıyla kiracı başına özellik kümeleri bir fork değil, bir yapılandırma sorusudur.

#Çok kiracılı SaaS için herhangi bir CMS'i değerlendirme kontrol listesi

1. Bir proje bir faturalandırma birimi mi? 100. müşteri ne kadara mal olur?
2. İzolasyon nerede uygulanır — uygulamada mı, veritabanında mı?
3. Bir kullanıcı farklı kiracılarda farklı roller tutabilir mi?
4. Okumalar ölçülüyor mu? Kim tarafından — siz mi, yoksa müşterilerinizin ziyaretçileri mi?
5. Veriye plan düşürüldüğünde ne olur?
6. Bir kiracıyı panelde bir insan olmadan, API'den sağlayabilir misiniz?
7. Okuyup faturalandırabileceğiniz kiracı başına bir kota sayaçı var mı?

Birinci soru, siz ikinci soruya gelmeden önce adayların çoğunu eler.

İlgili: Headless CMS karşılaştırması · corpusctl vs Sanity

Next.js ile savaşmak yerine ona uyan bir headless CMS