What Is a Database?
Tables, rows, columns, and schemas — the mental model every other chapter in this journey builds on.
Overview
A database is organized, persistent storage that more than one person or process can safely read from and write to at the same time, and that you can ask questions of directly instead of writing custom code to search through it. That's the whole definition — everything else is implementation detail. A relational database organizes that storage into tables: a table is a named collection of records that all share the same shape, a row is one single record, and a column is one field every row has, with a declared type. A schema is just the name for that whole shape — which tables exist, and which columns each one has.
Why It Exists
You could technically store application data in a plain JSON or CSV file. It works fine for a personal script. It falls apart the moment more than one process needs to read and write that data at the same time, because flat files have no safe way to handle two simultaneous writes, no query language to ask 'find me all the rows where X,' and nothing enforcing that every record actually has the fields it's supposed to. A database exists to solve exactly those three problems: safe concurrent access, a real query language, and an enforced shape for your data — so a bug in one part of your code can't quietly corrupt every other part's assumptions about what a record looks like.
Real World Example
Someone fills out a signup form with an email and a name. That one real-world event becomes one row in a `users` table. The form's email field maps to the table's `email` column, the name field maps to `name`, and the database itself adds a few more columns you didn't put on the form — an `id` to uniquely identify that row, and a `created_at` timestamp. The schema for `users` is the declaration of exactly those columns and their types, decided once, ahead of time. Every future signup becomes another row with that same shape — that consistency is what lets you write one query that reliably works for all of them.
Example Data
users — every signup becomes one row with the same fixed shape
| id | name | created_at | |
|---|---|---|---|
| 1 | sarah.johnson@example.com | Sarah Johnson | 2026-08-01 09:15:00 |
| 2 | michael.carter@example.com | Michael Carter | 2026-08-01 10:42:00 |
How It Works
A relational database engine stores your data in tables, where a table's schema fixes which columns exist and what type each one holds — a `created_at` column is always a timestamp, never sometimes a timestamp and sometimes a string, because the engine enforces that at write time. Every row in that table gets a primary key, a value that uniquely identifies it (the next chapters cover this in depth). The engine's whole job is to hold that structure durably on disk, let you query it with SQL instead of scanning it by hand, and guarantee that concurrent reads and writes don't corrupt each other — the three things a flat file can't do.
Diagram
One real-world event becomes one row, inside a table with a fixed schema
Real-world event
a user signs up
users table
schema: id, email, name, created_at
id
integer
text
name
text
created_at
timestamp
Common Mistakes
Storing structured application data in a flat file (CSV/JSON) once more than one process needs to read or write it
Why: Flat files have no safe mechanism for concurrent writes, no query language, and nothing that enforces a record's shape — the exact three problems a database exists to solve.
Fix: Move to a real database as soon as more than one thing needs to read and write the same data — don't wait until a corrupted file forces the migration.
Storing every column as text 'to keep things flexible'
Why: Skipping typed columns quietly reintroduces the same chaos a database is supposed to prevent — dates that don't sort correctly, numbers that can't be summed, no protection against a malformed value ever making it in.
Fix: Pick the narrowest correct type for each column when you create the table, not after the data's already messy.
Using 'database' and 'table' interchangeably
Why: It sounds like a small vocabulary slip, but it leads to real modeling mistakes — like assuming one table is meant to hold every kind of record instead of one clearly-scoped kind.
Fix: Keep the levels straight: a database is the container, a table is one structured collection inside it, a row is one record inside that table.
Interview Questions
What's the difference between a database, a table, and a row?
A database is the overall container. A table is one named collection of records that all share the same schema — the same set of typed columns. A row is a single record inside that table, holding one value for each of the table's columns.
Why not just store application data in a JSON file instead of standing up a database?
A JSON file has no safe way to handle two writers at once, no query language for filtering or aggregating without loading the whole file into memory, and nothing enforcing that every record actually matches the shape your code expects. A database gives you concurrency-safe access, a real query language, and an enforced schema — all three become necessary the moment more than one process touches the data.
Is there ever a legitimate case for flat-file storage over a database?
Yes — read-mostly configuration data with a single writer, application logs meant to be consumed by a separate log-processing pipeline, or a one-off batch export are all reasonable to leave as flat files. The deciding factor isn't 'is it structured data,' it's whether more than one process needs safe concurrent read/write access and query capability — if not, a database is solving a problem you don't actually have yet.
Production Best Practices
Do
✓Give every table one clear, single purpose before you add a single column.
✓Declare explicit, narrow column types at creation time instead of defaulting everything to text.
✓Treat the schema as a real design decision — sketch it out before writing the CREATE TABLE statement.
Don't
✗Don't reach for a flat file once more than one process needs to read and write the same data.
✗Don't use 'database' and 'table' interchangeably — the distinction matters once you start modeling relationships.
✗Don't skip schema design because 'we'll fix it later' — changing a table's shape gets more expensive the more data it holds.
Comparison
| Flat File (CSV/JSON) | Spreadsheet | Relational Database | |
|---|---|---|---|
| Safe concurrent writes | No | Limited | Yes |
| Enforced schema/types | No | Loose | Yes |
| Real query language | No | Basic formulas | SQL |
| Scales with data volume | Poorly | Poorly | Well |