Read replica'lar eşzamanlı dashboard'lar karşısında 'her şey için Postgres' yaklaşımını kurtaramıyor

Ne yaşandı

dev.to'da yayımlanan bir birinci ağızdan anlatı, bir ekip için "Postgres kullan, yeter" şeklinde dillere pelesenk olmuş öğüdünün işe yaramadığı anı izliyor: dashboard'lar eşzamanlı hale gelir gelmez, primary'yi korumak için ekledikleri read replica, yükün altında bu kez kendisi ezilmeye başladı.

Yazarın vardığı sonuç, başarısızlığın operasyonel değil yapısal olduğuydu; tek başına replikasyon bu sorunu çözemez.

Replica'lar darboğazı kopyalar, formatı değil

Yazıya göre refleks olarak yapılan şey bir read replica ayağa kaldırmak, ağır analitik okumaları ona yönlendirmek ve sorunu çözülmüş saymak. Yazı, ClickHouse'un mühendislik ekibinin Mayıs 2026 tarihli rehberine dayanarak tersini savunuyor: replica'lar yüksek erişilebilirlik ve yatay okuma ölçekleme konusunda yardımcı olur ama primary'nin satır yönelimli sınırlarını miras alırlar. Analitik için veriyi kötü sıkıştırırlar ve hâlâ büyük miktarda bellek tüketen B-tree index'lere bağımlıdırlar.

Yazarın çerçevesinde replica, işi başka bir yere taşır ama altta yatan depolama formatına dokunmaz.

Dar sorgulara karşı çalışan satır depolama

Yazıda açıklandığı gibi Postgres veriyi 8 KB'lık sayfalarda tutar ve her satırda sabit 23 baytlık bir tuple header bulunur. Yalnızca iki kolona ihtiyaç duyan bir dashboard sorgusu bile satırların tamamını okur; dolayısıyla dar agregasyonlar tam satır I/O maliyeti öder. Bunu dashboard'ları yenileyen eşzamanlı kullanıcılarla çarpınca ek yük hızla birikir.

Asıl nerede kırıldığı

Yazı, bir veri mühendisliği ekibinin Eylül 2026 tarihli olay retrospektifine işaret ediyor: bir replica, aynı anda tetiklenen yüzlerce neredeyse özdeş agregasyonun saldırısına uğradı. CPU ve bellek baskısı fırladı; WAL replay hızlı sorgularla aynı kaynaklar için rekabet etti ve çabuk sorguları belirgin bir yavaşlığa sürükledi.

Yazı ayrıca Temmuz 2026 tarihli bir MotherDuck analizine dayanarak bu tür olayların arkasındaki gecikme eğrisini anlatıyor: bir ürünün erken dönemlerinde 50 ms tutan bir dashboard agregasyonu, on milyonlarca satırda beş saniyeye uzadı ve eşzamanlı yük bindiğinde sonunda zaman aşımına uğradı. Bu, yazının kullanıcıların analitiği anlık olarak algıladığı eşik olarak nitelediği 100 ms altı bütçenin çok dışındadır.

İkinci dereceden bir maliyet de var. Yazı, Brandur Leach ve Gunnar Morling'in uyarılarına değinerek, Postgres'te kuyruk benzeri iş yüklerini sıradan OLTP trafiğiyle karıştırmanın MVCC şişmesi, index parçalanması ve WAL birikmesi ürettiğini belirtiyor. Sistem yalnızca yavaş değildir; hasar da biriktirir.

Aşırı sağlama vergisi

Yazara göre bu yoldaki ekipler telafiyi donanımla yapma eğiliminde: dashboard zirvelerine göre boyutlandırılmış, geceleri büyük ölçüde boş duran ama yine de gün boyu fatura eden bir AWS r8gd.4xlarge instance'ı. Sav şudur: bir satır deposunu büyütmek format uyuşmazlığını çözmez; uyuşmazlığı yinelenen bir faturaya dönüştürür.

Varış noktası

Anlatı Postgres'e karşı bir argüman değil. Yazar işlemsel veriyi hâlâ orada tutuyor ve bu seçimi savunuyor. Bu anlatıdaki hata, aslında birbirinden farklı biçimlendirilmiş sorunlar olan defter tutma ile analitik deposu görevlerini tek bir motora yüklemektir.

Önerilen çözüm, veriyi etkili biçimde sıkıştıran ve bir sorgunun gerçekten dokunduğu kolonları okuyan, örnek olarak ClickHouse'un gösterildiği kolon yönelimli bir sunum katmanı; Postgres ise kayıt sistemi olarak kalıyor.

Neden önemli

"Postgres kullan, yeter" ekolü, erken aşama ürünler için altyapıyı gerçekten sadeleştirdiğinden ciddi bir ivmeye sahip. Bu anlatı ona somut bir başarısızlık sınırı veriyor: on milyonlarca satır üzerinde eşzamanlı dashboard agregasyonları; burada read replica'lar ve daha büyük instance'lar hesaplaşmayı yalnızca erteler. Müşteriye dönük analitik yapan ekipler, yavaşlayan WAL replay'in yanında replica CPU ve bellek sıçramaları gibi izlenecek spesifik bir sinyal ve OLTP'yi analitik sunum katmanından ayırmanın ne zaman isteğe bağlı olmaktan çıkıp zorunlu hale geldiğine dair daha net bir fikir ediniyor.