Why NoSQL Exists

For nine chapters the relational model has absorbed everything the Marquee threw at it — films, screenings, bookings, seat clashes, growth, a website. It handled all of it, and it handled it well. So a fair question hangs over this chapter: if relational databases are this capable, why does anything else exist at all?

The answer is not that relational databases are old or flawed. It's that their bargain — a declared schema, joins that reassemble split data, strict all-or-nothing guarantees — is worth paying for most of the time, and for a few specific jobs it costs more than it returns. NoSQL is the name for the tools that strike a different bargain on purpose. This page names the three pressures that make a different bargain worth it, before the next four pages tour the families one by one.

Pressure One: the Shape of the Data

Some data refuses to sit still in fixed columns. Suppose the Marquee wants to store festival history for its films. Night Bus won three awards at two festivals; Paper Lanterns won none but screened at a retrospective; an older film has a director's commentary track and a restoration note. Every film's extra information is a different shape.

Force that into a relational table and you get a wall of columns that are empty for almost every row — an award_1, award_2, festival_note, restoration_year, most of them NULL most of the time. It works, but it fights you. Data that arrives as nested, varying records — where each item carries whatever it happens to have — is the first pressure that makes people look past the relational table.

Pressure Two: Scale by Spreading

A single database lives on a single machine, and a single machine has a ceiling — so much memory, so much disk, so many queries a second. For most businesses, including the Marquee, that ceiling is comfortably far away. But some systems outgrow any one machine and must spread their data across many.

Here's the honest catch: once the data lives on twenty machines instead of one, the relational conveniences get genuinely hard. A JOIN might need rows from five machines at once; an all-or-nothing transaction might need all twenty to agree in the same instant. Some databases are built from the ground up to spread easily — by giving up exactly those cross-machine features. That trade is the second pressure, and it's a real engineering choice, not a theory lesson.

Pressure Three: Raw Speed on One Simple Question

Sometimes the whole job is tiny and repeated at enormous volume. Not "join four tables and group by month" — just "give me the value stored under this exact name, in under a millisecond, a million times a minute". For that one shape of question, the relational machinery — the planner, the rule-checking, the flexibility to ask anything — is overhead you're paying for and not using.

A tool that does only key-to-value lookup, and does nothing else, can do that one thing faster than a database built to answer any question. The third pressure is raw speed on a deliberately narrow question, and the next chapter's cache is exactly this pressure answered.

Shapevarying, nested records

→

Spreadtoo big for one machine

→

Speedone narrow question, fast

The Question to Carry: What Did It Give Up?

Back in Chapter 1 we compared database families to vehicles — a bicycle, a van, a freight train, all moving things, and choosing before you know the cargo being the classic mistake. This chapter is where the cargo finally arrives that the van genuinely can't carry: some jobs need the bicycle's nimbleness or the freight train's scale, and the relational van is the wrong shape for them. That's the whole reason the other vehicles exist.

So here is the single question to carry through the next four pages, the one that turns every database sales pitch into an engineering conversation: what did it give up? Every NoSQL family wins its specialty by surrendering something relational — the joins, the strict transactions, the ability to ask any question. Find what each one traded away, and you understand it completely. A family that seems to have no downside just hasn't shown it to you yet.