PL/SQL'in öldüğünü kaç kez okuduğumu artık sayamıyorum. İlki muhtemelen 2014 civarıydı; Hacker News'te birisi tüm mantığın uygulama katmanına ait olduğunu açıklıyordu. Sonra mikroservis dalgası geldi. Sonra Spark. Sonra dbt. Sonra lakehouse savunucuları. Sonra birinin bir sigorta CFO'sunu yasal karşılıkların Airflow tarafından orkestre edilen bir Python notebook'unda hesaplanabileceğine ikna etmeye çalıştığı kısa bir an.
Bu arada, düzenleyicilerin her çeyrek okuduğu sayıları üreten gerçek sistemler hâlâ, ezici çoğunlukla, 2011'den beri yamanan bir Oracle veritabanı içinde çalışan PL/SQL paketleridir. Bunun sebebi bankaların ve sigortacıların aptal veya yavaş olması değil. Sebep, yerine geçecek olanı satmaya çalışanların hiçbirinin PL/SQL'in onlar için aslında ne yaptığını anlamaya zahmet etmemesi.
PL/SQL aslında neyin yerine geçer
Genç bir mühendis, IFRS 17 CSM hareketlerini veya BDDK düzenleyici oranlarını hesaplayan 4.000 satırlık bir package body'ye baktığında, eski (legacy) bir şey görür. Aslında baktığı şey şu beş özelliğin birleşimidir:
- Serileştirilebilir izolasyon sunan bir işlemsel yürütme motoru
- Depolama katmanına sıkı sıkıya bağlı bir tip sistemi
- Sıralamanın garanti edildiği, tek süreçli ve deterministik bir runtime
- Her DML'in bir oturuma, kullanıcıya ve zaman damgasına kadar izlenebildiği bir denetim yüzeyi
- Kodun, değiştirdiği veriye komşu yaşadığı bir dağıtım modeli
PL/SQL'i değiştirmek bir dili değiştirmek değildir. Bu beş özelliği aynı anda değiştirmektir. Çoğu modern yığın bunlardan birini değiştirir ve diğer dördünü sessizce yere bırakır.
Kimsenin konuşmak istemediği yasal raporlama sorunu
Türk sigortacılığında aylık Hazine raporlama döngüsü affetmez. Sunduğunuz sayılar, savunduğunuz sayılardır. AKS bildiriminizdeki teknik karşılıklar genel muhasebeyle mutabık değilse, Spark işinizin stragglers sorunu olduğunu ve shuffle'ın garip biçimde bölündüğünü açıklama şansınız yoktur. Bulgu alırsınız.
Operasyonel gereksinimler somuttur:
- Üç yıl sonra, talep üzerine, kuruşuna kadar yeniden üretilebilirlik
- Tek bir poliçenin karşılık hesaplamasını izole biçimde yeniden çalıştırıp birebir aynı sonucu alabilme yeteneği
- Düzenlenmiş bir rakama dokunan her mantık satırının denetlenebilir değişiklik geçmişi
- Raporlama döneminin, kısmen hesaplanmış durumu sızdırmayacak bir işlemsel sınır içinde kapatılması
Düzgün bir değişiklik yönetimi süreciyle veritabanına commit edilmiş bir PL/SQL paketi tüm bunları neredeyse bedavaya verir. Modern bir veri yığını size bir Git deposu, bir CI hattı, altı YAML dosyası, bir feature store, çoğunlukla çalışan bir lineage aracı ve orkestratör bir görevi iki kez tetiklediğinde nasıl kurtaracağınızı açıklayan 40 sayfalık bir runbook verir.
Performans argümanı tersine dönmüş durumda
PL/SQL'e karşı standart söylem, yatay ölçeklenemediğidir. Bu doğru ve neredeyse her zaman alakasızdır. Yasal raporlama iş yükleri web ölçekli değildir. Orta ölçekli bir Türk sigortacısı döngü başına beş ila elli milyon poliçe-kaydı arasında bir şey işler. Bu, tek bir Exadata düğümünün buffer cache'ine rahatça sığar.
Bu ölçekte asıl önemli olan veri yerelliğidir. Bir satırı veritabanından dışarıdaki bir hesaplama motoruna her taşıdığınızda, serileştirip, geri çözüp, işleyip, geri yazdığınızda, PL/SQL'in ödemediği bir ağ atlamasının bedelini ödüyorsunuz. Referans tablolarına ağır join'ler içeren satır-satır aktüeryal mantık için, veritabanı içindeki küme tabanlı SQL, herhangi bir dış runtime'a karşı bir büyüklük mertebesi farkla kazanır. Bunu aynı donanım bütçesinde PySpark'a karşı birden fazla kez kıyasladım. Yakın bir yarış değil.
PL/SQL'in gerçekten kaybetmeyi hak ettiği yerler
PL/SQL'in her yere ait olduğunu savunmuyorum. Şunlar için berbat bir seçimdir:
- Milisaniye aralığında gecikmeye duyarlı veya kullanıcıya dönük herhangi bir şey
- ML model eğitimi ve çoğu ML çıkarımı
- Onlarca tüketiciye yayılması gereken olay tabanlı iş yükleri
- Onu yazan ekibin aslında SQL bilmediği her şey
Son nokta, herhangi bir mimari argümandan daha fazla zarar veriyor. PL/SQL kod tabanlarının çürüme nedeni PL/SQL'in kötü olması değildir. Sebep, disiplinli, paket kapsamlı, düzgün enstrümante edilmiş PL/SQL yazabilen mühendis kuşağının daralması ve bu sistemleri devralan kişilere tech lead'leri tarafından bu dili öğrenmenin kariyer açmazı olduğunun söylenmesidir. Onlar da view'larla sarmalıyor, Python'da bunun %80'ini yeniden hesaplayan paralel bir pipeline kuruyor ve artık iki kaynaklı gerçeğiniz ve iki kat hatanız oluyor.
Modern araçların yerine geçmeyi gerçekten hak etmek için neye ihtiyacı olurdu
Biri PL/SQL'i yasal raporlamadan ciddi şekilde yerinden etmek istiyorsa, çıta özellikler değildir. Operasyonel niteliklerdir. Yerine geçecek olanın şunları sağlaması gerekir:
- Sadece görev başına değil, tüm pipeline boyunca işlemsel semantik
- Yeniden denemede deterministik yürütme, birebir aynı kayan nokta davranışı dahil
- Raporlanan bir rakamı üreten her kod sürümünün tek, sorgulanabilir geçmişi
- Toplu işlemi yeniden çalıştırmadan başarısız tek bir hesaplamayı saniyenin altında yeniden başlatma
- Düzenleyicinin denetçisinin tek bir toplantıda anlayabileceği bir güvenlik modeli
Delta Lake artı dbt artı Airflow artı bir lineage aracı, iyi bir günde bunlardan belki ikisini verir ve entegrasyon vergisini nöbetçi ekibiniz öder. Snowflake'in prosedürel uzantıları ve BigQuery'nin stored procedure'ları daha yakındır, ama onlar farklı sözdizimi ve daha kötü araçlarla PL/SQL'dir. Dürüst okuma şudur: sektör on beş yılını PL/SQL'in zaten yaptığını kötü biçimde yeniden icat etmekle geçirdi ve buna ilerleme dedi.
2026 gerçeği
Birlikte çalıştığım bankalar ve sigortacılar 2026'da PL/SQL'lerini söküp atmayacak. 2030'da da yapmayacaklar. Yapacakları şey — ve zekileri zaten yapmakta — PL/SQL'e yeniden birinci sınıf bir mühendislik disiplini olarak davranmak: düzgün sürüm kontrolü, ciddi kod incelemesi, uygulama kodu kadar titiz enstrümantasyon ve aslında oldukları kıdemli altyapı insanları gibi ücretlendirilen mühendislerle kadrolama.
PL/SQL'in öldüğü beyanı çoğunlukla bir işarettir. Size bunu söyleyen kişinin bir düzenleyici bildirimi imzalayan kişi olmadığını söyler. Hata kabul etmeyen sistemler moda olan dilde çalışmıyor. İşe yarayan dilde çalışıyor.