1. Neden PostgreSQL?

PostgreSQL, açık kaynaklı ve kurumsal düzeyde bir ilişkisel veritabanıdır.

Örneğin bir Strapi projesinde şu tablolar olabilir:

●​ users
●​ articles
●​ categories
●​ comments

media

Strapi bunları otomatik oluşturur.

JSON desteği
PostgreSQL'in en büyük avantajlarından biri JSONB tipidir.

Örneğin ürün özelliklerini her zaman aynı kolonlarda tutmak istemeyebilirsin.

Normal tablo:

n c s we
i
g
h
t

Ama her ürünün farklı özellikleri varsa:

●​ {
●​ "screen": "15 inch",
●​ "cpu": "M4",
●​ "ram": "32 GB"

PostgreSQL bunu doğrudan saklayabilir.

●​ CREATE TABLE products (

●​ id SERIAL,
 ●​ name TEXT,
●​ attributes JSONB

);

Sonra sorgulayabilirsin.

●​ SELECT *
●​ FROM products

WHERE attributes->>'cpu' = 'M4';

Bu yüzden Strapi gibi dinamik içerik sistemlerinde PostgreSQL çok avantajlıdır.

2. Docker Volume nedir?

Docker Container silinirse içindeki veriler de silinir.

Bu yüzden disk üzerinde bir klasör bağlanır.

Örneğin:

●​ services:
●​ db:
●​ volumes:

- postgres:/var/lib/postgresql

Burada:

●​ Docker Volume
●​
●​ ↓
●​

/var/lib/postgresql

bağlanır.

Veriler artık container dışında saklanır.

Eski kullanım
Yıllardır çoğu örnekte şöyle yazılırdı:

●​ volumes:

- postgres:/var/lib/postgresql/data

Çünkü eski PostgreSQL Docker imajlarında veritabanı burada tutuluyordu.

/var/lib/postgresql/data

PostgreSQL 18'de ne değişti?

PostgreSQL 18 Docker imajlarında veri dizini yönetimi değiştirildi.

Artık giriş (entrypoint) script'leri ve varsayılan veri yolu farklı şekilde ele alınıyor.

Bu nedenle eski örnekleri kopyalarsan:

●​ volumes:

- postgres:/var/lib/postgresql/data

başlatma sırasında beklenmeyen izin veya dizin başlatma problemleri yaşayabilirsin.

Sonuç:

●​ Container
●​
●​ ↓
●​
●​ Başlıyor
●​
●​ ↓
●​
●​ Postgres açılamıyor
●​
●​ ↓
●​
●​ Container kapanıyor
●​
●​ ↓
●​
●​ Docker tekrar başlatıyor
●​
●​ ↓
●​
 ●​ Tekrar çöküyor
●​
●​ ↓
●​

Crash Loop

Crash Loop nedir?

Docker'ın politikası şöyledir:

●​ Container başladı
●​
●​ ↓
●​
●​ Hata oluştu
●​
●​ ↓
●​
●​ Container kapandı
●​
●​ ↓
●​
●​ restart: always
●​
●​ ↓
●​
●​ Tekrar başlat
●​
●​ ↓
●​
●​ Yine hata
●​
●​ ↓
●​
●​ Tekrar başlat
●​
●​ ↓
●​

...

Sürekli yeniden başlar.

Loglarda şöyle görünür:

 ●​ Starting PostgreSQL...
●​
●​ database directory is invalid
●​
●​ Stopping...
●​

Restarting...

veya

initdb: directory exists but is not empty

Neden /var/lib/postgresql?
Yeni PostgreSQL imajları bu dizin yapısını daha doğru yönetebiliyor.

Compose dosyasında:

●​ services:
●​ db:
●​ image: postgres:18-alpine
●​
●​ volumes:

- postgres:/var/lib/postgresql

olduğunda container kendi alt dizinlerini oluşturabiliyor.

Yani:

●​ /var/lib/postgresql
●​
●​ data
●​
●​ pg_wal
●​

...

gibi yapıyı kendisi yönetiyor.

 Alpine neden seçilmiş?
image: postgres:18-alpine

Alpine Linux tabanlıdır.

Avantajları:

●​ Daha küçük imaj (~100–150 MB civarı)

●​ Daha hızlı indirme
●​ Daha düşük RAM kullanımı
●​ Daha az saldırı yüzeyi

Senior'ın dikkat ettiği nokta

Buradaki "Senior her zaman güncel imajların spesifik gereksinimlerini takip etmelidir."
cümlesinin vermek istediği mesaj şudur:

Bir senior geliştirici:

●​ Eski blog yazılarındaki örnekleri doğrudan kopyalamaz.

●​ Kullandığı Docker imajının sürüm notlarını ve resmi dokümantasyonunu kontrol eder.
●​ Büyük sürüm geçişlerinde (örneğin PostgreSQL 17 → 18) davranış değişikliklerini
araştırır.
●​ Veri dizini, izinler ve volume yapısındaki değişiklikleri doğrular.

Ancak burada önemli bir teknik not var: "/var/lib/postgresql/data kullanmak

PostgreSQL 18'de her durumda crash loop'a neden olur" şeklinde genel bir kural
doğru değildir. Resmî postgres:18 Docker imajı hâlâ PGDATA varsayılanını
/var/lib/postgresql/data olarak kullanır ve bu yol doğru yapılandırıldığında normal
şekilde çalışır. Crash loop'lar çoğunlukla şu nedenlerden kaynaklanır:

●​ Yanlış PGDATA ayarı,

●​ Eski bir volume'un yeni sürümle uyumsuz kullanılması,
●​ Dosya izinleri (permission) sorunları,
●​ Volume'un yanlış dizine bağlanması veya içinde beklenmeyen dosyalar bulunması,
●​ Yanlış Compose yapılandırması.

Dolayısıyla bu açıklamadaki asıl çıkarım, "Sürüm yükseltmelerinde veri dizini ve Docker

yapılandırmasını dikkatle doğrulamak gerekir" olmalıdır; yoksa
/var/lib/postgresql/data yolunun PostgreSQL 18'de genel olarak hatalı olduğu
sonucu çıkarılmamalıdır.

●​