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.

Short answer

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. I’ve discussed the architectural sibling of this reflex — the urge to start a new project directly on microservices — in a separate answer; the decision procedure is the same here.

Why

1. 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.
2. Products, prices and orders are the spine of your business. Everything where you want ACID, joins and reporting lives here; you don’t want to give up transactional guarantees, foreign keys and JOIN-based reports.
3. The scenario where document NoSQL is right isn’t yours. 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.

What to do

1. Keep the relational core in PostgreSQL. Products, prices, orders, stock — everything where you want ACID, joins, and reporting stays relational.
2. Put the variable attributes in a single JSONB column. Hold the fields that vary per product — color/size/warranty — in one JSONB column.
3. Add a GIN index on that JSONB column. Queries like attributes @> '{"color":"red"}' then run fast. You get schema flexibility where you need it and transactional integrity everywhere else.

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.