# Should I choose NoSQL or PostgreSQL for flexible product attributes?

> Keep products, prices and orders in PostgreSQL and put the variable attributes in one GIN-indexed `JSONB` column; reporting alone rules out splitting.

- Asked: 2026-06-05
- Answered: 2026-06-08
- Asked by: Halil
- Tags: veritabani, mimari, postgresql
- Source: https://muhammetsafak.com/just-ask/nosql-vs-relational-for-flexible-product-attributes/
- Language: en-US
- Author: Muhammet Şafak

---
**Question:** On a new project we'll design a flexible product attribute system (color, size, warranty period, etc. — different for every product). In a relational DB the EAV model brings complex SQL and performance loss; NoSQL (MongoDB) looks attractive with its schemaless structure.

Given the ACID requirement, data consistency, and reporting needs, by what parameters should I choose between these two worlds?


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](/just-ask/should-i-start-a-new-project-with-microservices/); 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.

## Related Reading

- [The NoSQL Trap: Starting Because "It Has No Schema"](https://sade.dev/en/journal/the-nosql-trap) — sade.dev
- [When should I switch to a covering index with INCLUDE to get an index-only scan?](https://muhammetsafak.com/just-ask/switch-covering-index-include-get-index-only-scan/) — Just Ask
- [Should I use a partial index on a queue table where I only ever scan 'pending' rows?](https://muhammetsafak.com/just-ask/should-i-use-a-partial-index-on-a-queue-table-where/) — Just Ask
- [How do I rewind to seconds before a disaster with WAL archiving and PITR?](https://muhammetsafak.com/just-ask/point-in-time-recovery-with-wal-archiving/) — Just Ask