Bir mimari planında, daha tek kullanıcı yokken şu liste vardı: kalıcı veri için PostgreSQL, arama için Elasticsearch, cache için Redis, esnek belgeler için MongoDB, kuyruk için RabbitMQ. Beş ayrı veri sistemi — beşinin de yedeği, monitoring’i, sürüm yükseltmesi ve kendine özgü hata modu.

O listenin büyük kısmını, uzun bir süre boyunca, tek başına PostgreSQL taşır. Soru “PostgreSQL bunu yapabilir mi” değil; “bu beş sistemin operasyon yükünü gerçekten satın aldınız mı”.

PostgreSQL’in az bilinen genişliği

PostgreSQL’i sadece bir tablo-satır deposu sanmak, yeteneklerinin küçük bir kısmını kullanmaktır. Sık sık ayrı bir sistem getirten ihtiyaçların çoğu zaten içinde:

  • Tam metin arama. tsvector, tsquery ve GIN index ile gövdeli bir arama. Çoğu uygulamanın “ürün ara”, “yazı ara” ihtiyacını dilsel sapma, ağırlıklandırma ve sıralama dahil karşılar.
  • Doküman saklama. jsonb sütunu, GIN index’iyle birlikte sorgulanabilir bir belge deposudur. Şema esnekliği isteyen alanları, ilişkisel tablonun içinde tutabilirsiniz.
  • Kuyruk. SELECT ... FOR UPDATE SKIP LOCKED ve LISTEN/NOTIFY, orta hacimli bir iş kuyruğunu ayrı bir broker olmadan çalıştırır. Laravel’in database queue driver’ı bunun SKIP LOCKED tarafını kullanır — worker’ları LISTEN/NOTIFY sinyali beklemek yerine kuyruk tablosunu belirli aralıklarla yoklar.
  • Analitik sorgular. Window function’lar, CTE’ler, materialized view’lar — ayrı bir analitik veritabanına gitmeden ciddi raporlama.
  • Coğrafi veri. PostGIS eklentisiyle konum sorguları.

Bu özellikler “var ama kullanılmıyor” değil; production’da güvenilir biçimde çalışan, olgun yeteneklerdir.

Tek sistemin sessiz getirisi

Her yeni veri sistemi yalnızca bir kutu değil; bir bakım yükümlülüğüdür. Tek sistemde kalmanın getirisi:

  • Tek yedek hattı. Bir tane backup/restore prosedürü, bir tane kurtarma tatbikatı.
  • Tek izleme hedefi. Öğrenilecek bir metrik seti, kurulacak bir alarm düzeni.
  • Çapraz tutarlılık. En önemlisi bu. Arama indeksiniz ile veriniz aynı veritabanındaysa aralarında drift olamaz — ikisi aynı transaction’da güncellenir. Ayrı bir Elasticsearch ise eninde sonunda veriyle senkronizasyonu bozulur ve onu düzeltmek ayrı bir iş kalemine dönüşür.
  • Tek zihinsel model. Ekip tek bir sistemin tuhaflıklarını öğrenir, beş sistemin değil.

Bu, boring architecture yazısındaki innovation token mantığının veri katmanındaki hâlidir: her yeni sistem bir token ve token sınırlı.

Sınır nerede başlar

PostgreSQL her şeye yetmez — dürüst sınırları var ve onları görmezden gelmek de bir hata olur:

  • Arama. Yazım hatası toleransı, gelişmiş alaka düzeyi ayarı, faceted search ve çok dilli analiz ciddi ölçekte gerektiğinde, adanmış bir arama motoru gerçekten kazandırır.
  • Kuyruk. Çok yüksek throughput, karmaşık yönlendirme ya da çok tüketicili fan-out gerektiğinde gerçek bir message broker doğru araçtır. PostgreSQL kuyruğu orta hacimde rahat, uç hacimde değil.
  • Yazma throughput’u. Tek primary’nin fsync kapasitesini aşan sürekli yazma — bu, veri yoğunluklu sistemlerdeki en zor kırılma noktası ve gerçek bir sınır.

Bu sınırlardan birine çarptığınızda ek sistem getirmek doğru karardır. Çarpmadan getirmek ise yalnızca bir tahmin.

Karar: önce PostgreSQL, sonra ölçüm

Kural sade: yeni bir projede, PostgreSQL’in yapabildiği her şeyi PostgreSQL’e yaptırın. Arama, kuyruk, cache benzeri ihtiyaçların ilk durağı o olsun. Ayrı bir sistem, ancak ölçülmüş bir sınır aşıldığında gelsin — bir histen, bir blog yazısından ya da CV kaygısından değil.

Çoğu ekip PostgreSQL’in belki %20’sini kullanır, sonra “yetmiyor” der. Yetmeyen çoğu zaman PostgreSQL değil, onu tanıma çabasıdır.

PostgreSQL her şeye yetmez — ama sandığınızdan çok daha fazlasına yeter. İkinci bir veri sistemi getirmeden önce, birincisinin gerçekten sonuna gelip gelmediğinizi sorun.

Önce PostgreSQL; gerisi ölçümle gelsin.