Yönetilen PostgreSQL mi, Kendi Sunucunda mı? Kritik Kararlar

⏱️ 6 dk okuma📅 29 Ağustos 2026

Üretim ortamında PostgreSQL çalıştırmayı planlayan teknik karar vericiler için asıl mesele, veritabanı platformunun günlük işletim sorumluluklarının kimde kalacağıdır. Kendi altyapısında yönetilen (self-hosted) bir PostgreSQL kurulumu ile yönetilen (managed) bir bulut hizmeti arasındaki tercih; kontrol düzeyi, mühendislik kapasitesi, dayanıklılık, güvenlik, maliyet öngörülebilirliği ve risk toleransı gibi başlıklarda net bir denge kurmayı gerektirir. Bu yazı, Microsoft’un Azure blogunda Lauro Ojeda tarafından paylaşılan karşılaştırmayı temel alarak iki modelin operasyonel etkilerini özetliyor.

PostgreSQL neden tercih ediliyor?

PostgreSQL, küçük uygulamalardan kurumsal sistemlere kadar geniş bir yelpazede kullanılan, standartlara dayalı, açık kaynaklı ilişkisel bir veritabanıdır. Geniş ekosistemi ve güçlü genişletilebilirlik yetenekleri, onu farklı ölçeklerdeki ekipler için doğal bir seçim haline getiriyor. Ancak PostgreSQL’i seçmek, onu nerede ve nasıl çalıştıracağınıza dair soruyu çözmüyor: kendi altyapınızda mı, sanal makinede mi, yoksa yönetilen bir bulut hizmetinde mi?

Yönetilen ve kendi sunucunda çalıştırılan modellerin farkı

Kendi altyapısında çalıştırma modeli; işletim sistemi, PostgreSQL kurulumu ve destekleyici altyapı üzerinde doğrudan kontrol sağlar. Bunun karşılığında platformun tüm katmanlarının işletim sorumluluğu kuruma kalır. Yönetilen PostgreSQL hizmetleri ise (örneğin Azure Database for PostgreSQL ve Azure HorizonDB) belirli altyapı ve platform sorumluluklarını hizmet sağlayıcıya devrederek ekiplerin mühendislik kapasitesini uygulama, veri modeli ve performans tarafına ayırmasına imkan tanır.

Ölçek büyüdükçe ortaya çıkan “operasyonel vergi”

Kendi sunucunda çalıştırma modeli, kaynak metnin “operasyonel vergi” olarak tanımladığı sürekli bir yük getirir: veritabanı platformunu hazırlamak, güvenli hale getirmek, izlemek, bakımını yapmak ve kurtarmak için gereken zaman, uzmanlık ve kaynak. Bu işler zorunludur ama çoğu zaman uygulamanın kendisine değer katmaz.

Bir PostgreSQL örneği sanal makine veya kurum içi sunucuda çalıştırıldığında mühendislik ekibinin üstlendiği başlıca sorumluluklar şunlardır:

Uçtan uca yaşam döngüsü yönetimi: Donanım tedariki, veri merkezi altyapısının sürdürülmesi, işletim sistemi kurulumu ve PostgreSQL’in doğru yapılandırılması.
Güvenlik sıkılaştırma: Güvenlik duvarları, işletim sistemi yamaları, aktarımda ve dinlenmede şifreleme gibi kontrollerin elle yönetilmesi.
Yüksek erişilebilirlik (HA): Patroni veya Pacemaker gibi araçlarla karmaşık replikasyon ve failover mekanizmalarının kurulması; bu yapıların test edilip sürdürülmesinin zorluğu.
Felaket kurtarma: Yedekleme ve kurtarma süreçlerinin, point-in-time restore dahil, tasarlanması, otomatikleştirilmesi, izlenmesi ve test edilmesi.
Kimlik yönetimi: Veritabanı kullanıcı ve parolalarının elle yönetilmesi, birbirinden ayrık kimlik depolarının oluşması.

Bu görevler, ekiplerin uygulama geliştirme, veri modeli iyileştirme ve performans optimizasyonu için ayırabileceği süreyi tüketir.

Yönetilen PostgreSQL ne zaman anlamlı?

