# Esnek ürün nitelikleri için NoSQL mu, PostgreSQL mi seçmeliyim?

> İlişkisel çekirdeği (ürün, fiyat, sipariş) PostgreSQL'de tutup değişken nitelikleri GIN index'li tek bir `JSONB` kolonuna koyun; raporlama bölmeye karşı.

- Soruldu: 2026-06-05
- Yanıtlandı: 2026-06-08
- Soran: Halil
- Etiketler: veritabani, mimari, postgresql
- Kaynak: https://muhammetsafak.com/tr/sor-bakalim/esnek-urun-nitelikleri-icin-nosql-mu-postgresql-mi/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** Yeni projede esnek bir ürün nitelik sistemi (renk, beden, garanti süresi vb. her üründe farklı) tasarlayacağız. İlişkisel DB'de EAV modeli karmaşık SQL ve performans kaybı getiriyor; NoSQL (MongoDB) şemasız yapısıyla cazip duruyor.

ACID gereksinimi, veri tutarlılığı ve raporlama ihtiyacını düşünerek bu iki dünya arasındaki seçimi hangi parametrelere göre yaparım?


Kısa cevap: Sırf nitelikler üründen ürüne değişiyor diye MongoDB'ye koşmayın — bu tam olarak **NoSQL tuzağı**. PostgreSQL'in `JSONB`'si üçüncü ve en isabetli yolu sunuyor.

## Kısa cevap

Sorunun kökü gerçek: ilişkisel DB'de EAV modeli (entity-attribute-value) cidden acı verir — devasa join'ler, okunamayan SQL, performans kaybı. Ama bu acı sizi doğrudan şemasızlığa itmemeli. Bu refleksin mimarideki kardeşini — yeni bir projeye doğrudan mikroservisle başlama isteğini — [ayrı bir kayıtta](/tr/sor-bakalim/yeni-projeye-mikroservisle-mi-baslamali/) tartışmıştım; karar mekanizması burada da aynı.

## Neden

1. **Raporlama ihtiyacınız tek başına kararı veriyor.** Yoğun raporlama gerektiğini söylüyorsunuz. Veriyi Mongo'ya bölerseniz bu raporları PostgreSQL'deki veriyle birlikte tek bir SQL sorgusunda yapamaz, iki ayrı sistemden veri birleştirme derdine düşersiniz. Bu tek gereksinim bile bölmeye karşı yeterli argüman.
2. **Ürün, fiyat, sipariş işinizin omurgası.** ACID, join ve raporlama istediğiniz her şey burada; transaction garantisini, foreign key'leri ve `JOIN`'lı raporları kaybetmek istemezsiniz.
3. **Document NoSQL'in doğru olduğu senaryo sizinki değil.** MongoDB'ye geçmeniz, ancak tüm erişiminiz anahtara göre (key-based) olduğu, varlıklar arası transaction/raporlama gerektirmediğiniz ve bütün domain'in doğası gereği belge şeklinde olduğu durumda mantıklı.

## Ne yapmalı

1. **İlişkisel çekirdeği PostgreSQL'de tutun.** Ürün, fiyat, sipariş, stok — ACID, join ve raporlama istediğiniz her şey ilişkisel kalsın.
2. **Değişken nitelikleri tek bir `JSONB` kolonuna koyun.** Üründen ürüne değişen renk/beden/garanti gibi alanları tek bir `JSONB` kolonunda tutun.
3. **`JSONB` kolonuna GIN index kurun.** `attributes @> '{"renk":"kırmızı"}'` gibi sorgular böylece hızlı çalışır. İhtiyacınız olan yerde şema esnekliği, geri kalan her yerde transactional bütünlük elde edersiniz.

**Sonuç:** PostgreSQL + variant nitelikler için `JSONB` (GIN index'li). NoSQL'i yalnızca erişim deseni gerçekten onu zorunlu kılıyorsa düşünün. "Şeması yok, kolay olur" diye başlamak, ileride tutarlılık ve raporlama faturasını çok daha ağır ödetir; bu mimari tercihin neden tuzak olduğunu sade.dev'deki yazıda açtım.

## İlgili Yazılar

- [NoSQL Tuzağı: "Şeması Yok" Diye Başlamak](https://sade.dev/tr/journal/nosql-tuzagi) — sade.dev
- [Heap erişimini önlemek ve index-only scan almak için covering index'e (INCLUDE) ne zaman geçmeliyim?](https://muhammetsafak.com/tr/sor-bakalim/index-only-scan-covering-indexe-ne-zaman-gecmeliyim/) — Sor Bakalım
- [Sadece 'pending' satırları taranan bir kuyruk tablosunda partial index kullanmalı mıyım?](https://muhammetsafak.com/tr/sor-bakalim/sadece-pending-satirlari-taranan-bir-kuyruk-tablosunda-partial-index-kullanmali-miyim/) — Sor Bakalım
- [WAL arşivleme ve PITR ile felaketten saniyeler öncesine nasıl dönerim?](https://muhammetsafak.com/tr/sor-bakalim/veritabani-pitr-ve-wal-arsivleme-ile-felaket-oncesine-donmek/) — Sor Bakalım