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.

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 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.