Renting a Memory

01Who Patches the Database?

Start with a question Project 2 quietly raised and never answered. Your system is three services and a datastore. The services are containers now — disposable, replaceable, watched over by the manager you hired last week. The data is different. Some of you ran the database as just another container; some clicked the provider’s “managed database” button because the spec said so, without knowing what the button bought. Either way, answer honestly: when a security hole in the database engine is announced on a Tuesday, who patches it? Who takes the backups — and who has ever tested a restore? And when the machine under it dies at 2 a.m., the manager can start a fresh database container in seconds… attached to what data?

That last one deserves a beat. Notes 08’s whole pitch was that failure is boring: kill a pod and an identical one appears. That works because pods carry nothing irreplaceable. A database is the opposite — it is the one component whose entire job is to be irreplaceable. Lose it and there is nothing to restart from. The manager can babysit the box the database runs in. It cannot take responsibility for the bytes.

So this week you hire a second professional. Last week, a manager for the containers. This week, a landlord for the data. Think of the difference between owning a house and renting an apartment. In the house, the leaking roof, the furnace, the locks — all yours, forever, including at 2 a.m. In the apartment, the building is the landlord’s problem. What stays yours is everything that makes the place yours: the furniture and who you invite in.

That is the definition to carry: a managed database means the provider runs the database engine — the machine, the patches, the backups, the failover — and you bring the two things that were always really yours: the shape of your data, and the questions you ask it.

02What “Managed” Buys You

Here is the chore list that disappears the moment you rent instead of own. Every line is real work someone on a database team does today, and every line has ruined somebody’s weekend:

• Install and configure. The engine, its settings, its storage — tuned by people who do nothing else all day.
• Patch. The Tuesday security hole gets fixed in a maintenance window you choose — you read about it instead of living it.
• Back up — and restore. Automatic daily backups, plus point-in-time recovery: “rewind my database to 3:59 p.m. yesterday, just before the bad deploy.” An untested backup is a rumor; the landlord tests theirs.
• Failover. A standby copy in another building — Notes 04’s buildings — kept in sync and promoted in about a minute when the first one dies. Your 2 a.m. becomes a log line.
• Read replicas. Extra copies that answer read-only questions, added with a checkbox when one machine stops being enough for the asks.

The names, once, in parallel, because every provider sells the same apartment: Amazon RDS, Google Cloud SQL, Azure Database — each one runs the famous open engines (PostgreSQL, MySQL) that you could install yourself, exactly as a managed Kubernetes runs the same Kubernetes. Each also sells a serverless flavor that grows, shrinks, and bills by actual use — Notes 01’s elasticity finally reaching the database.

03The Relational Shape

You now know who runs the database. Next question: what shape should it be? For fifty years the default answer has been relational — and the plainest way to picture it is a set of spreadsheets that keep promises.

A relational table looks like a spreadsheet: a fixed set of columns, one row per thing. But where a spreadsheet lets you type anything anywhere, a table refuses. Every row must fit the declared columns — a price must be a number, an email must exist. The declaration is called a schema: the shape, written down and enforced at the door.

The second promise is the one that names the whole family: tables relate, and the database enforces the relationship. An order row says “customer 1.” The database will not let you insert an order for customer 9 if there is no customer 9, and will not let you delete Alice while her orders still point at her. Call it the no-orphan-orders rule: no row may point at a row that isn’t there.

How do you talk to it? In SQL — and the right way to think about SQL is asking in full sentences. You do not tell the database how to search; you describe what you want: “every order Alice placed in October, newest first.” In SQL that sentence barely changes shape: SELECT * FROM orders WHERE customer = 1 ORDER BY placed_at DESC. The database plans the hunt itself. Fifty years of shared vocabulary, on every cloud, in every engine — that is why it survives.

The third promise is the quiet superpower: the transaction, an all-or-nothing envelope. The classic story takes four sentences. Move $100 from Alice to Bob: step one subtracts from Alice, step two adds to Bob. The power dies between the steps, and $100 has simply vanished. A transaction seals both steps in one envelope: either everything in it happens, or none of it ever did — half-done is not a state the world is allowed to see.

Put the three promises together — rows that must fit, relationships that must hold, changes that land whole — and you know when relational wins: money, inventory, bookings — anything where a wrong answer is expensive. The promises are exactly the apologies you never want to write.

04The NoSQL Shapes

If relational is so good at keeping promises, why did anyone leave? Two walls, both hit at full speed by the early giant websites.

