Why I'm writing about this
For the longest time, databases scared me.
Not because they're scary. Because I didn't know much about them. Coming from a non-technical background, it felt like something that would be hard to grasp.
I'm not a database expert (yet). But through the years, with hands-on practice, I got the basics in.
The first time I pushed myself to log in and run a simple query? It was because I was tired of asking my developer every single time I needed to check some data.
I had this feeling: I JUST WANNA DO IT MYSELF. And it finally won over my fear.
And I know that with AI and a quick Google search, I can handle the rest, at least to the level a product manager actually needs.
So that's what we're doing today. Uncovering the mystery of databases in plain terms, with a hands-on exercise you can follow along with. Because that's how the lessons actually stick.
The database ecosystem
Before we get into databases, it helps to understand where a database actually lives inside an application.
Most apps are built in layers.
There's the frontend, the part you see and click. There's the backend, the logic running behind the scenes. And there's the database, where all the data is stored.
When you do something in an app, like load your orders, the frontend asks the backend, the backend queries the database, and the answer travels back up to your screen.
The database sits at the bottom of all this. Quiet, but holding everything together.
Not every app needs a database, though. If an app only needs to hold something temporarily while it's running, like a value someone just typed or a short session, it can keep that in memory.
But anything kept in memory disappears when the app restarts or shuts down. So the moment your data needs to survive past the current session, you need a database.
Types of databases
You've probably heard names like MySQL, PostgreSQL, and MongoDB.
In reality, there are two main types: relational and non-relational. You'll also see them called SQL (relational) and NoSQL (non-relational).
Today, I want to focus on relational databases, since that's what most of you are working with.
But in two words, what's the difference?
Relational databases organize data into strict, structured tables, with clearly defined connections between them.
Non-relational databases are more flexible. Instead of strict tables, they store data in formats like JSON-style documents. We'll save that one for another day.
Why relational databases (and what ACID means)
So why use a relational database?
Because it protects data integrity. That matters a lot in industries like finance, banking, healthcare, supply chain, and inventory, where wrong or missing data has real consequences.
How does it protect integrity? It follows a principle called ACID.
I don't know why every tech term has to be this hard to remember. So here's my translation:
๐น Atomic (ALL OR NOTHING)โ
It processes the whole transaction or none of it. If something interrupts it at 99%, it cancels everything out.
๐น Consistent (STRICT RULES ONLY)โ
It follows the rules you set. If you say a Name column can't contain numbers, no one can sneak numbers into it.
๐น Isolated (NO CUTTING IN LINE)โ
If several updates hit the same data at once, they're handled in order, one after another, so they don't trip over each other.
๐น Durable (STAYS SAVED)โ
Once it's saved, it stays saved. Even if the server crashes and comes back later, your data is still there.
Let's create one
Now that you can see why relational databases are so useful, let's create one.
I'll walk you through it in a few simple steps, and we'll run some basic queries together.
We'll use Supabase. It's a Backend-as-a-Service platform, basically an open-source alternative to Firebase, and it gives you a free PostgreSQL database to play with.
Two quick notes before we start:
โ The free tier needs no credit card.
โ Free projects pause after 7 days of inactivity. If you come back later and yours looks asleep, just log in and unpause it. Nothing is lost.
๐น Step 1: Create your Supabase account
Go to supabase.com and sign up. Signing in with GitHub or Google is the fastest way.
Then click New project. Give it a name, set a database password (save it somewhere safe), pick a region close to you for speed, and create.
Provisioning takes about two minutes.
๐น Step 2: Create a table
Grab the table code from the Notion file. (I know it's annoying to open another doc just for the code. I tried having it in the newsletter and it looked terrible.)
Open the SQL editor, you will find it on the left pane. Paste the code and run it. It creates the table and adds five sample tickets.
Code:
Result (you can check it out in the Table Editor view, left pane):
A few notes on tables:
A table is just structured data, like a spreadsheet.
โ
Each row is one record, and each column is one piece of information about that record.
For this exercise, we'll create a simple tickets table, like an IT help desk would use. Each row is one support ticket, with columns for its title, status, priority, who it's assigned to, and when it was created.
You'll also see something called a primary key on the id column.
A primary key is the unique label for each row. No two rows can share it, so the database always knows exactly which record you mean. Think of it as the ticket number: every ticket gets its own, and there are never duplicates.
โ
โ๐น Step 3: Run your first queries
All five queries are in the Notion file with copy buttons. Here's what each one does, and what you'll get back.
Query 1: Read everything
โโ
โselect * from tickets;
โโ
select means "show me." The * means "all columns." So this reads the whole table. That's it, that's a query.
โ
Query 2: Pick columns
โ
โselect title, status from tickets;
โ
Instead of *, you name the columns you want. Now you get just those two. Same data, but filtered to what you need.
Query 3: Filter rows
โ
โselect * from tickets where status = 'open';
โ
where keeps only the rows that match a condition. Query 2 chose which columns to show. This chooses which rows. Only the open tickets come back.
Query 4: Sort
โ
โselect * from tickets order by created_at;
โ
order by sorts the result. Here, oldest first. Add desc to flip it (order by created_at desc).
โ
โQuery 5: Countโ
โ
select count(*) from tickets;
โ
count(*) doesn't list rows, it counts them and gives you one number. This is the first time a query returns a calculation instead of raw data.
Download the full code
I put everything in one Notion page: the table setup and all five queries, each with a copy button so you can paste straight into Supabase.
โ[NOTION LINK]โ
โ