Database Basics for Vibe Coders

The word "database" sounds like something you need a degree for. It isn't. A database is a set of lists where every item has the same labelled slots. If you've ever made a spreadsheet, you've already built one — you just didn't call it that.

But here's why it's worth ten minutes of your attention: the data model is the one part of your app the AI struggles to fix later. Screens are easy to change. Data structure, once your app is full of real data, is painful to change. Getting it roughly right early saves you the worst kind of rework.

A table is a labelled list

Think of one spreadsheet tab. The columns are the labels; each row is one item.

A users table:

| id | email | name | created_at | | -- | ----- | ---- | ---------- | | 1 | ann@… | Ann | 2026-05-01 | | 2 | bo@… | Bo | 2026-05-02 |

That's a table. Your whole database is a few of these tabs. The skill isn't technical — it's deciding which lists you need and what slots each item has.

Step one: list your nouns

Go back to your spec and circle the nouns — the things your app deals with. A blog has posts and comments. A store has products and orders. A habit tracker has habits and check-ins.

Each noun usually becomes a table. This is the whole design process for most small apps: name the things, and you've named your tables.

Step two: give each thing its slots

For each table, list what you need to remember about one item. A post:

• a title (text)
• the body (text)
• when it was published (date)
• whether it's a draft (true/false)

Don't overthink types. Text, number, true/false, and date cover almost everything early on. The AI will pick exact types — your job is to know what facts you're storing.

Step three: connect the tables

This is the one genuinely new idea, and it's simple. When one thing belongs to another, you link them with an id.

A comment belongs to a post. So the comments table has a post_id column that holds the id of its post:

| id | post_id | text | | -- | ------- | ---- | | 1 | 42 | Nice! | | 2 | 42 | Agreed |

Both comments point at post 42. That's a relationship. "A comment belongs to a post" and "a post has many comments" are the same link seen from two ends. Ninety percent of app data is just things pointing at other things this way.

The two questions that catch most mistakes

Before you build on a data model, sanity-check it:

1. "If I delete this, what should happen to the things linked to it?" Delete a post — should its comments vanish too? Usually yes. Delete a user — what about their orders? Maybe you keep them. Decide on purpose.
2. "Am I storing the same fact in two places?" If a customer's address lives in both the users table and every orders row, you'll one day update one and forget the other. Store each fact once, and point to it.

These two questions prevent the messiest, hardest-to-undo data problems.

Let AI design it — then interrogate it

You don't have to draw this alone. Describe your nouns and ask:

"Design the database tables for this. Show me each table, its columns, and how they connect. Explain why you split it the way you did."

Then push back. Ask "why is this its own table?" and "what happens when I delete a user?" The AI's first draft is usually fine, but understanding why it's shaped that way is what lets you change it confidently later.

Why this is the foundation

Everything else in your app reads from and writes to this data. Get the model right and features click into place — the screen just shows what's already well-organized underneath. Get it tangled and every new feature fights the structure, and you'll feel the app resisting you without quite knowing why.

Spend the ten minutes. Name your nouns, give them slots, draw the links. It's the least glamorous part of building — and the part that quietly decides whether the rest is easy or miserable.