- Postgres'u kendi kendine barındırmak karmaşık ya da riskli değildir; yönetilen hizmetlerden daha ucuzdur ve performans ayarı açısından daha esnek bir yaklaşımdır
- Çoğu bulut veritabanı hizmeti, açık kaynak Postgres'in hafifçe değiştirilmiş bir sürümünü çalıştırır; asıl fark pratikte operasyon otomasyonu düzeyindedir
- Gerçek üretim örneklerinde kendi kendine barındırılan Postgres, binlerce kullanıcıyı ve on milyonlarca sorguyu kararlı biçimde işler ve bakım için gereken süre de oldukça düşüktür
- AWS RDS gibi yönetilen hizmetlerin fiyatlarının artması nedeniyle, aynı maliyetle çok daha yüksek özelliklere sahip sunucuları doğrudan işletmek mümkün hale gelmiştir
- Altyapı yönetimi çok karmaşık olmayan orta ölçekli ekipler için kendi kendine barındırma, maliyet verimliliği ve performans açısından gerçekçi bir alternatiftir
Bulut merkezli anlatının değişimi
- Geçmişte çoğu şirket veritabanlarını kendi sunucularında doğrudan çalıştırıyordu; bu yaklaşım daha düşük ağ gecikmesi ve daha hızlı bir yapı sunuyordu
- 1980'lerden 2000'lere kadar uygulama sunucusu ile veritabanı sunucusunun aynı fiziksel donanım üzerinde bulunduğu durumlar yaygındı
- Amazon RDS (2009)'in çıkışı, yedekleme, yama ve izlemeyi otomatikleştiren cazip bir teklif olarak görüldü
- İlk dönemde, özel sunuculara yakın bir maliyetle operasyon yükünü azaltabiliyordu
- 2015 sonrasında bulut kullanımının hızlanmasıyla birlikte, altyapıyı doğrudan yönetmenin verimsiz olduğu algısı yaygınlaştı
- AWS'nin altyapıyı üstlendiği, geliştiricilerin ise uygulama mantığına odaklandığı yapı standart haline geldi
- 2025 itibarıyla RDS fiyatları ciddi biçimde yükselmiş durumda ve aynı bütçeyle çok daha güçlü özel sunucular kiralanabiliyor
- Örnek: db.r6g.xlarge örneği (4 vCPU, 32GB RAM) aylık $328 iken, bu bütçeyle 32 çekirdekli ve 256GB RAM'li bir sunucu kiralanabiliyor
Yönetilen hizmetlerin gerçek yapısı
- AWS RDS, temelde standart Postgres'e AWS'ye özgü izleme ve yedekleme sistemlerinin eklenmiş halidir
- EBS snapshot tabanlı yedekler, Chef/Puppet/Ansible ile yapılandırma yönetimi, PgBouncer bağlantı havuzu, CloudWatch izleme ve otomatik failover betikleri buna dahildir
- Bu yapı teknik olarak çok karmaşık değildir; asıl değer operasyon otomasyonu ve ilk kurulum kolaylığıdır
- Aynı özellikteki bir sunucuyla RDS'den kendi kendine barındırmaya geçildiğinde, performansın aynı kaldığı hatta yer yer arttığı görülmüştür
- RDS'de sınırlı olan parametreler doğrudan ayarlanabildiği için performans optimizasyonu mümkün olur
Kendi kendine barındırmanın operasyonel karmaşıklığı
- DigitalOcean'daki 16 vCPU / 32GB RAM / 400GB diskli sunucuya geçiş yaklaşık 4 saat sürmüş ve sonrasında kararlı çalışma doğrulanmıştır
- Yüksek erişilebilirlik gerektiren ürünlerde aylık yaklaşık 30 dakikalık yönetim süresi gerekirken, trafiği düşük hizmetlerde tam otomasyon mümkündür
- Düzenli bakım döngüsü
- Haftalık (10 dakika): yedek doğrulama, yavaş sorgu loglarının incelenmesi, disk kapasitesinin kontrolü
- Aylık (30 dakika): güvenlik güncellemeleri, yedek saklama politikasının gözden geçirilmesi, kapasite planlaması
- Üç aylık (2 saat): izleme panellerinin güncellenmesi, ayar optimizasyonu, geri yükleme testleri
- Arızalara müdahale sorumluluğu doğrudan size aittir, ancak RDS'de de arızalar yaşanır ve sonuçta yine geliştiricilerin müdahalesi gerekir
- Doğrudan işletimde güncelleme zamanını ve riskli geçiş aralıklarını kendiniz ayarlayabilirsiniz; bu da istikrarı korumayı kolaylaştırır
Kendi kendine barındırmanın uygun olmadığı durumlar
- İlk aşamadaki geliştiriciler hızlı prototip üretirken yönetilen hizmetler daha pratiktir
- Büyük ölçekli şirketler için özel veritabanı mühendisleri istihdam etmek ya da iş gücü maliyetini azaltmak adına buluta devretmek daha verimli olabilir
- Düzenlemeye tabi sektörlerde (PCI-DSS, HIPAA vb.) sertifikalı yönetilen platformların kullanılması gerekebilir
Başlıca yapılandırma noktaları
- Bellek ayarları: donanıma göre
shared_buffers, effective_cache_size, work_mem, maintenance_work_mem gibi değerlerin ayarlanması gerekir
- Örnek:
shared_buffers RAM'in %25'i, effective_cache_size ise %75'i olarak ayarlanabilir
- Bağlantı yönetimi:
pgbouncer kullanılarak bağlantı havuzu kurulabilir; Python asyncio ortamlarında verimli çalışır
max_connections = 200, log_connections = on gibi temel ayar örnekleri verilir
- Depolama ayarı: NVMe SSD ortamlarında
random_page_cost = 1.1, effective_io_concurrency = 200 gibi değerlerle ince ayar yapılabilir
- Rastgele okuma hızının artması, sorgu planlamasının optimize edilmesine yardımcı olur
- WAL ayarları: dayanıklılık ve performans için
wal_level = replica, max_wal_size = 2GB, checkpoint_completion_target = 0.9 gibi ayarlar düzenlenebilir
Sonuç
- Tüm altyapıyı doğrudan işletmek gerekmeyebilir, ancak Postgres kendi kendine barındırma için mantıklı bir alan olarak öne çıkıyor
- RDS için ayda $200'den fazla harcıyorsanız, çekirdek olmayan bir veritabanını test sunucusuna taşıyarak deneme yapmak değerlidir
- Gelecekte altyapının yönetilen hizmetler ile kendi kendine barındırmanın karıştığı hibrit bir yapıya evrilmesi olası görünüyor
- Postgres, maliyet/fayda açısından güçlü bir kendi kendine barındırma adayı olarak değerlendiriliyor
4 yorum
Depolama için de 11 nine garanti ediliyorsa, bulutu sanki işletmesi zormuş gibi kullanıyorlar; aslında zor olduğu için zaten bulutu kullanıyoruz :)
Aslında 3 node'lu bir cluster işletmek o kadar da kolay olmayacaktır.
Hacker News yorumları
Ben self-hosting işini bir sorumluluk meselesi olarak görüyorum
Birkaç SaaS ürünü kendi kendime host ediyorum; AWS'den çok daha ucuz ve performansı da belirgin şekilde daha iyi
Ama müşteri projelerinde AWS maliyetini ödemeleri için ikna ediyorum. Çünkü donanım erişilebilirliği sorumluluğunu başka tarafa devretmek mümkün oluyor
Bütçe kısıtlıysa RDS maliyeti ağır geliyor. Hetzner üzerinde 3 düğümlü bir Galera cluster'ı birkaç dolara çalıştırmak çok daha ekonomik
Ama Cloudflare ya da SQS gibi managed service'lerde de zaman zaman kesinti yaşanıyor. Sonuçta kusursuz kararlılık hiçbir yerde yok
AWS Aurora Serverless
Cloud SQL tarafında ise maliyet yapısı daha karmaşık; yedeklemeyi bir kez ayarlayınca iş bitiyor
Self-hosting'in çoğu kişi için doğru tercih olduğu iddiasına katılmıyorum
Bana göre ancak bütçe çok sıkışıksa ya da ayrı bir mühendis ayırabilecek kadar büyük bir ölçekteyseniz kendi hosting'inizi yapmak mantıklı
Küçük işletmeler için buluta bırakmak daha gerçekçi. Kurulumdan sonra ayda 30-120 dakika yönetim yeterli oluyor gibi görünüyor
Heroku ya da Render gibi PaaS'ler sıradan geliştiriciler tarafından da kullanılabilir ama çok daha pahalılar
Sonuçta uygulama kurtarma otomatik değilse sabah 3'te uyanmak yine değişmiyor
İç araçlar için Docker'a bir Postgres eklemek 5 dakika sürer
‘Managed database’ tanımı kafa karıştırıcı
Benim için asgari gereksinimler otomatik yedekleme, indeks optimizasyonu, çoklu veri merkezi failover, point-in-time recovery, slow query analizi, storage tahmini
Bunlar aylık ücret karşılığında veriliyorsa self-hosting tartışmasının pek anlamı kalmıyor
Sonunda iki kişi alıyorsunuz, iş sıkıcı geldiği için gereksiz iyileştirmelere kalkışıp 6 ayı boşa harcadığınız da oluyor
Managed DB'ler VPS'e kıyasla fazla pahalı
Bir kullanım kolaylığı primi bekliyordum ama gerçekte birkaç kat daha pahalılar. Bu yüzden büyük projeler dışında kullanmıyorum
Yazıda geçen yüksek erişilebilirlik (HA) kısmı yetersiz. Sadece WAL ayarıyla açıklanamaz. Replikasyonun maliyeti yüksek
Postgres'in HN'de neden bu kadar abartıldığını anlamıyorum
MongoDB'deki gibi otomatik failover yapan bir HA cluster'ı kolay kurmanın bir yolu yok. Gerçek üretim ortamında bunu nasıl çözdüklerini merak ediyorum
İlgili tartışma: PostgreSQL mail listesi
Pratikte tüm bağlantılar kopuyor, cache sıfırlanıyor ve upgrade sırasında kesinti kaçınılmaz oluyor
Oracle RAC tek istisna; PostgreSQL böyle bir mimariye sahip değil. YugabyteDB buna en yakın alternatif
Çoğu uygulama birkaç saatlik kesintiyi tolere ediyor. Bu karmaşık otomasyonu ancak büyük şirketler kaldırabiliyor
Kubernetes ortamında CloudNativePG de iyi bir seçenek.
pg_auto_failover daha basit ama kısıtları var
Autobase projesine bakınca self-hosting için gereken işleri otomatik yaptığını görüyorsunuz
15 yıldır Postgres'i her zaman self-hosted kullandım ve neredeyse hiç sorun yaşamadım
Tek ciddi konu, ORM yükseltmelerine uyum sağlamak için PG sürüm migrasyonu yapmam gerektiğinde çıktı. Dikkatli sistem yönetimi ile çözülebiliyordu
Fly.io üzerinde yönetilmeyen Postgres'i kendim çalıştırdım ve gerçekten çok zorlandım
Düğümler sık sık ölüyordu, manuel olarak repmgr ile toparlamak zorunda kalıyordum; sonunda süreci şirket içi wiki'ye yazdım
Cluster'ın amacı yüksek erişilebilirlikken neden zombi primary durumunu otomatik yönetmediğini anlayamadım
Sonunda managed Postgres'e geçtim; arıza anında işi başkasının çözmesi gerçekten büyük rahatlık
Bu başlıktaki birçok yorum ölçek, iş yükü, ekip, zaman, işin aşaması, ölçeklenebilirlik gereksinimleri gibi gerçek dünyadaki etkenleri göz ardı ediyor
Self-hosting doğru da olabilir yanlış da; ama tartışma fazla basite indirgenmiş
Geliştiricilerin derdi şu tür şeyleri self-hosting yaparken bu unsurların takdir edilip edilmediğinin de önemli olması gibi görünüyor. Bulut maliyeti daha fazla çıksa bile, self-hosting ile sağlanan maliyet tasarrufu kabul görmüyorsa, kapsanması gereken alanı azaltmak için bulut servisini kullanıp idare etmek daha rahat olur.