Your database is where all your data lives. It's the one thing that's hardest to change later.
If you've used a spreadsheet, you can understand a database. A database is rows and columns, just like Excel. The difference is that a database can handle millions of rows without slowing down, enforce rules about what goes in each column, and connect tables to each other.
RESTAURANT: Your database is your reservation book, your inventory list, your employee schedule, and your customer feedback cards — all in one system. Instead of separate notebooks scattered around the restaurant, everything lives in one place where any station can look it up instantly.
DEF: Table — One collection of related data. A "users" table has one row per user. A "conversations" table has one row per conversation. Each column in the table holds one type of information: name, email, date created.
DEF: Row — One record. One user. One conversation. One payment.
DEF: Column — One attribute. Name, email, subscription tier, last active date.
Every product needs a core set of tables. Here are the ones you'll create on day one:
users — One row per user. Their name, email, when they signed up, their subscription status, their settings.
subscriptions — One row per subscription. Links to the user, tracks the plan, the start date, the renewal date, whether it's active.
activity — One row per user action. What they did, when they did it, how long it took. This is your analytics foundation.
Start small. You can always add tables later. You cannot easily merge two tables that should have been one from the beginning.
This is the most important security concept for solo founders using Supabase.
DEF: Row-Level Security (RLS) — A rule that controls which rows a user can see or modify. Without RLS, any authenticated user can read every row in your table. With RLS, users can only access their own data.
Turn on RLS for every table. Write policies that restrict access to the row's owner. This is non-negotiable. One missing RLS policy means any user can read any other user's data.
Never modify your production database directly. Instead, write the change as a migration — a script that describes what to add, change, or remove. Test the migration in your sandbox first (Chapter 7). Then apply it to production.
Supabase includes automatic daily backups on the Pro plan. But backups you don't test are backups that might not work. Once a month, verify you can restore from a backup. The time to discover your backup process is broken is not during an emergency.
NOTE: The most dangerous database operation is a DELETE without a WHERE clause. It deletes every row in the table. Always write your WHERE clause first, then add the DELETE. Always run it in sandbox first. Always.