Yönetilen veritabanı hizmetleri, tanımlanmış altyapı ve platform sorumluluklarını bulut sağlayıcısına devrederek işletim modelini değiştirir. Kaynak metne göre sağlayıcı çoğunlukla temel altyapıyı, işletim sistemi bakımını, servis yamalarını ve fiziksel veri merkezi güvenliğini üstlenir. Müşteri; verilerinden, veritabanı yapılandırmasından, erişim politikalarından, uygulama tasarımından ve iş yükü performansından sorumlu olmayı sürdürür.

Kendi yönetiminde PostgreSQL ne zaman doğru?

Kendi yönetimindeki model; işletim sistemi düzeyinde erişim, özel altyapı, desteklenmeyen uzantılar, özelleştirilmiş dağıtım desenleri ya da yama ve değişiklik takvimi üzerinde doğrudan kontrol gerektiğinde tercih edilir. Aynı zamanda PostgreSQL platform mühendisliği olgunluğu yüksek, güvenilir otomasyona ve test edilmiş kurtarma pratiklerine sahip, yeterli çağrı (on-call) kapasitesi olan kurumlara da uyar. Bu senaryolarda ek sorumluluk, kaçınılan bir yük değil, kontrol ve esneklik için bilinçli bir ödünleşimdir.

Paylaşılan sorumluluk modeli perspektifi

Yönetilen PostgreSQL hizmetlerini değerlendirmenin bir yolu, bulutun paylaşılan sorumluluk modelidir. Kendi sunucunda çalıştırmadan IaaS’a, oradan PaaS’a doğru ilerledikçe altyapı ve platform yığınının giderek büyüyen bir kısmı sağlayıcı tarafından işletilir. IaaS dağıtımında kurum, sanal makineleri, işletim sistemlerini ve veritabanı yazılımını yönetmeyi sürdürür. PaaS modelinde ise işletim sistemi ve altyapının önemli bir kısmının sorumluluğu sağlayıcıya geçer.

Bu geçiş, sorumluluğu ortadan kaldırmaz. Dağıtım modelinden bağımsız olarak veri, kimlikler, yapılandırmalar, erişim yönetimi, uyumluluk gereksinimleri ve uygulama davranışı kurumun sorumluluğunda kalır. Yalnızca işletim sistemi yönetimi, fiziksel altyapı, platform bakımı ve güvenlik yığınının belirli katmanları yönetilen hizmete devredilir.

Yönetilen hizmetlerin sağladığı kolaylıklar

Kaynak metin, yönetilen PostgreSQL hizmetlerinin manuel altyapı ve platform görevlerini yönetilen yeteneklerle nasıl değiştirdiğine dair dört ana başlık ortaya koyuyor.

1. Otomatik yaşam döngüsü yönetimi

Kendi sunucunda: Ekipler güvenlik uyarılarını takip etmek, yamaları elle indirmek ve hem işletim sistemi hem veritabanı için kesinti planlamak zorundadır. Yönetilen hizmette: Sağlayıcı, işletim sistemi bakımını ve küçük sürüm güncellemeleri dahil servis güncellemelerini çoğunlukla üstlenir. Müşteriler bakım pencerelerini genellikle yapılandırabilir; büyük sürüm yükseltmeleri ise uyumluluk testleri ve takvim kontrolü için müşteri tarafından başlatılabilir.

2. Tasarım gereği yüksek erişilebilirlik

Kendi sunucunda: Manuel HA; birden fazla sanal makine, replikasyon gecikmesi ve witness düğüm yönetimi gerektirir; sürekli test edilmediğinde failover güvenilirliği düşer. Yönetilen hizmette: Yüksek erişilebilirlik, sağlayıcı tarafından yönetilen bir yapılandırma seçeneği olarak sunulur. Okuma yoğun iş yükleri için read replica desteği, HA tasarımından ayrı olarak değerlendirilmesi gereken bağımsız bir yetenektir.

3. Akıllı depolama ve kurtarma

