What is Supabase, and how does authentication work?

Supabase is a hosted backend for websites and apps: a Postgres database, user sign-up and login, file storage, server-side functions and an automatic API, all managed for you. AI tools like Claude reach for it often because it lets a front-end site save data and sign people in without building a server. It is a strong choice for DIY projects, with one big condition: you must turn on and test Row Level Security, or your data can be readable by anyone.

What Supabase includes

Postgres is a mature, standard database, so your data is not locked into an unusual format. That matters if you later hand the project to a developer or move it.

Does your site need it?

Most marketing sites do not. Ask: does the site need to remember something per visitor, or know who someone is? If not, skip the database and use your host's form handling or an email form service. Fewer moving parts means less to secure and maintain.

Supabase earns its place when you need:

• Logins for customers, members or staff.
• Data people create and come back to (quotes, applications, saved items).
• A directory or listing site where entries live in a database.
• An internal tool or dashboard behind your marketing site.

If what you really need is a store, look at an ecommerce platform first. See DIY ecommerce: why you should probably use a platform.

How authentication works

Authentication answers "who is this person?" Authorization answers "what are they allowed to see?" Supabase handles both, but you configure the second part.

1. Sign-up and sign-in. A visitor creates an account with email and password, a one-time magic link, or a social login through OAuth (Google, Apple, GitHub and others). Supabase stores the account and handles password hashing and reset emails.
2. The session. After sign-in, the browser holds a session token that proves who the user is on each request. The token expires and refreshes automatically.
3. Every request carries the user's identity. When the site asks the database for data, Supabase knows whether the request comes from an anonymous visitor or a signed-in user, and which one.
4. Row Level Security decides what comes back. Policies on each table say, for example, "a user can read and edit only rows where user_id matches their own ID."

You can add multi-factor authentication for users, and you should require it on any admin accounts.

The keys, and the mistake that leaks data

Supabase gives each project two kinds of API key. Per Supabase's documentation:

• Publishable key (and the older anon key): low-privilege and designed to sit in browser code. What it can reach is controlled entirely by your Row Level Security policies.
• Secret key (and the older service_role key): full access that bypasses Row Level Security. It belongs only in server-side code such as Edge Functions or your host's server functions, stored as an environment variable.

The classic DIY failure has two parts: tables created without Row Level Security, and a site that uses the publishable key in the browser. Anyone who opens the browser's developer tools can find that key and query every unprotected table. AI-generated code can produce exactly this if you do not ask for policies. The second classic failure is putting the secret key in front-end code or committing it to GitHub.

A safe setup checklist

1. Enable Row Level Security on every table, including ones you create later. No exceptions.
2. Write a policy for each action (select, insert, update, delete) and each role (anonymous visitors and signed-in users). Default to no access, then open only what is needed.
3. Test as an anonymous visitor. Ask Claude to write a short test that uses only the publishable key and tries to read every table. Anything that returns data should be intentional.
4. Keep the secret key server-side, in environment variables, never in the repository. If it leaks, rotate it immediately.
5. Run Supabase's security advisor in the dashboard and fix what it flags.
6. Turn on two-factor for your Supabase account and limit who has access to the project.
7. Validate inputs on anything users can submit, and add rate limiting or a CAPTCHA on public forms to stop spam.
8. Back up your data. Understand what your plan includes and export important data regularly.

A useful prompt when building with Claude: "Before writing any code that touches Supabase, list every table, its Row Level Security policies, and a test proving an anonymous user cannot read private rows." Our security guide for AI-built websites covers the rest of the stack.

Free tier realities

Supabase's free plan is good for learning and prototypes. Free projects can be paused after a period of low activity, with an email warning first and data retained; paid projects are not paused. A business site that people rely on should be on a paid plan. Add it to your numbers in the website cost calculator.

Supabase vs a CMS

Supabase stores application data. A headless CMS stores content that editors manage: pages, blog posts, images. They solve different problems. If your main need is letting staff update pages, read what is a headless CMS before reaching for a database.

The short version

Supabase gives a DIY site a real database, logins, storage and server functions. Use it only when you need to store data or know who users are, turn on Row Level Security for every table, keep the secret key off the front end, and move to a paid plan before launch. Back to the main guide: how to build your own website with Claude. Need a portal or app built properly? Talk to us.