PostgreSQL mü MongoDB mi? Karar Veriye Değil, Erişim Deseninize Bakar

Kısa cevap: Seçimi verinin şekli değil, ona nasıl eriştiğiniz belirler. 2025 Stack Overflow Geliştirici Araştırmasında PostgreSQL, geliştiricilerin %55,6'sı tarafından kullanılarak en yaygın veritabanı oldu; profesyonel geliştiricilerde oran %58,2. Bir yılda %48,7'den %55,6'ya çıkan bu artış, araştırmanın tarihindeki en büyük sıçrama ve ikinci sıradaki MySQL ile arayı 15 puana açıyor. Bu, "ilişkisel mi doküman mı" tartışmasının varsayılanını değiştirdi: artık PostgreSQL'den sapmak için bir gerekçe göstermek gerekiyor, tersi değil.

Bu yazı o gerekçenin ne zaman geçerli olduğunu ele alıyor.

PostgreSQL neden varsayılan hâline geldi?

Üç sebep birikti.

JSONB, tartışmanın yarısını ortadan kaldırdı. PostgreSQL şemasız doküman saklamayı ve o dokümanlar üzerinde indeksli sorgu çalıştırmayı destekliyor. Yani "esnek şema" ihtiyacı tek başına artık ayrı bir veritabanı gerekçesi değil; aynı ACID motorunun içinde ilişkisel ve doküman veriyi bir arada tutabiliyorsunuz.

Eklenti ekosistemi bir ürün yelpazesine dönüştü. Coğrafi veri için PostGIS, zaman serisi için TimescaleDB, vektör arama için pgvector. Bunların her biri bir zamanlar ayrı bir sistem satın alma sebebiydi.

Lisans belirsizliği yok. PostgreSQL'in izin verici lisansı, son yıllarda birçok açık kaynak veritabanında yaşanan lisans değişikliği tartışmalarının dışında kaldı.

Peki MongoDB ne zaman doğru cevap?

Doküman veritabanını haklı çıkaran şey verinin "yapılandırılmamış" olması değil. Aşağıdaki üç durumdan en az ikisi birden geçerliyse gerekçe gerçektir:

Okuma deseni tek bir belge etrafında toplanıyor. Uygulama her istekte tek bir kimliğe bağlı bütün bir nesneyi okuyor ve yazıyorsa, o nesneyi on beş tabloya bölüp her okumada tekrar birleştirmek gereksiz bir maliyettir.

Şema gerçekten ve sık değişiyor. Ürün kataloğu gibi her kaydın farklı alanlar taşıdığı, alan setinin de aylık değiştiği yapılar buna örnektir. Burada kritik ayrım şu: şemanın veritabanında olmaması, şemanın olmadığı anlamına gelmez. Şema uygulamaya taşınmıştır ve orada yazılı olmak zorundadır.

Yatay ölçekleme bir gereklilik, bir tercih değil. Tek node'un dikey sınırına gerçekten dayandıysanız parçalama (sharding) anlamlıdır. Dayanmadıysanız, dağıtık bir sistemin işletme maliyetini erken ödemiş olursunuz.

Kararı veren altı soru

Tek istekte kaç varlığa dokunuyorsunuz? Bir taneyse doküman, çoksa ilişkisel.İşlem sınırı nerede? Birden fazla varlığın aynı anda tutarlı kalması gerekiyorsa ilişkisel motor bunu ücretsiz verir.Sorgular önceden biliniyor mu? Bilinmeyen ve değişken sorgular ilişkisel modelin ve SQL'in güçlü olduğu yerdir.Veri ne kadar büyüyecek ve nasıl bölünecek? Doğal bir bölümleme anahtarı yoksa parçalama zorlaşır.Ekip hangisini işletebiliyor? İşletilemeyen doğru seçim, işletilebilen ikinci seçimden kötüdür.Rapor ve analitik nereden okuyacak? İki motor kullanacaksanız, raporlamanın hangisinden besleneceği baştan belli olmalı.

Geçişte asıl risk taşımada değil, kesme anında

Modernizasyon projelerinde veri taşıma genellikle çözülmüş bir problemdir; plan asıl olarak şu noktada kırılır: eski sistemi ne zaman ve nasıl kapatacaksınız.

İşe yarayan yaklaşım kademeli: önce çift yazma, sonra okumaların kademeli devri, sonra eski sistemin salt okunur hâle gelmesi, en sonda kapatma. Her adımda geri dönüş yolu açık kalır. Bu, şema değişikliklerinin güvenli uygulanması ile aynı disiplini gerektirir: sürümlenmiş migration'lar, önce test ortamı, üretimde geri alma yolu.

Kesme anında en çok gözden kaçan iki şey: karakter kümesi ve saat dilimi farkları ile eski sistemde yıllar içinde birikmiş "veri borcu": boş bırakılmış zorunlu alanlar, tutarsız tarih biçimleri, kopya kayıtlar. Bunlar taşımada değil, yeni sistemin kısıtları devreye girdiğinde ortaya çıkar.

Nereden başlanmalı

Veritabanı seçimi bir teknoloji tercihinden çok bir işletme taahhüdüdür: yedekleme, replikasyon, sürüm yükseltme ve kapasite planlaması ondan sonraki beş yılı belirler. Kurtarma tarafında hedeflerin nasıl belirleneceğini RPO ve RTO hesaplama yazımızda ele almıştık; replikasyon sağlığının nasıl izleneceğini ise PostgreSQL replikasyon gecikmesi yazısında.

Eclit'in bu katmanı nasıl işlettiğini veritabanı platform mühendisliği sayfasında görebilirsiniz.