Two families of databases. SQL stores neat, related tables; NoSQL stores more flexible, loosely-shaped data. Each fits different jobs.
Why it exists
Different data has different shapes: some is neat and relational like orders and customers, some is loose and varied like event logs or preferences. Forcing everything into one storage model makes some jobs slow and awkward. SQL and NoSQL exist as two families of database built around those different shapes, so teams can pick the one that matches how their data is actually queried.
How it actually works
SQL databases (Postgres, MySQL) use strict tables with defined columns and strong relationships. They are excellent when data is structured and consistency matters, like orders and payments.
NoSQL databases store data in more flexible shapes, documents or key-value pairs, and trade some strictness for speed and scale in certain patterns. Many products use both, each for what it is good at.
A senior PM walks you through it
A junior PM, stuck
The backend lead said orders stay in Postgres but the new activity feed goes to a NoSQL store, and I nodded like I understood. I do not. They are both just databases to me, so I cannot tell what actually changes about the data when it moves from one to the other, or why one order would be stored two completely different ways.
Nothing about the order changes; only its shape does. SQL spreads one order across several neat tables that you rejoin when you need it; NoSQL keeps that same order as one self-contained document. Below is order o_5512, the canonical Kacchi order, shown both ways: the SQL tables with the query that reassembles them, and the identical order as a single NoSQL document. Read them next to each other and the whole debate becomes concrete.
Treating SQL versus NoSQL as better versus worse. They are shapes for different questions; asking which one is good in the abstract wastes the discussion, while asking how the data gets read every time lands the real decision.
Underestimating a store move. Shifting data from tables to documents changes how every feature reads and writes it, so it is a real migration, not a config switch, even when the fields look identical.
Forgetting the duplication cost of documents. A customer's details copied into every one of their orders means one change has to be written to many documents; when someone says update is slow here, this is often why.
Assuming a JOIN is free. Reassembling an order across three tables is cheap for one order and expensive for a million; a report that joins big tables is where the SQL side slows down.
Next time it comes up, say: "Got it, orders are related and must reconcile, so they stay in SQL tables you JOIN; the activity feed is loose self-contained events read whole, so it fits a document store." You read one order in both shapes and matched the store to how the data is queried, which is the entire choice.
Where a PM meets this
You rarely choose this, but you will hear the debate. The short version: SQL for structured, related, must-be-correct data; NoSQL for huge scale or flexible shapes.
"Why is this hard to query?" is sometimes because data landed in a store that wasn't built for that kind of question.
Hear it in a meeting
"Orders live in Postgres; the activity feed is in a NoSQL store for volume."