Course B · Module B1 Production · Lesson 2 of 18

Databases

Understand where your app's data actually lives — and look at it without breaking anything.

~13 min · Have your app's database dashboard open if possible · Prereq: B1 GitHub & Worktrees

Your app is more than screens and buttons. Behind every form submission, every user account, every order — there is a database storing the real thing. Most founders treat it as a black box and hope the AI wired it up correctly. That's fine for a prototype, but not for production. Your single win today: by the end you'll be able to open your database, read what's in it, and understand its structure well enough to spot a problem before it becomes a customer complaint.

A database is a smart spreadsheet your app reads and writes

Picture a set of Google Sheets, except instead of you opening them, your app opens them automatically every time someone clicks a button. A user signs up — a new row appears in the "users" sheet. They place an order — a new row appears in the "orders" sheet. They update their address — that row changes. Your app is constantly reading and writing to these sheets in the background.

That "smart spreadsheet system" is the database. The individual sheets are called tables. The columns are fields. Each row is a record.

TableOne sheet of related data — users, orders, products. Each table has one job.

Column (field)A named piece of data — email, created_at, total_price. The column's type (text, number, date) is enforced.

Row (record)One entry in a table — one user, one order, one product listing.

IDA unique number or code every row gets automatically. The way tables link to each other — an order row stores the user's ID, not their whole profile.

Notice that last point about IDs. Tables refer to each other rather than duplicating data. An order doesn't store the customer's name and email — it stores their user ID, and the app looks up the rest when needed. This is called a relational database, and it's what Supabase, PlanetScale, and most app-builder backends give you by default.

Your app builder already gave you a database

If you built your app in Course A with a tool like Supabase, Lovable, or Replit, a Postgres database was created for you automatically. You can see it — and that's the most useful thing you can do today.

Supabase Table Editor gives you a spreadsheet-style view of every table in your database. You can read rows, edit individual cells, and even add or delete records — all without writing a line of code. This is your primary tool for understanding what's in there and for fixing data problems when they come up.

The place to start is always reading, not writing. Open the Table Editor, look at the rows your app has created, and ask yourself: does this look right? Are there rows I'd expect that aren't there? Are there unexpected nulls (empty fields) where there should be data? This kind of quick visual check catches whole categories of bugs that would otherwise take hours to diagnose through code.

Editing data safely — and why backups matter

You can edit rows directly in the database dashboard. This is sometimes the fastest way to fix a customer problem ("their account is stuck in a bad state — let me manually correct that field"). But it bypasses all the checks your app code normally runs, so a wrong edit can leave data in an inconsistent state.

✓ Safe to do directly

Correcting a typo in a text field
Marking a test record as deleted
Adding a missing value to an optional field
Querying and reading data to understand it

✗ Do through the app, not directly

Changing a user's password (use the auth system)
Moving money or adjusting balances
Deleting rows that other tables reference by ID
Anything your app's code does validation on

The fail-safe for all of this is a backup. Supabase takes automatic daily backups on paid plans. Before any significant manual edit on a live database, confirm a recent backup exists — or trigger one manually first. That way a bad edit is annoying rather than catastrophic.

One SQL command worth knowing

You don't need to learn SQL (the language databases speak), but one command will serve you well in every debugging session:

SELECT * FROM orders
WHERE user_id = 4821
ORDER BY created_at DESC
LIMIT 10;

Read it aloud: "Show me all columns from the orders table, for the user with ID 4821, newest first, ten rows maximum." That's it. Paste this into Supabase's SQL editor, swap in the table name and the ID, and you can inspect any user's records in about thirty seconds. Your AI tool can write the exact query for your schema — just describe what you're looking for in plain English.

Check yourself

Answer before opening — recalling it is what makes it stick.

A customer says their order isn't showing up in the app. What's the first thing you should do?

Open the database and look at the orders table for their user ID. Before changing any code, check whether the row actually exists — it might be a data problem (the record was never created or was created with the wrong user ID) rather than a display bug. Read first, then diagnose.

What's the difference between a table and a row?

A table is the whole sheet — for example, all orders; a row is a single entry in that sheet — one specific order. Tables hold all records of one type; each row is one instance of that type.

Why does the orders table store a user_id instead of copying the user's full name and email into every order row?

To avoid duplicating data. If a user changes their email, you'd have to update every order row. Storing just the ID means the user's profile is the single source of truth — orders just point to it. This is the relational model.