In this chapter
We'll see why moving everything to NoSQL would be a mistake — and meet polyglot persistence, the idea of using the right database for each specific job, not one database for all of them.
The Problem in Real Life
Sarah is a little too excited now. Flexible shape, no rigid columns, copies that survive a machine failing — after five chapters of NoSQL's upsides, she opens a new design doc titled "Move Everything." Orders. Customers. Payments. All of it, into the same flexible document model the seller listings are about to use.
She gets two tables in before she stops. Orders isn't like the seller listings. Its shape hasn't changed in over a year. And GreenMart's relational database has spent years guaranteeing a payment can never be double-charged, never silently lost, never left half-written if something fails mid-way — real guarantees Sarah fought hard to build in. Sarah looks at what she'd be trading that away for, and can't find an upside.
I don't actually need Orders to be flexible. I need it to never be wrong.
Sarah
One Database for Everything vs. The Right Tool for Each Job
Orders still needs strict correctness
A payment can never be double-charged or silently lost — exactly what a relational database's transactions are built to guarantee.
Not every dataset needs to change shape
Orders' shape has been stable for over a year — flexibility GreenMart doesn't need isn't worth the trade-offs that come with it.
Different data, different right tool
Seller listings, sessions, sensor data, and relationships are all shaped differently — no single database fits all of them equally well.
Polyglot persistence
Using multiple databases within one system, each chosen for what it's actually best at — not one database doing everything.
Polyglot Persistence
This near-miss is worth sitting with, because it's the mistake this whole Act has been quietly building toward avoiding. NoSQL fixed a real problem — the seller listings genuinely didn't fit one rigid table. That doesn't mean every problem is that problem.
- Data with a well-understood, stable shape that rarely changes — Orders hasn't needed a new column in over a year
- Data where guaranteed correctness matters more than flexibility or scale — a payment can't be double-charged, ever, no matter what
- Complex questions that join many related pieces of data together cheaply — exactly what GreenMart's relational database was built for
For all three of those, a relational database isn't the old tool GreenMart is outgrowing. It's still the right one. NoSQL's flexibility, its horizontal scale, its willingness to trade strict consistency for availability — none of that is a pure upgrade. Every chapter in this Act showed a real cost sitting right next to a real benefit. Applying that cost somewhere that never needed the benefit in the first place is just a loss, with nothing on the other side of the trade.
The real shift isn't "move everything to NoSQL." It's realizing GreenMart doesn't need one database anymore — it needs the right database for each specific job. This is called polyglot persistence: using multiple different databases within one system, each chosen for what it's actually best suited to, instead of forcing a single database — relational or NoSQL — to handle every kind of data equally well. Orders and payments stay exactly where they've always been. Seller listings move to a document-shaped store, because that's the problem this Act actually started with. And as GreenMart keeps growing, more problems are coming — each one gets its own Act in this course, and each one gets exactly the database built for it.
That's the real answer to the question this whole Act opened on. NoSQL was never trying to replace SQL. It's not a better version of the same idea — it's a different way of designing a data system, built for problems the relational model was never meant to solve well. The strongest real systems don't pick one and abandon the other. They use several, side by side, on purpose.
Key Takeaway
NoSQL isn't a better version of SQL. It's a different way of designing a data system — and the strongest real systems use several different ways, side by side, not just one.
Why This Matters
This is the lens the rest of the course runs on. Every Act ahead introduces one more purpose-built database for one more specific problem GreenMart actually runs into — never "here's another database that could replace what you already have," always "here's the right tool for this particular job." Losing sight of that turns this course into a list of trendy names to memorize instead of a real architecture that actually works.
Six chapters in, Sarah finally has everything she needs to make a real call on the seller-listing problem — not just "NoSQL sounds right," but the specific reasoning for why, and what it would cost. That's exactly the decision the checkpoint ahead asks Sarah — or you — to make.