What is a database? (and why a spreadsheet eventually breaks)

A database is an organized store of your app's facts: the users, orders, messages, and bookings. It is built so software can read and write those facts thousands of times a second without losing, duplicating, or mangling any of them. Think of it as a spreadsheet that grew up, got rules, and went to work for your app.

If you have ever run a business out of Excel or Google Sheets, you already think in rows and columns. That instinct is correct, and it is most of the mental model. The rest of this lesson is the difference, and the specific moments when the spreadsheet stops being enough.

How is a database different from a spreadsheet?

They are cousins. Both store rows of things with columns of facts about them. The database differs in four ways that only matter once real users arrive, which is exactly when they matter completely:

• It has rules. A spreadsheet lets you type 'banana' in the email column. A database refuses: this field must be an email, that one must be a number, every order must belong to a customer.
• It handles crowds. A hundred users can sign up in the same second and nothing collides, overwrites, or vanishes.
• Its tables connect. The bookings table knows which row in the users table made each booking. Change a customer's name once and every booking knows.
• Your app talks to it directly. Software reads and writes it automatically, all day, with nobody pasting anything anywhere.

When does the spreadsheet actually break?

Later than purists admit, and sooner than you hope. Spreadsheets, and spreadsheet-databases like Airtable, are genuinely fine for a surprising amount of early operating work; this club recommends running your first CRM in one. The break comes at recognizable moments:

• Your app needs to write to it by itself: a signup form at 2am can't wait for you to open the file.
• Two truths appear: the same customer exists in three rows with two phone numbers, and nobody knows which is real.
• Permissions get serious: the freelancer helping with marketing can suddenly see every customer's payment details.
• It gets slow and fragile: thousands of rows, formulas nobody remembers writing, and one accidental sort breaks everything.

What does 'thinking in tables' look like?

Take a booking app. It needs three tables: one for users (name, email, phone), one for services (title, duration, price), and one for bookings. Each booking row stores just three facts: which user, which service, what time. The pattern is the whole skill: each table holds one kind of thing, each row is one of them, each column is one fact about it.

Notice what the bookings table does not store: the customer's name. It points at the users table instead, so the name lives in exactly one place. That idea, facts living once and being referenced everywhere, is what keeps a database honest at any size, and it is the entire trick behind 'thinking in tables'. Your first data model gets its own lesson in the Build stage.

Which databases will you actually meet?

Mostly one: Postgres, the workhorse open-source database inside Supabase, which is what builders like Lovable wire in. Firebase is Google's alternative. Airtable is the bridge: a spreadsheet on the surface, a light database underneath. You do not choose between them so much as inherit whichever your builder uses, and that is fine.

One more word to recognize: SQL, the language used to ask a database questions. 'How many bookings this week?' becomes a line of SQL. You do not need to learn it; your AI tools read and write it fluently. But when an error message mentions SQL or a 'query', you now know the conversation it came from.

How do I use this tomorrow?

Tell your builder what to remember, not how to store it. 'Every booking belongs to one customer and one service.' 'A user can save unlimited drafts but publish three.' Sentences like that turn into well-shaped tables on their own. Then ask the AI to show you the tables it created and explain each one in plain language. Reading that explanation is five minutes, and it is the difference between owning your data and hoping about it.

Not sure where this database physically lives? That is the backend lesson, one row up: what a backend is, and where your data lives.

Common questions