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 run those reports as a single SQL query against your PostgreSQL data, 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.