Databases 101
Why your app forgets everything — and the spreadsheet-that-lives-with-your-app that fixes it.
What a database actually is
A spreadsheet your app can read and write. That's genuinely the mental model: tables are the sheets, rows are the entries, columns are the fields. When someone submits your form, your app adds a row. When you want to show submissions, your app reads the rows back.
The key property: it's memory that lives with the app, not the browser. Anything stored in the browser (like the Life Board's habit checks) exists on that one device only. A database row exists for every visitor, on every device, forever — until you delete it.
The vocabulary
Four words
- table — one kind of thing you store — ideas, orders, signups
- row — one entry in a table — a single submitted idea
- column — one field every row has — idea, email, created_at
- query — a request to read or change data — written in SQL
💡 tipSQL is the language queries are written in. You don't need to learn it — Claude writes it, you paste it. Being able to recognize“this creates a table” is plenty.
Where it lives
Not inside your app. A database is a separate always-on service your app talks to over the internet — I use Supabase, which is hosted Postgres (the world's most battle-tested open-source database) with a friendly dashboard on top. Your app connects using two values: a project URL and a key. Those live in environment variables, not in your code.
Because the database is separate, one database can serve all your apps — my portfolio, guide gate, and idea form all share one Supabase project, each with its own tables.
How you'll actually use it (with Claude Code)
You describe what to remember; Claude writes both halves — the app code and the SQL:
"Save this form's submissions to a Supabase table called
ideas. Write the SQL to create the table — I'll run it in
the SQL Editor."And here's the part that makes it click: open Table Editor in the Supabase dashboard and your data is just… a spreadsheet. Submit a test form and watch the row appear.
Row Level Security — the lock
Your app's publishable keyships to the browser, where anyone can find it. That's by design — and it's safe only because of Row Level Security: rules the database itself enforces about who can see or change which rows. “Users can only read their own rows.” “Nobody can read this table except my server.”
🔒The one rule:
Every table gets RLS turned on. No exceptions, even for “harmless” data. A table without RLS plus a publishable key equals a public spreadsheet. When Claude writes your SQL, the RLS lines are the ones you must not delete.
💡 tipIf a form suddenly errors with something about “policy” or “permission denied,” that's RLS doing its job on an action you haven't allowed yet. Paste the error to Claude — writing the missing policy is a one-prompt fix.