Wall one: the rigid columns. The schema is a promise, and promises bind. If every user’s profile has different fields — one has pronouns, one has forty game badges, one has nothing — then a fixed set of columns is a parking lot where every spot is the wrong size. You end up with a hundred mostly-empty columns, or a schema change every sprint.

Wall two: the one-machine ceiling. The promises are cheap to keep when all the data stands on one machine. Spread it across fifty machines and “no orphans” means machines checking with each other before every write — brutally slow. For a long time the practical answer was simply “buy a bigger machine,” and at some size there is no bigger machine. The giants needed the other direction: more machines — Notes 03’s horizontal scaling, now for data.

So a family of stores appeared that dropped some promises to get past the walls. The name stuck was NoSQL — a terrible name that describes what they lack instead of what they are. Here is what they are:

Now the honest trade, stated once and plainly. What NoSQL bought: flexibility (records of any shape) and spread-across-machines (no ceiling). What it paid: the promises. Asking questions across records — “join every order to its customer” — stops being the store’s job and becomes your code’s. Strict all-or-nothing envelopes shrink or vanish. And because the data lives in copies on many machines, you re-meet an old acquaintance: copies that briefly disagree. Notes 04’s stale read is back, now inside the database — many NoSQL stores will cheerfully give you a slightly old answer rather than keep you waiting. Next week is entirely about that bargain; for now, know that it exists and that nobody gets to skip it.

05Choosing a Shape

Shapes are not fashion; they are a fit between the data and the questions. Walk three ordinary scenarios:

• A store’s orders → relational. Orders are money, orders point at customers, and a half-done refund is an apology with a dollar amount. Buy all three promises.
• User profiles with ever-changing fields → document. Each profile its own shape, fetched whole by one user id, never joined to anything. The schema would be all cost and no protection.
• Session tokens → key-value. Millions of “is this login still good?” asks, each by exact ticket. Losing one just means logging in again. The coat check, at full speed.

06The Barista’s Memory

One piece left, and it is the cheapest performance win in this whole course. Picture the café barista who knows the regulars. The first time you order, she walks to the kitchen and asks. The second time, she doesn’t move: “Oat latte, $4 — same as always.” She has a small, fast memory in front of a slower, truthful one. That is a cache.

You have already met caches twice without the name. Notes 05’s phone books penciled in answers with an expiry note, and the copy shops held TTL-stamped copies of your files in every city. Today’s cache is the same reflex one layer down, standing between your app and the database. Two words cover its whole life: a hit — the answer was in memory, served in about a millisecond; and a miss — not there, so the app asks the database, then leaves a note in the cache so the next ask is a hit. Someone always pays full price once.

Every note carries a TTL — “trust this for 60 seconds” — the exact same penciled note as DNS in Notes 05, doing the exact same job: old answers die of old age. And here is a connection worth a highlight: a cache is just a key-value store from §04 with one rule added — everything in it is allowed to vanish. That is why the famous caches, Redis and Memcached, are key-value stores, and why the landlord rents those too: ElastiCache (AWS), Memorystore (Google), Azure Cache for Redis.

6.1 The classic pain: the barista doesn’t know

Now the famous problem, in café terms. A regular changes her usual order. The kitchen knows. The barista — cheerfully, confidently — keeps serving the old one, because nobody told her memory. In system terms: the database was updated, but the cache still holds the old value, and every hit serves a confident lie until the note dies. Telling the cache is called invalidation, and it is genuinely hard to do perfectly, because every single path that changes the data must remember to shout — forget one and the lie is back.

So carry the sane default instead of a heroic scheme: read-through plus a TTL. Read-through: the app always asks the cache first, and on a miss fetches the truth and leaves a note. TTL: every note expires on its own, so the worst case is bounded — “this page can be up to 60 seconds behind” is a sentence you can say out loud to a stakeholder. If 60 seconds is fine, cache it. If it isn’t, shorten the TTL. If even 5 seconds of lie is unacceptable — don’t cache that value at all.

Which is the real rule for when caching helps: it saves you when reads are heavy and repetitive — menus, profiles, top-10 lists, the same questions all day (a 90% hit rate means the database hears one question in ten). It lies to you exactly where wrongness is expensive — the account balance mid-transfer, the last seat on the flight. Notice that is the same instinct as §05: know which of your questions must be true, and which merely need to be fast.

