Unit 2 · Module 1
What Is a Database?
The spreadsheet mental model, and why RAM isn't enough
Where data actually lives
Before getting into what a database is, the more useful question is where data lives at all when an app is running. Because there isn't one answer. Data sits in different places depending on how long it needs to stay around and who needs to be able to read it.
Most people, before they start building things, never think about this. You log into an account and the app remembers you. You close the tab and come back the next day and your profile is still there. You log in from your phone and the same profile shows up there too. That feels like one thing happening, but it's actually three different layers of memory quietly cooperating.
The hierarchy, from most temporary to most permanent
Every piece of data your app touches lives somewhere on this hierarchy. The deeper down it sits, the longer it survives and the more places can reach it.
At the top is RAM. RAM is the computer's short-term memory. When your code
creates a variable like const username = "alex", that value lives in RAM. It's
fast to read, fast to write, and instantly gone the moment the page closes. Every variable
inside every function you've ever written has lived here. RAM is for things happening right
now, and only right now.
Below that is browser storage. This is data the browser saves on the user's
own device. It survives a refresh. It survives closing the tab and coming back tomorrow.
But it only exists on the one device that wrote it. If the same person opens your app on
their phone, none of it is there. The two main flavors of browser storage are
localStorage (for small, simple values) and IndexedDB (for
larger, more structured data).
Below that is the database. A real database lives on a server somewhere, not on the user's device. It survives the page closing, the device dying, the user switching to a different browser, a different phone, a different country. Anyone with permission can reach it from anywhere. This is where long-term data lives: accounts, posts, orders, history, everything an app needs to remember on behalf of every user at once.
Try It: Where data survives
Save a value into all three layers, then simulate what happens next
RAM
In-memory variable
empty
localStorage
Saved on this device
empty
Database
Saved on a server
empty
Analogy: The restaurant, again
A single order travels through three kinds of memory before the night is over.
RAM is the order the waiter is holding in their head as they cross the floor. Fast, useful in the moment, gone the second they stop thinking about it.
Browser storage is the order ticket clipped to the rail above the line. The waiter walks away and comes back later and the ticket is still hanging there. But it only exists on that one rail, in that one kitchen. The other location across town has no idea this order was ever placed.
The database is the POS system the order gets rung into. Every order from every table, every shift, every location is recorded there. Close the restaurant for the night, come back in the morning, open the system on any device at any location, and every order is still exactly where it was.
Why RAM alone isn't enough
The instinct, when first learning to code, is to treat variables as the whole story. You build a tiny app, you put data in variables, the app works. Then you refresh the page and everything resets. The first time that happens, it feels like a bug. It isn't. RAM was never supposed to remember anything past the moment.
That's the gap that browser storage and databases fill. They each solve a different flavor of "I need this to still be here later," and which one you pick depends on what later means and who else needs access.
Why browser storage alone isn't enough either
Browser storage solves the refresh problem, but it doesn't solve the second-device problem.
A todo list saved in localStorage is fine until the user opens the app on
their laptop and wonders where everything went. The data is sitting on their phone. The
laptop has no way to know that.
Browser storage is also tied to the browser itself. Clear the cache, switch from Chrome to Safari, lose the device, and the data is gone with it. There's no recovery, because no other system ever saw it.
For anything that needs to survive the device, span multiple users, or be trusted as the real record of what happened, the data has to live somewhere outside the browser entirely. On a server. In a database.
What a database actually is, in one sentence
That's the entire idea. Everything else in this unit is just unpacking pieces of that sentence: how the data gets organized, how code talks to it, how relationships between different pieces of data are described, and what specific tools (like Supabase) make all of that practical to use.
The next page picks up the most important piece: the mental model for how databases organize data. And the good news is, if you've ever opened a spreadsheet, you already have that mental model. You just haven't been told that's what it was.