Builder Toolkit · 10 / 11

Supabase Basics

Decide whether you need a backend, create one table, and understand keys and row level security.

Supabase Basics

What this is

Supabase is a hosted backend. It provides a database, user authentication, and file storage behind one project.

Copy

Frontend = what people see
Backend  = where the data lives

The one idea

Add a backend only when your project must remember something after the page reloads.

Why it matters

Plenty of good projects never need one. A portfolio, a landing page, a menu, a calculator: all frontend only.

Adding a database too early is one of the most reliable ways to stall a build. You end up debugging authentication before you have anything worth logging into.

What to do

Decide honestly whether you need it

Ask one question:

Copy

Does this project need to save data that survives a refresh,
and be visible to someone else on another device?

If no, skip this page. Browser storage covers a surprising amount, and KDBM Lite builds a browser-local app for exactly this reason.

If yes, continue.

Create the project

Create an account at supabase.com.
Create one project.
Save the database password somewhere private, not in your code.
Wait for provisioning to finish.

Start with one table

One table. Resist the schema you imagine you will need in six months.

A contact or booking table looks like this:

Column	Type	Meaning
`id`	uuid	Unique row identifier
`created_at`	timestamp	When the row was created
`name`	text	Who submitted it
`email`	text	How to reply
`message`	text	What they said

If you want AI help designing it, constrain the request:

Copy

I am a beginner using Supabase.

My app needs to save:
[describe the data in plain language]

Suggest ONE table only.
Explain each column simply.
Do not add authentication yet.

Understand the two keys

This is the part that matters most for your safety.

Key	Where it may go	What it does
Anon (public) key	Browser code, `NEXT_PUBLIC_`	Limited access, controlled by row level security
Service role key	Server only, never the browser	Bypasses every security rule

The service role key ignores your rules

It is designed to. That is why it must never appear in frontend code, in a public variable, or in a screenshot. If a tutorial tells you to put it in the browser to fix an error, the tutorial is wrong.

Keep row level security on

Row level security decides which rows a request may read or write. Supabase enables it on new tables, and it is tempting to switch off when something does not work.

Leaving it off means anyone holding your public key can read your whole table. Write a policy instead of disabling the rule.

Do this now

Open your Supabase project and find Project Settings, then API. Look at the two keys and say out loud which one may go in browser code. If you hesitate, reread the table above.

Check yourself

I can explain why my project needs a backend, or I skipped this page.
I have exactly one table so far.
I know which key is safe for the browser.
Row level security is still on.
My keys are in .env.local, which Git ignores.

Connect it

Terminal command

npm install @supabase/supabase-js

Swipe sideways if a command is long.

Then add the values locally and on your host, following Environment Variables.

If queries return nothing

Empty results with no error usually mean row level security is doing its job and no policy allows your request. That is a policy to write, not a rule to disable.

Common mistakes

Adding a backend before the frontend works.
Building five tables before saving a single row.
Starting with authentication instead of one simple table.
Disabling row level security to make an error go away.
Putting the service role key anywhere near browser code.
Setting keys locally and forgetting the host, so the live site fails.

Next step

Data sorted. If people need to sign in, continue to OAuth Basics.