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

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.