PostgreSQL RLS Performansı: Maliyet Gerçekte Nerede Saklı?

2 milyon satırlık çok kiracılı bir fatura tablosu üzerinde yapılan ölçümler, doğru indeksle eşleşen basit bir row-level security politikasının pratikte bedava olduğunu gösteriyor: açık bir WHERE koşuluyla aynı gecikme. Asıl maliyet, belirli uygulama tercihlerinde ortaya çıkıyor.

Tenant kimliğini almak için STABLE olarak işaretlenmemiş bir PL/pgSQL yardımcı fonksiyonu kullanmak, fonksiyonun inline edilmesini engelliyor ve tam tablo taramasına yol açıyor: normalde 0,2 ms süren bir sorgu 1,8 saniyeyi aşabiliyor. SQL fonksiyonları volatility ayarından bağımsız olarak inline edilip hızlı kalabiliyor — ta ki SECURITY DEFINER veya SET search_path eklenene kadar; bu durumda inlining bozuluyor ve SQL fonksiyonlarında bile saniyeler süren taramalar ortaya çıkıyor.

Üyelik kontrolünü IN (SELECT ...) ile yapan politikalar, planlayıcı sorguyu tek bir indeks aramasına indirgeyemediği için her sorguya yaklaşık 80 ms ekliyor; tenant değerini istek başına bir kez çözüp politikaya tek değer olarak vermek bu maliyeti ortadan kaldırıyor. Ayrı bir sorunda, lower() veya LIKE gibi leakproof olmayan fonksiyonlar sorgu içinde kullanıldığında PostgreSQL, indeksi sadece tenant_id için kullanıp o kiracının tüm satırlarını filtreden geçiriyor — anlık aramalar onlarca milisaniyeye çıkıyor; üretilmiş (generated) sütunlar veya desen eşleştirme operatörleriyle bu düzeltilebiliyor.

Mühendisler için çıkarımlar somut: tenant arama fonksiyonlarını STABLE (büyük kiracılar önemliyse PARALLEL SAFE) olarak tanımlayın, politikalarda kullanılan fonksiyonlara SECURITY DEFINER veya search_path sertleştirmesi uygulamaktan kaçının, üyelik kontrolünü politika içinde değil istek başına bir kez yapın ve lower()/LIKE karşılaştırmalarını indekslenebilir alternatiflerle değiştirin.