Kendi sunucunda: Disk kapasitesinin tükenmesi yüksek öncelikli olaylara yol açabilir; depolama tedariki, izleme, yedekleme otomasyonu ve kapasite planlaması sürekli ilgi ister. Yönetilen hizmette: Depolama büyümesi, otomatik yedekleme ve point-in-time restore platforma yerleşik olarak gelir. Saklama süreleri, depolama sınırları, yedeklilik seçenekleri ve ölçekleme davranışı sağlayıcı, bölge, hizmet katmanı ve yapılandırmaya göre değişir.

4. Kurumsal güvenlik ve kimlik

Kaynak metindeki karşılaştırma tablosuna göre kimlik ve erişim yönetiminde iki modelin farkı şöyle özetlenebilir:

Özellik	Kendi Sunucunda	Yönetilen Hizmet
Kimlik doğrulama	Manuel parola rotasyonu, ayrık kimlik bilgisi depoları.	Merkezi kimlik yönetimi için yerel Microsoft Entra ID entegrasyonu.
Güvenlik duruşu	Statik parolalar ve manuel işlemler nedeniyle daha yüksek sızıntı riski.	Parolasız kimlik doğrulama desteği ile daha küçük saldırı yüzeyi.
Yönetim	DBA’ların kurumsal kullanıcıları veritabanı rolleriyle elle eşleştirmesi.	Entra kimlik ve grupları üzerinden merkezi erişim; veritabanı izinleri yine yönetim gerektirir.

Karar verirken kendinize sormanız gereken sorular

Kaynak metnin önerdiği değerlendirme listesi, kararı somut hale getirmeye yardımcı olur:

Platformu güvenilir biçimde işletecek altyapı ve PostgreSQL uzmanlığımız var mı?
Hangi sorumluluklar doğrudan kurum kontrolünde kalmalı?
Hangi erişilebilirlik, kurtarma, güvenlik ve uyumluluk hedeflerini karşılamalıyız?
Kurumun kaldırabileceği operasyonel değişkenlik ve olay riski ne kadar?
Platform yeni iş yüklerini destekleyecek şekilde ölçeklenebilir mi?
Hangi işleri veritabanı uzmanları üstlenmeli, hangileri yönetilen hizmete devredilebilir?
Öngörülebilir işletim maliyetleri, standartlaştırılmış kontroller ve hızlı dağıtım ne kadar öncelikli?

Stratejik bir kaynak tahsisi kararı

Kendi yönetimindeki PostgreSQL ile yönetilen hizmet arasındaki seçim, aslında kontrol, mühendislik kapasitesi ve operasyonel risk arasındaki bir tahsis kararıdır. Doğrudan altyapı erişimi, uzmanlaşmış yetenekler veya derin özelleştirme ihtiyacı; platformun tamamının sahipliğine değecek kadar önemliyse kendi yönetimindeki model uygun olabilir. Standartlaştırılmış operasyonlar, dayanıklılık, güvenlik entegrasyonu ve hızlı teslimat öncelikli olduğunda ise yönetilen hizmet öne çıkar.

Azure tarafında yönetilen bir modeli tercih eden ekipler için kaynak metin iki seçeneği öne çıkarıyor: Azure Database for PostgreSQL yapılandırılabilir yüksek erişilebilirlik, bakım, yedekleme, ölçekleme ve güvenlik yetenekleriyle tam yönetimli bir hizmet sunuyor. Azure HorizonDB ise bağımsız ölçeklenebilir işlem ve depolama, hızlı okuma ölçeklenmesi ve bölge dayanıklılığı isteyen kritik iş yükleri için bulut yerel bir PostgreSQL seçeneği olarak konumlandırılıyor.

Sonraki adımlar

Bir sonraki adımı değerlendirmeden önce gerekli uzantıları, işletim sistemi erişim ihtiyacını, erişilebilirlik ve kurtarma hedeflerini, güvenlik kontrollerini, bölgesel kullanılabilirliği, performans gereksinimlerini ve iç destek kapasitesini doğrulamak yerinde olur. Bu koşullar Azure üzerindeki yönetilen bir hizmete uygunsa geçiş sürecini planlamak için Microsoft’un sunduğu belgeler yol gösterici olabilir.

Kaynaklar ve İleri Okuma

Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102