Data

What a Database Actually Is

Vibe Coder 101 · Phase 3: Under the Hood · Stage 13 of 38 · about 16 min

Start with something familiar: a spreadsheet.

A sheet has columns across the top (Name, Email, Signed up) and rows going down, one per person. That is genuinely close to how a database is organized:

  • A table is one sheet — say, "users".
  • A row (or record) is one thing in it — one user.
  • A column (or field) is one fact about each thing — their email.
  • An id is a unique number or code for each row, so you can point at exactly one and never confuse two people with the same name.

If you understand a spreadsheet, you already understand the shape of a database. So why not just use a spreadsheet?

Four things a database does that a spreadsheet cannot

1. Many people at once, safely. If two people edit the same spreadsheet cell simultaneously, one silently wins. A database is built so that cannot quietly happen — two people signing up at the same instant both get saved.

2. Finding things fast. Searching ten rows is instant either way. Searching two million is where a database's index earns its keep — the same reason a book has an index instead of you reading every page.

3. Refusing bad data. You can tell a database "email is required and must be unique". It then enforces that forever, even when your code has a bug. A spreadsheet will cheerfully accept "banana" in the date column.

4. Connecting things. An order belongs to a customer; a customer has many orders. A database can hold that relationship properly, so deleting a customer does not leave orphan orders pointing at nobody.

Why not just save files?

You can, and for small things it is fine. It falls over in predictable ways: two saves at once can corrupt the file, you have to load the whole thing to find one item, and there is nothing stopping bad data going in.

The trap worth knowing: an AI asked to "save the data" will often reach for the simplest option and not mention any of this. So ask directly — where is this stored, what happens if two people do it at once, and what happens if it fails halfway?

SQL and NoSQL, without the argument

You will see these two words constantly. The honest short version:

  • SQL databases (Postgres, MySQL, SQLite) are the spreadsheet model taken seriously: fixed columns, strict rules, excellent at relationships. SQL is the language you use to ask them questions.
  • NoSQL databases (things like document stores) are more like a filing cabinet of flexible forms. Each record can have a different shape, which is convenient early and can get messy later.

For a first real app, a SQL database is usually the safer default — its strictness catches your mistakes, and almost every tutorial and AI model knows it deeply. That is a genuine advantage, not a fashion.

Two words you will meet

A query is a question you ask the database: "give me all users who signed up this week." A migration is a recorded change to the shape of your tables — adding a column, say. Migrations matter because your app and your database have to agree about that shape; a migration is how they stay in step instead of one quietly breaking the other.

Backups: the part people skip until it hurts

A database is where the thing you cannot recreate lives. Code you can regenerate; your users' data you cannot.

Three questions worth being able to answer before real people rely on your app:

  • Is it backed up, and how often?
  • Have you ever actually restored one? An untested backup is a hope, not a backup.
  • What is the worst case? If the last backup was last night, you are accepting the loss of up to a day.

Most hosted databases do automatic backups. Knowing whether yours does, and how far back it goes, is the point.

Your turn

Sketch the tables your project would need — on paper is fine. For a to-do app that might be one table: tasks, with columns for id, text, done, and created date. For a shop it might be customers, products, orders.

You have just done data modeling, which is the part of back-end work that matters most and needs no code at all.

The next stage takes this practical: browser storage versus a real database, and the rule about API keys that saves people money.