The app saves the order as one document: customer, address and items together.
One read brings back the whole order. Fast and flexible.
The customer moves. Their address is copied inside every old order.
The app must fix each copy. Miss one and the data disagrees.
Questions across many orders, like sales per item, are awkward to answer.
SQL gives strict tables, joins and transactions.
NoSQL trades some of that for flexible shapes and easy spreading.
Start with SQL unless you have a reason not to.
Reach for it when
Start with SQL for orders and money. Use NoSQL for key lookups at huge scale or data whose shape keeps changing.
The catch
A single SQL machine takes all writes; NoSQL spreads easily, but a changed address must be fixed in every copied order.
Say it in an interview“I would start with a SQL database for correctness and flexibility of queries, and move a workload to NoSQL only when scale or data shape clearly needs it.”