---
title: "PostgreSQL Her Şeye Yeter mi?"
description: "Ayrı arama motoru, kuyruk veya doküman DB'si eklemeden önce: PostgreSQL'in tek başına nereye kadar yettiği ve sınırının nerede başladığı."
url: https://sade.dev/tr/journal/postgresql-her-seye-yeter-mi/
lang: tr
author: "Muhammet Şafak"
published: 2026-08-01
updated: 2026-08-30
section: Journal
tags: ["postgresql","database","architecture","opinion"]
---

# PostgreSQL Her Şeye Yeter mi?

> Ayrı arama motoru, kuyruk veya doküman DB'si eklemeden önce: PostgreSQL'in tek başına nereye kadar yettiği ve sınırının nerede başladığı.

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](/tr/journal/neden-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](/tr/systems/veri-yogunluklu-sistemler-kirilma-noktalari) 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.