In this chapter
We'll learn what NoSQL databases are and why they exist — document databases (complete folders), key-value stores (a coat check, again) and others — and how to choose between relational and NoSQL, using the two databases BlueTicket actually runs.
The Problem in Real Life
John opens the infrastructure diagram. Next to PostgreSQL there's a second database Anna has never noticed: Redis.
"Remember the sessions from Act 12 — the guest list behind the wristband?" he asks. "They don't live in PostgreSQL. They live in Redis. It's a completely different kind of database, built for a completely different job."
Why would one company need two different kinds of database?
Anna
One Kind of Database for Everything vs. the Right Kind for Each Job
Not all data is a neat table
Some data is a whole document, some is just a key and a value, some is a web of connections.
Some jobs need extreme speed
Looking up a session happens on every single request; it has to be almost instant.
Trade-offs again
Every kind of database is great at some jobs and worse at others — just like data structures in Act 09.
NoSQL Databases
NoSQL (often read as "not only SQL") is the name for databases that don't store data in relational tables. They appeared when big websites needed to store huge amounts of data, with flexible shapes, across many servers. They're not "better" or "worse" than relational databases — they make different trade-offs. The main families:
- Document database — a folder with a complete document inside: instead of splitting an event across tables, a document database stores each event as one self-contained document (usually JSON-like, Act 12) with everything about it inside: name, date, venue, artists, even a list of ticket types. Different documents can have different fields. Like keeping one complete folder per event, instead of spreading its pages across several filing cabinets. Example: MongoDB. Good for data that's read and written as a whole and whose shape varies.
- Key-value store — the coat check (again): a key-value store is a giant, very fast hash table (Act 09): you store a value under a key and get it back by the key, instantly. Nothing more. Example: Redis, which keeps data in memory (RAM), so lookups take well under a millisecond. Perfect for sessions (
session:8f2c → Zoë's session), caches, counters and rate limits. - Others you'll hear about: wide-column databases (like Cassandra) for enormous amounts of data spread across many servers; graph databases (like Neo4j) for data that's all about connections — the graphs from Act 09, like "fans who went to this show also went to..."; search engines (like Elasticsearch) for full-text search; and time-series databases for measurements over time, like the memory graph from Act 10.
| Family | Everyday picture | Example | Great for |
|---|---|---|---|
| Relational | Strict filing cabinets with linked forms | PostgreSQL, MySQL | Money, bookings, accounts |
| Document | One complete folder per thing | MongoDB | Flexible, self-contained records |
| Key-value | A coat check | Redis | Sessions, caches, counters |
| Wide-column | Huge ledgers spread over many buildings | Cassandra | Massive write-heavy data |
| Graph | A map of who knows whom | Neo4j | Connections and recommendations |
| Search | A book's index for everything | Elasticsearch | Full-text search |
| Feature | Relational | NoSQL (in general) |
|---|---|---|
| Data shape | Fixed tables and columns | Flexible (documents, key-values, graphs) |
| Relationships | Built in: foreign keys, joins | Often handled by the application |
| Transactions and constraints | Strong (ACID) | Varies; often simpler or weaker |
| Scaling | Usually one main server, scaled up | Often designed to spread across many servers |
| Query language | SQL | Varies by database |
| Data | Stored in | Why |
|---|---|---|
| Events, seats, fans, bookings, payments | PostgreSQL (relational) | Must be strictly correct; many relationships |
| Login sessions | Redis (key-value) | Read on every request; must be instant |
| Short-lived caches | Redis (key-value) | Fast; fine to lose and rebuild |
In a document database, an event can be one self-contained document. In a key-value store, a session is just a key and a value.
// A document (MongoDB-style){"_id": "evt_42","name": "Friday Stand-Up Night","date": "2026-11-13T20:00:00Z","venue": { "name": "Grand Hall", "address": "14 River Road" },"ticketTypes": [{ "name": "Standard", "priceCents": 4999 },{ "name": "Student", "priceCents": 3999 }]}// A key-value pair (Redis-style)// key: session:8f2c// value: { "fanId": 77, "loggedInAt": "2026-11-14T10:00:00Z" }
Lines starting with // are comments for you; real JSON doesn't allow comments.
Relational vs. NoSQL — how to choose: relational databases shine when data has a clear structure, many relationships, and must be strictly correct: money, bookings, stock, accounts. Their transactions and constraints (last chapter) are hard to beat. NoSQL databases shine when you need flexible shapes, extreme speed for simple lookups, or enormous scale across many machines — often accepting weaker guarantees in return.
Most real companies use both: each kind of database for what it's best at. That's called polyglot persistence. BlueTicket keeps bookings, payments, seats and fans in PostgreSQL, because they must be exactly right. It keeps sessions and short-lived caches in Redis, because they're simple key-value lookups that happen on every request and must be lightning fast — and losing a cached copy is fine, because it can be rebuilt.
Anna adds both to her notes, with one line underneath: "Bookings must be correct → relational. Sessions must be fast → key-value." BizTechLab's Non-Relational Databases course covers every NoSQL family in depth, with the same kind of story.
Key Takeaway
NoSQL databases store data without relational tables: document databases keep each item as a complete JSON-like document (MongoDB), key-value stores are giant, fast hash tables (Redis), and others handle wide-column, graph, search and time-series data. Relational databases win when structure and strict correctness matter; NoSQL wins for flexible shapes, speed and huge scale. Most companies use both.
Why This Matters
Choosing the right database for each job is one of the most important early decisions in any system, and it's hard to change later. Knowing the families — and that "use both" is normal — lets you understand any company's architecture diagram, including the Sale Day design BlueTicket builds in Act 14.
Anna knows what databases are, how they're shaped and which kind fits which job. One practical question remains: how does BlueTicket's code actually reach the database at all — and when is a plain file still the right choice?