Should I choose NoSQL or PostgreSQL for flexible product attributes?

Short answer: don’t reach for MongoDB just because attributes vary from product to product — that’s exactly the NoSQL trap. PostgreSQL’s JSONB gives you a third, more accurate option.

The pain is real: EAV (entity-attribute-value) in a relational DB genuinely hurts — huge joins, unreadable SQL, performance loss. But that pain shouldn’t push you straight into schemalessness.

1. Keep the relational core. Products, prices, orders, stock — everything where you want ACID, joins, and reporting stays relational. This is the spine of your business; you don’t want to give up transactional guarantees, foreign keys, and JOIN-based reports here.
2. Put the variable attributes in JSONB. Hold the fields that vary per product — color/size/warranty — in a single JSONB column. Add a GIN index on it; queries like attributes @> '{"color":"red"}' run fast. You get schema flexibility where you need it and transactional integrity everywhere else.
3. Pick document NoSQL only if the whole domain is document-shaped. Moving to MongoDB makes sense only when all access is key-based, you don’t need cross-entity transactions/reporting, and the entire domain is genuinely document-shaped. Your scenario isn’t that.
4. Your reporting need alone decides it. You say you need heavy reporting. If you split data into Mongo you can’t do those reports in SQL and you’re stuck stitching data from two systems. That single requirement is enough to argue against splitting.

Bottom line: PostgreSQL + JSONB (GIN-indexed) for the variant attributes. Consider NoSQL only if the access pattern truly demands it. Starting with “it has no schema, this’ll be easy” makes you pay a much heavier consistency-and-reporting bill later — I unpack why this architectural choice is a trap in the sade.dev piece.