What Is a Database? A Guide for People Building Apps
A database is where an app keeps its records so they're still there tomorrow. How tables and relationships work, with a booking app example and what to ask AI.
Mythex Team · · 5 min read
A database is an organised store of information that an app saves to and reads from — its users, orders, bookings, messages. Unlike information kept only in a browser tab, data in a database is still there after a refresh or a restart, and everyone who uses the app sees the same records. Most databases organise data into tables, much like sheets in a spreadsheet, but with strict rules that keep the data consistent.
Why it matters when you build with AI
The most common surprise for people building with AI is an app that looks finished but forgets everything. You add a customer, refresh the page, and it's gone. That usually means the app was keeping data in the browser's memory, not in a database.
A database is also where many of your most important decisions live, whether you realise it or not:
- What you record. If you don't store a booking's status, you can't show which bookings were cancelled.
- How things connect. Whether one customer can have many bookings, or one booking many services, shapes the whole app.
- Who can see what. Most privacy mistakes are about which records a user can read.
You don't need to design the database yourself. But understanding the basics lets you describe your data clearly and catch problems early.
An everyday analogy
Picture a well-run filing cabinet in a small office.
Each drawer holds one kind of thing: one drawer for clients, one for appointments, one for invoices. Inside each drawer, every folder follows the same format, with the same fields filled in. Each folder has a unique reference number, and when an invoice belongs to a client, the invoice folder notes that client's number instead of photocopying their whole file.
That's a relational database. The drawers are tables, the folders are rows, the fields are columns, the reference numbers are primary keys, and the notes pointing to another folder are foreign keys. A good office manager also enforces rules — no appointment without a date, no two clients with the same number — just as a database does.
A worked example: a salon booking app
Say you ask an AI to build a booking site for a hair salon. A sensible database would have four tables.
services
| id | name | duration_minutes | price |
|---|---|---|---|
| 1 | Haircut | 45 | 40.00 |
| 2 | Colour | 90 | 95.00 |
staff
| id | name | |
|---|---|---|
| 1 | Sara | sara@example.com |
| 2 | Omar | omar@example.com |
customers
| id | name | phone | |
|---|---|---|---|
| 101 | Lena Park | lena@example.com | 555-0100 |
bookings
| id | customer_id | service_id | staff_id | starts_at | status |
|---|---|---|---|---|---|
| 5001 | 101 | 1 | 2 | 2026-10-03 14:00 | confirmed |
Look at the bookings table. It doesn't copy Lena's name and phone number into every booking; it stores customer_id = 101. If Lena changes her phone number, it changes in one place and every booking shows the new one. This is the core idea of a relational database: store each fact once, and link to it.
The same structure answers useful questions:
- "Which slots are free for Omar on Friday?" — look at Omar's bookings that day.
- "How much did colour appointments earn this month?" — join bookings to services and add up prices.
- "Which customers haven't booked in 90 days?" — compare customers with their latest booking.
Common terms explained
| Term | What it means |
|---|---|
| Table | A collection of one kind of record, like customers or bookings. |
| Row (record) | One item in a table — one customer, one booking. |
| Column (field) | One piece of information every row has, like email or price. |
| Primary key | A unique ID for each row, usually a number or random string. |
| Foreign key | A column that points to a row in another table, like customer_id in bookings. |
| Schema | The overall design: which tables exist, their columns and how they link. |
| Query | A request to read or change data, such as "all bookings for tomorrow." |
| SQL | Structured Query Language, the standard language for querying relational databases. |
| Migration | A saved, repeatable change to the schema, such as adding a column. |
| Index | A lookup structure that makes searches on a column faster, like a book's index. |
| CRUD | Create, Read, Update, Delete — the four basic things apps do with data. |
| Backup | A copy of the data you can restore if something goes wrong. |
Types of databases
| Type | How it stores data | Examples | Good for |
|---|---|---|---|
| Relational (SQL) | Tables with fixed columns and links between them | Postgres, MySQL, SQLite | Most business apps: bookings, stores, CRMs, SaaS |
| Document (NoSQL) | Flexible JSON-like documents | MongoDB, Firestore | Data whose shape varies a lot from record to record |
| Key-value | A value stored under a key | Redis | Caching, short-lived data like sessions |
For almost everything a founder or small business builds first, a relational database is the safe default.
Where the database sits in your app
Visitors never talk to the database directly. The page in their browser (the frontend) asks your server (the backend) for data, usually through an API. The server checks who is asking and whether they're allowed, then queries the database and sends back only what that person should see.
That middle step is important. If the browser could query the database directly with full access, anyone could open developer tools and read everything.
Common mistakes and misconceptions
- Keeping data only in the browser. Browser storage (such as localStorage) lives on one device and one browser. It's fine for a remembered filter, not for orders.
- Stuffing everything into one table. A single "bookings" table with the customer's name, phone and service price copied into every row gets out of sync fast.
- Storing passwords as plain text. Passwords should be hashed, never stored readable. See what authentication is.
- No rules on the data. Without required fields and uniqueness rules, you'll get bookings with no date and duplicate customers.
- Forgetting about deleting. Decide whether deleting a customer deletes their bookings, keeps them, or is blocked.
- Using production data to experiment. Test risky changes somewhere safe first, and keep backups.
- Treating the spreadsheet as the database forever. Spreadsheets are great for starting out, but they struggle with many simultaneous users and permissions. See how to turn a spreadsheet into an app.
What to ask your AI builder for
- "Save this in a database, not in the browser. Tell me which tables you'll create."
- "Show me the schema as a simple table: each table, its columns and how they link."
- "A customer can have many bookings; each booking has exactly one service and one staff member."
- "Make email required and unique for customers."
- "Stop two bookings for the same staff member overlapping."
- "Only the logged-in owner can read all bookings; customers can only see their own. Enforce that on the server."
- "When I delete a service, don't delete past bookings — mark the service inactive instead."
Databases in Mythex
When your app needs to save data, Mythex adds a dedicated Postgres database to the project — you can ask in chat ("save waitlist sign-ups to a database") or use the /database command. Connection details are passed to your app automatically, and the agent creates the tables. The database sleeps after five idle minutes and wakes on the next request, and published usage is charged for the time it was awake, from the same credit balance as building. It's available on Free and Pro. The database docs cover the details, and the app templates include data-driven starting points.
Questions
What is a database in simple terms?
A database is an organised store of information that an app can save to and read from, such as users, orders or bookings. Unlike data kept only in a browser tab, it is still there after a refresh, a restart, or when someone opens the app from another device.
Is a spreadsheet a database?
A spreadsheet can hold the same kind of data, but it isn't built for apps. A real database enforces rules about what each column holds, links tables together reliably, handles many people writing at once, and controls who can read what.
What's the difference between SQL and NoSQL databases?
SQL (relational) databases such as Postgres and MySQL store data in tables with defined columns and relationships between them. NoSQL databases such as MongoDB store more flexible documents. Most business apps — bookings, CRMs, stores — fit the relational model well.
Does my app need a database?
If it needs to remember anything people enter — sign-ups, orders, messages, settings — and show it later or to someone else, yes. A purely informational website with no forms that save data usually doesn't.