What Are Databases?
Why every app needs a database, and why a spreadsheet isn't enough.
Every app you use remembers things. Instagram remembers your followers. Spotify remembers your playlists. Your bank remembers every payment you've ever made.
Where does all that live? Not in a text file, and not in a spreadsheet — it lives in a database: a program whose entire job is to store data safely and answer questions about it in milliseconds.
In this course you'll learn to talk to databases yourself. By the end, you'll design them from scratch and pull answers out of millions of rows with a few lines of SQL.
"Why not just use a spreadsheet?" — great question. Spreadsheets are fine for a shopping list. They fall apart when real apps need them:
- Size — spreadsheets choke past ~100,000 rows; databases handle billions.
- Many users at once — two people editing the same spreadsheet cell = chaos. Databases coordinate thousands of simultaneous users safely.
- Rules — nothing stops you typing "banana" into a spreadsheet's price column. Databases enforce rules about what's allowed.
- Questions — "Which customers spent over $100 last month but nothing this month?" is a nightmare of manual spreadsheet gymnastics — and one short sentence in SQL.
A startup tracks its 40 customers in a spreadsheet. It grows to 4 million customers, a mobile app, and 200 employees who all need to look up customer info at the same time. What's the right move?
- AMove the data into a database — spreadsheets can't handle this scale or simultaneous access
- BSplit the data across 100 smaller spreadsheets
- CBuy a faster laptop for the spreadsheet
- DPrint backups and keep using the spreadsheet
The kind of database you'll learn here is a relational database — the most widely used kind, powering everything from banks to Instagram.
The idea is simple: data lives in tables (think: strict, super-powered spreadsheets), and tables can relate to each other. A customers table and an orders table can be linked so the database knows exactly which customer placed which order.
Two terms to lock in:
- Relational — the tables-that-link-together model you'll use all course
- SQL — Structured Query Language, how you ask a relational database questions
SQL has been the standard for 50 years, and it's one of the most in-demand skills in tech: developers, data analysts, product managers, and scientists all use it daily.
Which statement best describes a relational database?
- AData stored in tables that can be linked to each other, queried with SQL
- BA folder of spreadsheet files that sync automatically
- CA single giant text file with all the app's data
- DA tool that only stores numbers, not text
You'll hear about two big families of databases:
- Relational (SQL) — PostgreSQL, MySQL, SQLite, SQL Server. Data has a fixed structure, tables link together, rules are enforced.
- NoSQL — MongoDB, Redis, DynamoDB. Looser structure, great for specific specialized jobs.
- This course uses PostgreSQL — the world's most popular open-source relational database.
Don't worry about the choice: 95%+ of what you learn applies directly to MySQL, SQLite, and every other SQL database. And SQL is the right first database skill either way — even NoSQL job postings ask for it.
You're building a system for medical records: patients, doctors, appointments, prescriptions — all connected, with strict correctness requirements. Which type of database fits best?
- ARelational (SQL) — structured data with clear links between records and strict rules
- BNoSQL — it's newer, so it must be better
- CA plain text file — simpler is better
- DNo database — keep it all in the app's memory