PostgreSQL; 1986’da Berkeley’de başlayan, 30+ yıllık olgunluğa sahip açık-kaynak ilişkisel veritabanı sistemidir. MVCC (Multi-Version Concurrency Control) mimarisi, zengin uzantı ekosistemi (PostGIS, pgvector, TimescaleDB) ve katı SQL standartlarına uyumu sayesinde yeni nesil uygulamalar için fiili ilk tercihtir.
PostgreSQL’in en güçlü tarafı uzantılabilirliğidir: yeni veri tipleri, indeks türleri ve sorgu fonksiyonları çekirdeği değiştirmeden eklenebilir. Bu sayede AI embedding (pgvector), zaman serisi (TimescaleDB), coğrafi veri (PostGIS) gibi özel iş yükleri tek veritabanı motorunda çalıştırılabilir.
Mono’nun yaklaşımı
PostgreSQL kurulumu sadece “RPM yükle ve çalıştır” değil. Mono ekibinin standart kurulum kararları:
- Versiyon: Yeni projeler için n-1 (en güncelin bir altı) — olgunluk avantajı. Sürüm yükseltme
pg_upgradeile minimal kesintiyle planlanır. - HA: Patroni + etcd (3 node DCS) — automatic failover < 30 saniye, split-brain koruması.
- Yedekleme: pgBackRest ile incremental + WAL archival; off-site S3 kopyası; tatbikatlar çeyrekte bir.
- İzleme:
pg_stat_statements, PMM (Percona Monitoring) veya Grafana + postgres_exporter, query latency p99 alarmı. - Connection pooling: PgBouncer transaction-mode; uygulama-veritabanı arası 10:1 oranında bağlantı tasarrufu.
- Sıkılaştırma: SSL zorunlu, SCRAM-SHA-256 auth,
pg_hba.confminimum yetki, audit içinpgaudit.
Tipik üretim mimarisi
Mono müşterilerimizin tipik 3-katmanlı kurulumu:
- Uygulama → PgBouncer (transaction mode, ~25:1 oranı).
- PgBouncer → HAProxy/Patroni REST (primary keşfi).
- Patroni cluster (3 node: 1 primary + 2 sync replica), etcd üzerinde DCS.
- pgBackRest ile saatlik PITR + S3 (Mono Cloud Garage veya AWS).
- Read-only replica raporlama/analitik için (cascading replication ile primary yükünü kapatır).
Yaygın sorunlar ve çözümler
- Connection storm’lar: Uygulama her istekte yeni bağlantı açıyor. PgBouncer ile çözülür.
- Bloat: Yoğun UPDATE workload’larında dead tuple birikimi.
autovacuum_naptimeveautovacuum_vacuum_scale_factortablo bazlı ayarlanır; pg_repack ile online sıkıştırma. - Yavaş plan değişimleri: İstatistiklerin eskimesi.
ANALYZEcron’u,default_statistics_target‘ı kritik tablolarda 1000+‘a çıkarın. - Replication lag: Long-running query primary’de WAL replay’i yavaşlatır.
hot_standby_feedbackveya replica’damax_standby_streaming_delayayarı. - Out of disk: WAL archive cron’u veya retention politikası eksik.
archive_cleanup_commandve pgBackRest retention.
İlgili hizmetlerimiz
Sıkça sorulan sorular
PostgreSQL mi MySQL/MariaDB mi?
Yeni projeler için PostgreSQL öneriyoruz: ACID garantilerinde daha katı, JSONB/CTE/window function/partial index gibi gelişmiş özelliklerde MySQL’in önünde. MySQL ekosistemine derin yatırım yapmış kurumlarda MariaDB Galera Cluster bir seçenek olarak değerlendirilebilir.
HA için Patroni mi yoksa Crunchy/CloudNativePG mi?
Patroni geleneksel VM/sunucu kurulumlarında olgunluğu kanıtlanmış çözümdür. Kubernetes üzerinde çalışıyorsanız CloudNativePG veya Crunchy operator’ları daha iyi entegre olur. Mono varsayılanı: VM’de Patroni + etcd; K8s’de CloudNativePG.
Yedekleme stratejisi ne olmalı?
3-2-1 kuralı: 3 kopya, 2 farklı medya, 1 off-site. Pratikte: pgBackRest ile günlük tam + saatlik diferansiyel + PITR; off-site için S3 uyumlu (AWS S3 / Mono Cloud Garage). Restore tatbikatı kesinlikle çeyrekte bir yapılmalıdır.
Replication lag'i ne zaman önemsenmeli?
Read-replica’dan okumayan uygulamalar için kritik değildir. Read-replica okuyorsanız synchronous_standby_names + application_name ile read-after-write garantisi sağlayın veya kritik okumaları primary’e yönlendirin.
Hangi extension'ları kuralım?
Sık kullandıklarımız:
pg_stat_statements (sorgu profili), pg_partman (partition yönetimi), pgvector (AI embedding), postgis (coğrafi veri), pg_repack (online vacuum). Üçüncü parti uzantılarda shared_preload_libraries etkisini test edin.