You built an app with Claude Code, it shows up on screen, it works, and then you refresh the page: everything is gone. That's normal — your data was living in the browser's memory. For an app to hold on to its users' information, it needs a database. Supabase is currently the most beginner-friendly option out there: a hosted PostgreSQL database, an automatically generated API, user account management, and a free plan that's more than enough for a first project.
In this guide you'll see three ways to add that database to your project: learning in a guided setting where the tools are already set up for you, building it by hand in the Supabase dashboard, or letting Claude Code write your schema itself through a controlled connection. You'll also see the serious alternatives (Firebase, Airtable, SQLite) and the five mistakes that leak beginners' data. No prerequisites: if you know how to install an app, you can follow along.
What a database changes in your app, and what Supabase does
A database is where your app writes down whatever has to survive closing the tab: accounts, orders, messages, uploaded files. Without one, you've got a mockup that reacts nicely but forgets everything.
Vibe coding means describing in plain English what you want and letting an agent like Claude Code write the code for you. It works remarkably well for the interface: buttons, forms, layout. Where it often stalls is storage, because that's where you have to make real decisions: which tables, who's allowed to read what, how to change the structure later without breaking what already exists.
Supabase bundles all those answers into a single project. Behind the interface, it's PostgreSQL — a database that's been running in production for over thirty years — with extra layers built on top.
| Supabase piece | What it's for | Something you already know |
|---|---|---|
| Database (PostgreSQL) | storing your tables and their relationships | an Excel workbook, but with strict rules |
| Auth | sign-up, login, forgotten password | the "Sign in with Google" button |
| Storage | images, PDFs, videos | a Drive attached to your app |
| Realtime | instant screen updates | seeing other people's cursors in a shared doc |
| Auto-generated API | talking to the database from your code | the server you don't have to write |
In practice: you create a taches table, and Supabase immediately hands you the endpoints to read, add, update, and delete rows. You don't write a server. That's what makes the tool such a good fit for vibe coding. The official Supabase database documentation is still the reference to keep open in a tab.
Method 1: build your database in a guided setting with Skilzy
When you're starting out, the fastest route is learning schema design and security while you build, with the tools already installed and paid for.
Skilzy is a French e-learning platform for learning and using AI. It has more than 15 programs: creating images, videos (UGC, ads, faceless channels, avatars, voiceovers), music, automating with n8n, writing good prompts, coding with AI. The thing that really changes the game for a beginner is the built-in AI Lab: you use the real tools directly inside the platform, credits included, without piling up €20-a-month subscriptions.
For the part you care about here, the program on building an app with Claude Code takes you from a blank page to an app that saves real data. What you walk away with, applied to your database:
- a schema you actually understand, with the right column types and real relationships between tables, instead of a pile of
textcolumns - security rules (Row Level Security) written and tested, so one user can't read another user's rows
- clean handling of API keys and environment variables, the number one source of data leaks among beginners
- an instructions file that keeps the agent on track going forward, as explained in our guide to the CLAUDE.md file
Two state-recognized certifications eligible for funding are also available: RS7439, AI-assisted content marketing, and RS6792 on AI and sales. Handy if you want your learning to leave a mark on your résumé or to be covered by a funding scheme.
There's also a B2B offer for training organizations that want to add these programs to their catalog.
Method 2: build your database by hand in the Supabase dashboard
It's free, it takes about fifteen minutes, and it's the method to know even if you end up handing the work to AI. You can't check what an agent is doing to a database whose workings you don't understand.
- Create your project. On supabase.com, sign in with GitHub, then hit "New project." Pick a region close to your users (Paris or Frankfurt for a European audience — it's worth tens of milliseconds on every request). Save the database password in your password manager: it won't be shown again.
- Create your first table. Two paths: the "Table Editor," which looks like a spreadsheet, or the "SQL Editor," which is faster as soon as you know what to write. Here's an example for a to-do list tied to users:
create table public.taches (
id uuid primary key default gen_random_uuid(),
created_at timestamptz not null default now(),
user_id uuid not null references auth.users (id) on delete cascade,
titre text not null,
terminee boolean not null default false
);
- Turn on row-level security. Without this step, anyone who has your public key can read the whole table. Supabase enables RLS by default on tables created through the interface, but not always on tables created in SQL. Check, then write your rule:
alter table public.taches enable row level security;
create policy "chacun voit ses taches"
on public.taches for select
using (auth.uid() = user_id);
In plain English: a logged-in user only sees the rows whose user_id matches their own ID. You'll need an equivalent rule for insert, update, and delete.
- Grab your keys. Under "Project Settings," then "API," you'll find the project URL and two keys. The public key (
anon) can live in your front-end code. Theservice_rolekey bypasses every security rule: it must never leave your server, and never show up in a Git repository. - Wire it into your code. Install the official library with
npm install @supabase/supabase-js, put your keys in a.env.localfile that Git ignores, then:
import { createClient } from '@supabase/supabase-js'
const supabase = createClient(
process.env.NEXT_PUBLIC_SUPABASE_URL,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY
)
const { data, error } = await supabase
.from('taches')
.select('*')
.order('created_at', { ascending: false })
On the budget side: Supabase's free plan covers two active projects, roughly 500 MB of database space, and 50,000 monthly active users as of this writing. Free projects get paused after a week of inactivity, which catches a lot of beginners off guard — you just restart them from the dashboard. Check the pricing page before building a business on top of it, since these thresholds change.
Method 3: let Claude Code write your schema with the Supabase MCP server
Claude Code can read your database structure, suggest the tables you're missing, and write the migration files itself — as long as you give it controlled access.
MCP (Model Context Protocol) is the standard that lets an agent talk to an outside tool. Supabase publishes an official MCP server. Installing it takes one command:
claude mcp add supabase -e SUPABASE_ACCESS_TOKEN=ton_token -- npx -y @supabase/mcp-server-supabase@latest --read-only --project-ref=ton_ref
The --read-only is deliberate: you start read-only, long enough to confirm the agent understands your database. You can drop it later if you need to. If this part is new to you, our tutorial on connecting Claude Code to your tools with MCP walks through every step, including creating the personal access token.
From there, you work in plain language: "Look at the taches table in Supabase, add a projets table with a title and a color, link each task to a project, and write the migration." The agent reads the existing structure, proposes the SQL, and you approve it.
For changes, use the Supabase CLI rather than typing SQL by hand in the interface. Your changes become version-controlled files, which means they're reversible:
npx supabase init
npx supabase link --project-ref ton_ref
npx supabase migration new ajout_table_projets
npx supabase db push
A CLAUDE.md file at the root of the project prevents 80% of accidents. Three lines are enough: "Every schema change goes through a migration in supabase/migrations. RLS is mandatory on every new table. Never use the service_role key on the client." For the rest of the day-to-day habits, keep the essential Claude Code commands within reach.
The five mistakes to fix before you ship your app
- RLS turned off on a public table. Your
anonkey is visible in the browser's code. Without RLS, the whole table is readable by anyone. - The
service_rolekey in the front end. It ignores all your rules. It stays server-side, period. - The
.envfile pushed to GitHub. Check your.gitignorebefore the first commit. A published key has to be revoked, not just deleted from the repo. - Schema changes made only by hand. With no migration, you can't roll back or recreate your database anywhere else.
- Approving the agent's SQL without reading it. A
drop tableslipped into a migration is irreversible on the free plan, which doesn't include point-in-time recovery.
The alternatives to Supabase, and when they're the better fit
Supabase isn't the only choice, and on some projects it isn't even the best one. Here are the options that hold up.
| Option | Its strength | Its limit | Who it's for |
|---|---|---|---|
| Supabase | standard PostgreSQL, plain SQL, generous free plan | you have to understand RLS | web or mobile app with user accounts |
| Firebase (Google) | very fast to get going, excellent on mobile | non-relational database, complex queries are painful, bill hard to predict | mobile prototype, push notifications |
| Airtable | instant spreadsheet interface, perfect with n8n | slow past a few thousand rows, expensive per user | internal tool, content management, automations |
| SQLite or Turso | single file, zero network latency, zero config | no built-in authentication, backups are on you | solo project, local tool, desktop app |
| Google Sheets | you already know how to use it | it isn't a database, it buckles fast | throwaway mockup, testing an idea for a week |
A simple rule to decide: if your app has user accounts and data that cross-references (a user, their projects, their tasks), go with Supabase. If you're building an internal tool driven by automations, Airtable will save you hours. If you're making a small local utility, SQLite is plenty and will never cost you a cent.
Your next step
Open a Supabase project, create a single table with four columns, turn on RLS, write one read rule, and wire it into your app. One hour, no more. That first complete loop is what unlocks everything else: from there, every new table is just a repeat of the same moves.
If you're still unsure what order to learn things in, our guide on where to start with AI gives you a clear path.