Three experiments worth your two minutes. Send a few bursts and watch the hit rate climb as the regulars’ notes accumulate — then slide the mix to 0% (all strangers) and watch the cache become useless: caches only pay on repeated asks. Set the TTL to 0 and send a burst: a note that expires instantly is no note at all, and every ask walks to the kitchen. Then the main event: with the latte cached, raise its price — and count how many customers are quoted the old one before the note dies. Now set the TTL long, do it again, and feel why “just cache it for an hour” is a decision about how long you are willing to lie.

07The Bill

Short and honest, because Notes 01 trained you to ask. On a grown-up system the managed database is routinely the single biggest line on the bill — and the reason is a sentence you can now say precisely: your web containers scale down at night, but the database holds the state, so it never sleeps. The meter from Week 1 runs on it all 730 hours of the month.

Two knobs set the number. Instance size — how big a machine the engine stands on, billed per hour whether anyone asks it anything or not (the serverless flavors exist precisely to un-stick this knob for spiky, modest workloads). And storage plus IOPS — how big the shelf is, and how many trips to the shelf per second you’ve reserved. Students watch the first knob and get surprised by the second.

And one win that is nearly free: the cache you just met. Every hit is a query the database never heard, and the expensive knob is sized for the questions that get through. A small cache absorbing 80% of the reads frequently lets you rent a database one or two sizes smaller — the cheapest line on the bill quietly shrinking the most expensive one. That is the Notes 01 lesson wearing this week’s apron: the meter doesn’t care how clever your code is; it cares what you asked for, and the barista makes you ask for less.

08Self-Check

Six quick questions. Pick an answer to see whether you’re right and why. Nothing is recorded; this is for you.

09Before Session 17 — November 2

A light week on deliverables, deliberately — Project 2 just landed and Project 3 is about to. Three things, none longer than a coffee. The list remembers your progress on this device.

• Drive Plate 6.2 until you can produce, on demand: a hit, a miss, an expiry, and one stale answer — and say in one sentence which TTL choice would have shortened the lie. Expect to drive it in Session 17’s opening round.
• Name the shape of your Project 2 datastore and defend it in one sentence using §05’s walk — or admit, in one sentence, which shape it should have been. Either answer is a good answer; “it was the default” is not.
• Project 3’s specification drops this week — watch the course page. Read it the day it appears; it is small and it builds directly on what you just shipped.

10Key Terms

Managed database

The landlord: the provider runs the engine, patches, backups, and failover. You bring the schema and the queries.

RDS / Cloud SQL / Azure Database

The managed-database rentals on AWS, Google, and Azure — the same famous engines, with a landlord.

Serverless database

A managed database that grows, shrinks, and bills by actual use — elasticity reaching the data layer.

Point-in-time recovery

“Rewind my database to 3:59 p.m. yesterday.” The backup chore, done properly, by someone else.

Read replica

An extra copy of the database that answers read-only questions, lightening the main one.

Relational database

Spreadsheets that keep promises: fixed columns, enforced relationships, all-or-nothing changes. PostgreSQL, MySQL.

Schema

The shape of the data, written down and enforced at the door — every row must fit.

SQL

Asking in full sentences: describe what you want, and the database plans the hunt itself.

The no-orphan-orders rule

No row may point at a row that isn’t there — a relationship enforced, not hoped for. (Formally: a foreign key.)

Transaction

The all-or-nothing envelope: everything in it happens, or none of it ever did. Half-done is not a visible state.

NoSQL

The family of stores that dropped some relational promises to gain flexible shapes and spread-across-machines.

Document store

Folders of JSON: each record its own shape, fetched whole by its id. DynamoDB, Firestore, Cosmos DB.

Key-value store

The coat check for data: ticket in, value out, nothing fancier — the fastest possible ask. Redis, Memcached, DynamoDB.

Wide-column store

A coat check whose coats are enormous sorted rows — “all events for this user, in order.” Cassandra, Bigtable.

Graph database

Relationships as the main attraction — “friends of my friends who liked this.” Neptune, Neo4j.

Cache

A small, fast, forgetful memory in front of a slower, truthful one. A key-value store whose contents may vanish.

Cache hit / miss

Hit: answered from memory, the database never hears it. Miss: the full trip, remembered for next time.

TTL

How long a cached note may be trusted before it dies of old age — the bound on how far behind an answer can be.

Invalidation

Telling the cache the truth changed. Hard, because every path that writes must remember to shout.

Read-through + TTL

The sane default: ask the cache first, fetch and remember on a miss, let every note expire on its own.

ElastiCache / Memorystore

Managed Redis/Memcached on AWS and Google (Azure: Cache for Redis) — the barista, with a landlord.

No term matches that filter.