--- 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-09-06 section: Journal tags: ["postgresql","database","architecture","opinion"] summary: "PostgreSQL'in yanına Elasticsearch, MongoDB ve RabbitMQ dizen listenin büyük kısmını uzun süre tek bir PostgreSQL taşır: arama için GIN index'li tsvector, doküman için jsonb, orta hacimli kuyruk için SELECT FOR UPDATE SKIP LOCKED. Sınırlar dürüst ve gerçek, ama ikinci veri sistemi bir histen ya da bir blog yazısından değil, ölçülmüş bir sınırdan gelmeli." --- # PostgreSQL Her Şeye Yeter mi? > PostgreSQL'in yanına Elasticsearch, MongoDB ve RabbitMQ dizen listenin büyük kısmını uzun süre tek bir PostgreSQL taşır: arama için GIN index'li tsvector, doküman için jsonb, orta hacimli kuyruk için SELECT FOR UPDATE SKIP LOCKED. Sınırlar dürüst ve gerçek, ama ikinci veri sistemi bir histen ya da bir blog yazısından değil, ölçülmüş bir sınırdan gelmeli. 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. ## Sık sorulanlar **PostgreSQL ayrı bir arama motorunun yerini tutar mı?** Çoğu uygulama için evet. tsvector, tsquery ve GIN index; dilsel sapma, ağırlıklandırma ve sıralama dahil gövdeli bir tam metin araması verir. Adanmış bir motor; yazım hatası toleransı, gelişmiş alaka düzeyi ayarı, faceted search ve çok dilli analiz ciddi ölçekte gerektiğinde kazandırmaya başlar. **PostgreSQL iş kuyruğu olarak kullanılabilir mi?** Orta hacimde evet. SELECT ... FOR UPDATE SKIP LOCKED, birden çok tüketicinin kuyruk benzeri bir tablodan lock çakışması olmadan iş çekmesini sağlar; LISTEN/NOTIFY ise tablonun değiştiğini haber verir. Çok yüksek throughput, karmaşık yönlendirme ya da çok tüketicili fan-out gerektiğinde doğru araç gerçek bir message broker olur. ## Kaynaklar - [Full Text Search: tsvector, tsquery, stemming and ranking](https://www.postgresql.org/docs/current/textsearch-intro.html) — PostgreSQL - [JSON Types: jsonb and GIN indexing](https://www.postgresql.org/docs/current/datatype-json.html) — PostgreSQL - [SELECT: the locking clause and SKIP LOCKED](https://www.postgresql.org/docs/current/sql-select.html) — PostgreSQL - [NOTIFY](https://www.postgresql.org/docs/current/sql-notify.html) — PostgreSQL