# 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://www.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.

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.

1. **İlişkisel çekirdeği koruyun.** Ürün, fiyat, sipariş, stok — ACID, join ve raporlama istediğiniz her şey ilişkisel kalsın. Bunlar işinizin omurgası; transaction garantisini, foreign key'leri ve `JOIN`'lı raporları burada kaybetmek istemezsiniz.
2. **Değişken nitelikleri `JSONB`'ye koyun.** Üründen ürüne değişen renk/beden/garanti gibi alanları tek bir `JSONB` kolonunda tutun. Üstüne bir **GIN index** kurun; `attributes @> '{"renk":"kırmızı"}'` gibi sorgular hızlı çalışır. İhtiyacınız olan yerde şema esnekliği, geri kalan her yerde transactional bütünlük elde edersiniz.
3. **Document NoSQL'i yalnızca tüm domain document ise seçin.** 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ı. Sizin senaryonuzda öyle değil.
4. **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.

**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
- [Sadece 'pending' satırları taranan bir kuyruk tablosunda partial index kullanmalı mıyım?](https://www.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://www.muhammetsafak.com.tr/sor-bakalim/veritabani-pitr-ve-wal-arsivleme-ile-felaket-oncesine-donmek/) — Sor Bakalım
- [Canlı tabloda dual-write ile sıfır kayıplı şema geçişini nasıl koordine ederim?](https://www.muhammetsafak.com.tr/sor-bakalim/canli-tabloda-dual-write-ile-sifir-kayipli-sema-gecisi/) — Sor Bakalım