Bu neden önemli?
Her yeni servis, ayrı bir fatura, ayrı bir bakım ve ayrı bir arıza noktası demek. Küçük ve orta projelerde zaten çalışan tek bir veritabanı, sandığından çok daha fazla işi üstlenebilir.
Yirmi servis yerine bir veritabanı
Modern bir web uygulaması kurarken liste hızla uzar: önbellek için Redis, arama için Elasticsearch, yapay zekâ araması için bir vektör veritabanı, arka plan işleri için bir kuyruk servisi, zamanlanmış görevler için bir cron sunucusu… Her biri ayrı kurulum, ayrı fatura, ayrı izleme demek.
Better Stack’in iki videosu tersini deniyor: Bunların hepsini PostgreSQL (kısaca Postgres) ile yapmak. Postgres, yıllardır kullanılan açık kaynak bir ilişkisel veritabanı. Asıl gücü, eklentilerle (extension) yeni yetenekler kazanabilmesi.
Hangi iş, hangi özellik?
- Önbellek:
UNLOGGEDtablolar. Postgres normalde her değişikliği önce bir güvenlik günlüğüne (WAL) yazar ki çökmede veri kaybolmasın. Unlogged tablolar bu adımı atlar. Daha hızlı yazılır ama çökme sonrası tablo boşalır. Önbellek için zaten sorun değil. - Tam metin arama:
tsvector. Metni kelime köklerine ayırıp dizine ekler. “koşuyor” diye arayınca “koşmak” geçen belgeyi de bulabilirsin. Basit bir site araması için Elasticsearch’e gerek kalmayabilir. - Vektör arama: pgvector. Yapay zekâ modellerinin ürettiği sayı dizilerini (embedding) saklar ve “anlamca en yakın” kayıtları bulur. RAG gibi yapay zekâ özelliklerinin temel taşı.
- Konum verisi: PostGIS. “Bana 2 km içindeki kafeleri göster” gibi coğrafi sorgular için yıllardır standart eklenti.
- Zamanlanmış görevler: pg_cron. Her gece eski kayıtları silmek gibi işleri veritabanının içinden, cron söz dizimiyle zamanlar.
- Belge saklama:
JSONB. Şeması belli olmayan veriyi JSON olarak saklayıp içinde sorgu yapabilirsin. MongoDB’ye gerek duymadan esnek veri.
Kuyruk da Postgres’te: pgmq
İkinci video tek bir işe odaklanıyor: mesaj kuyruğu. Kuyruk, “bu işi sonra yap” notlarını tutan bir sıra. Örneğin kullanıcı kayıt olunca hoş geldin e-postası kuyruğa atılır, arka plandaki bir işçi onu gönderir.
pgmq, Amazon SQS’e benzer bir kuyruğu tamamen Postgres içinde, düz SQL ile kuruyor:
- Kuyruk oluştur, içine JSON mesaj gönder.
- Bir işçi mesajı okuyunca mesaj belirli bir süre (visibility timeout) diğer işçilere görünmez olur. İşçi işi bitirip mesajı silmezse, süre dolunca mesaj başka bir işçiye tekrar gider. Böylece çöken bir işçi yüzünden iş kaybolmaz.
- Biten mesajlar silinebilir ya da sonradan incelemek için arşive taşınabilir.
Videoda 2 çekirdekli küçük bir konteynerde 100 bin mesaj ve 100 işçiyle bir yük testi yapılıyor. Sonuç, “Postgres ölçeklenmez” önyargısının bu boyutlarda pek geçerli olmadığı yönünde. Tabii bu tek bir deney, senin yükün farklı olabilir.
Peki her şeyi Postgres’e mi taşımalı?
Videonun kendi cevabı da temkinli: “Yapmalısın” değil, “yapabilirsin”. Birkaç şeyi akılda tut:
- Tek veritabanı, tek arıza noktası da demek. Aramadaki ağır bir sorgu, ödeme sorgularını yavaşlatabilir.
- Çok büyük ölçekte uzman araçlar (Kafka, Elasticsearch, Redis) hâlâ daha iyi sonuç verir.
- Ama çoğu proje o ölçeğe hiç ulaşmaz. Başlangıçta sade kalıp gerçekten ihtiyaç doğunca ayrı servise geçmek, baştan yirmi parça kurmaktan genelde daha akıllıca.
Düşün
- Çalıştığın ya da hayal ettiğin bir projede hangi servisler aslında tek bir veritabanıyla çözülebilirdi?
- “Basit başla, gerekince büyüt” ile “baştan doğru aracı seç” arasında sen nerede duruyorsun?
Bu yazıdaki araçlar Araç Kutusu'nda: pg_cron, pgmq, pgvector