Why Memory Matters

Concept. CS145 is about data and how it persists over time.

Intuition. Your other classes teach the actions: algorithms, model inference, systems. Actions are short-term. The data those actions read and write lives in a database, on disk, long-term. ("Memory" here means that durable database, not the volatile RAM chip in your laptop.)

What this course teaches

What this course teaches Top: a soft grey container labeled SHORT-TERM ACTIONS holds four small circles labeled function call, model inference, system event, and API request. A single arrow drops from the container down toward the row of module panels below. Below, six module panels left to right. The same database cylinder is in every panel; each module adds one capability the database needs at the next scale. M1 (SQL, blue): a SQL query goes into the cylinder and rows come out. The language is already declarative and parallel. M2 (Storage, orange): the cylinder shows columnar layout inside, with a disk underneath. M3 (Indexing, emerald): a B+Tree perches on top of the cylinder, labeled one billion rows to milliseconds. M4 (Transactions, violet): a lock encloses the cylinder, two concurrent users converge on it. M5 (Distributed, pink): three cylinders side by side with replication arrows between them. M6 (Modern systems, slate): three small cylinders embedded in a phone, an LLM sparkle, and a server stack. Bottom axis: one machine to many machines, single query to planet-scale state. Color key: grey is the transient action layer your other classes teach; each module's accent marks its panel, and the cylinder is the same shape throughout because the primitive does not change, only what surrounds it. What this course teaches Other classes teach the actions on top. CS145 builds the database underneath, one capability per module. SHORT-TERM · ACTIONS function call model inference system event API request M1 · SQL SELECT genre, COUNT(*) FROM listens GROUP BY ... Declarative. Parallel. A complete database. + M1B: CTEs, windows M2 · Storage disk pages How rows live on disk. Pages, columns, bloom filters. M3 · Indexing 1B rows → ms B+Trees and LSM. Find rows in milliseconds. + M3B indexes · M3C optimizer M4 · Transactions all-or-nothing Concurrent users, never charge twice. + M4B recovery · M4C TM M5 · Distributed shard 1 · shard 2 · shard 3 Sharded, replicated. One database, many machines. M6 · Modern systems phone agent server a database in each Where databases live now: phone, agent, edge, server. one machine, today many machines, planet-wide Color key   grey = the transient action layer (your other classes)  ·  each module is colored for consistency

Figure 1. Each module adds one capability the database needs at the next scale. M1 is already a complete, declarative, parallel database; the rest of the course is what happens around it. M2 decides how rows live on disk. M3 finds rows in milliseconds. M4 keeps state correct when many users hit it at once. M5 spreads one logical database across many machines. M6 is where databases live in the wild: in your phone, inside an LLM, at the edge. See the course map for how these connect to the projects and the careers they lead to.

Where we start: three teardowns

We learn how the database is built by taking three real systems apart and finding the same primitive inside each one. In teaching order, from a laptop to the planet:

Three teardowns, one primitive Three blue cards left to right: 0.1 small analytics (Pandas, the on-ramp and the RAM limit), 0.2 agent memory (no memory then local then global, the whole course in one example), and 0.3 a big service (UberEats, planet scale plus the offline edge). A grey scale axis underneath runs from one machine to many machines. Color key: blue is a teardown, the same database at growing scale. Three teardowns, one primitive The same SQL database, three settings. This course is the bridge. 0.1 · Small analytics Pandas and Polars on a laptop. Fast, until it runs out of RAM. ~16 GB on a laptop the on-ramp 0.2 · Agent memory No memory, then local, then global. 1 user → 800 M users the whole course in one example 0.3 · A big service UberEats: one database, three sides, plus the edge. billions of orders, planet-wide planet scale and the edge one machine many machines Color key  blue = a teardown, the same database at growing scale

Figure 2. The whole kickoff in one map. The same database in three settings, left to right from one machine to many. The numbers under each card are the working scale: a 16 GB laptop, then one user growing to 800 million, then billions of orders across the planet. Modules 1 through 6 build it.

0.1 Pandas: Deconstructing Small Analytics. Pandas and Polars on a laptop, the world you already know. What happens when the data no longer fits in RAM?

0.2 Claude & OpenAI: Deconstructing Agent Memory. One AI coding agent, the whole course in one example. Why does it hallucinate with no memory? Why is the context window the same memory limit? How does a local database fix it on one machine? How do you scale it to millions of users, each with their own memory?

0.3 UberEats: Deconstructing a Big Service. UberEats at planet scale, plus the offline edge. How does one database serve billions? How do the driver apps work on a phone?

The short version of all three: the context window, the DataFrame, the phone in a tunnel are short-term memory. Anything that has to outlast them lives in a database. Every serious product (ChatGPT, Stripe, Epic, Spotify) is built that way.

Every product you use has a database underneath. By the end of this course, you can design one. Start with 0.1 Pandas: Deconstructing Small Analytics.