Document store or relational database?

NoSQL and choosing a database Mid-level Python 3.13+ PostgreSQL 17+ Reviewed By Best Latest Apps

Pick the fix

An e-commerce app needs orders, customers and inventory with stock that must never go negative across concurrent orders. Primary store?

Options
Hint 1 of 1

Where are the cross-row rules?

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A PostgreSQL with constraints and transactions (JSONB for product attributes)

Correct. Shared, related data with invariants across rows.

Stock that must never go negative across orders is a rule across many rows. Relational constraints and transactions enforce that in one place; JSONB still covers flexible product attributes.

Why not the others?
  • B MongoDB with orders embedding customer and stock copies. Copies drift and stock checks across documents get hard.
  • C Redis as the only store. Durability and constraints don't fit.
  • D Elasticsearch. A search index, not a source of truth.

30-second answer

A document store fits when data is naturally a self-contained tree read and written as a whole (a product with its variants, a CMS page), the shape varies a lot between records, and you rarely join across documents. A relational database fits when data is shared and referenced from many places, you need joins, constraints and multi-row transactions. PostgreSQL's JSONB covers many 'flexible fields' needs without a second database.

Practise saying it · 35 s. No recording, just a timer

Document or relational?

Say your answer out loud, then check which of these points you covered:

  • Self-contained trees vs shared data
  • Joins and constraints
  • Access patterns decide
  • JSONB middle ground

Deep dive

Document stores push joins into the application or into denormalized copies you must keep in sync.

MongoDB has had multi-document transactions since 4.0, but its data model still favours single-document writes.

Schema flexibility moves validation into code; use JSON Schema validation where available.

Choose for access patterns, not for 'schemaless'.

Common mistakes

  • Picking a document store to avoid designing a schema.
  • Modelling many-to-many relationships as nested arrays.
  • Running two databases when JSONB columns would do.

Senior take & follow-ups

Decide by access pattern and relationships, and mention JSONB as the middle ground.

Follow-up questions

Think of your answer first, then open the hint.

  1. When is JSONB in PostgreSQL enough?

    Show hint

    Flexible attributes on otherwise relational rows.

  2. Embed or reference?

    Show hint

    Embed what's read together and owned by the parent; reference what's shared or unbounded.

Related questions

Suggest a fix if something here is wrong or out of date.