PostgreSQL'i Rust'ta Yeniden Yazmak: Zorluklar ve Dersler

PostgreSQL gibi onlarca yıllık bir C tabanlı veritabanını Rust'a taşımak, düşük seviyeli sistem programlama, geriye dönük uyumluluk ve performans dengesi açısından ciddi zorluklar barındırıyor. Bellek yönetiminde manuel malloc/free yapısından Rust'ın sahiplik modeline geçiş, MemoryContext yerine Rc/Arc kullanımıyla ölçülen benchmarklarda yüzde 12-15 CPU ek yükü getirmiş. Ayrıca Rust'ın varsayılan yığın boyutu, PostgreSQL'in sorgu planlamasındaki derin özyinelemeli çağrılarla çelişiyor.

Eşzamanlılık modeli de yeniden tasarlanmış: pthread_mutex yerine Mutex/RwLock, spinlock'lar yerine crossbeam gibi harici bağımlılıklar kullanılmış; bu değişiklikler derleme zamanında güvenlik sağlasa da kod karmaşıklığını artırmış. Async-std'ye geçiş, yüksek eşzamanlılık altında gecikme sıçramalarına yol açmış. 300'den fazla resmi uzantının uyumluluğunu korumak için hibrit C/Rust çalıştırma modeli ve SPI uyumluluk katmanı geliştirilmiş; disk üzerindeki veri formatının bayt düzeyinde korunması da ayrı bir mühendislik problemi olmuş.

İlk testlerde TPC-C iş yüklerinde yüzde 8-12 performans kaybı gözlemlenmiş; #[inline(always)], const generics ve thread-local önbellekleme gibi optimizasyonlarla bu açık kapatılmaya çalışılmış. Sıralama ve hash join gibi bellek yoğun işlemler, cranelift tabanlı JIT yeniden implementasyonu gerektirmiş. Projenin çıkardığı en önemli ders, kademeli göçün (önce depolama katmanı, sonra sorgu motoru) ve unsafe kullanımını FFI ile performans kritik noktalara sınırlamanın esas olduğu; tam MVCC modeli ve Rust-native sorgu planlayıcısı gibi hedefler henüz tamamlanmamış.