# 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://www.muhammetsafak.com.tr/en/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.

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.

## Related Reading

- [The NoSQL Trap: Starting Because "It Has No Schema"](https://sade.dev/en/journal/the-nosql-trap) — sade.dev
- [Should I use a partial index on a queue table where I only ever scan 'pending' rows?](https://www.muhammetsafak.com.tr/en/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://www.muhammetsafak.com.tr/en/just-ask/point-in-time-recovery-with-wal-archiving/) — Just Ask
- [Time-series data: TimescaleDB or InfluxDB?](https://www.muhammetsafak.com.tr/en/just-ask/time-series-data-timescaledb-vs-naive-solutions/) — Just Ask