Guide

How to add a database to your project with Supabase

A browser-only guide to giving a Claude Code project a place to store and share data.

Oct 19, 2026

Once a project is online, the next thing it usually needs is memory. A way to save what someone types, remember who they are, or show the same list to everyone who visits. That is what a database is for.

This guide picks up where publishing a site with Claude Code left off. It assumes you already have a project on GitHub, built with Claude Code, and deployed on Vercel. Here you add a database with Supabase, still entirely in a browser. You connect Supabase to Claude so it can do the setup directly, and you review and confirm each step.

Supabase is the database I use and understand, so it is the one I can walk you through honestly. Other tools fill the same role.

When a project needs one

You can build plenty without a database. Add one when the project needs to:

  • Remember something across visits, not just while the page is open.
  • Share information between different people, not just show it back to one.
  • Hold accounts, submissions, bookings, votes, saved items, messages, or anything else that has to persist.

If the project only displays content you wrote into it, you do not need a database yet. Add it the first time something has to be saved.

Supabase · the database

Supabase gives you a database, plus tools for sign-in and file storage, all reachable from a browser.

  1. Go to supabase.com and create an account.
  2. Choose New project. Pick the organization, give it a name, and select a region close to the people who will use it.
  3. Set a database password when prompted. Save it in a password manager. You rarely type it by hand, but you do not want to lose it.
  4. Create the project and wait a minute while it provisions.

You now have a database. The next steps connect it to your project.

Connect Supabase to Claude

Rather than carrying setup between Supabase and Claude by hand, connect the two so Claude can build and manage the database directly. Supabase offers an MCP connection for exactly this.

  1. Follow Supabase's MCP connection instructions to link your Supabase project to your assistant. The steps differ a little by assistant and change over time, so use Supabase's current guide.
  2. Back in your Claude session, confirm it worked: ask Claude whether it can see your Supabase tools. It should be able to list your project before you ask it to change anything.

This is a one-time connection. Once it is in place, Claude can create tables, apply changes, and check security rules for you, so you never copy setup back and forth by hand. You stay in the loop by having Claude explain each step in plain terms and confirming it before it runs.

Tell Claude what to store

You do not design the database yourself. You describe what the project needs to remember, and Claude turns that into a structure.

In your Claude Code session, describe the data in plain words: what kinds of things the project saves, and who should be able to see or change each kind. A message like this is enough:

I'm adding my connected Supabase database to this project. Here is what it needs to store: [describe each kind of thing, for example "a signup has a name, an email, and the date it was submitted"]. Explain who should be able to read and who should be able to change each kind of data. Design the tables and the access rules, show me the plan in plain terms, and wait for me to confirm before you apply anything.

Claude will propose the tables and the access rules. Read the explanation. You do not need to know the details, but you should understand, in plain terms, what gets stored and who can touch it.

Apply the setup

Once you have confirmed the plan, tell Claude to apply it. With the connection in place, it creates the tables in your Supabase project directly. Then check the result yourself: open the Table Editor in Supabase and confirm the tables are there.

If anything looks wrong, tell Claude what you see and it will fix it.

Lock down who can read and write

This is the step that protects your users, so do not skip it.

Your project talks to Supabase from the browser using a key that is meant to be public. On its own, that key could read or change anything. What keeps data safe is Row Level Security. Once you turn it on for a table, Supabase denies all access until you write rules that say exactly who may see or change which rows. Until you turn it on, a table is open.

Ask Claude to set this up and to check its own work:

Turn on Row Level Security for every table, and write policies that match the access rules we agreed on. Apply them, then confirm there is no table left open and tell me how I can verify it myself in Supabase.

Because Claude is connected to the database, it can apply the rules and then query the project to confirm none are missing. Still look yourself: in Supabase, every table should show that Row Level Security is enabled. If a table is open, anyone who finds your public key can read or change it.

Connect the keys

Claude can set up the database, but your deployed site still needs two values to reach it at runtime: the project URL and the public key.

  1. In Supabase, open Project Settings → API. Copy the project URL and the publishable key. (Older projects call the public key the anon key.)
  2. In Vercel, open your project → Settings → Environment Variables. Add them with the names Claude asks for, usually NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY.
  3. Redeploy so the new values take effect.

The publishable key is safe in the browser. Supabase also has a secret key with full access that bypasses your security rules. It must stay in server-side code only, never in the browser and never in the repository. If you are unsure where a key is used, ask Claude to check before you deploy.

What it costs

Supabase has a Free tier that covers a personal project. Two things to know:

  • A free project pauses after about a week with no activity. You restore it from the dashboard in a click.
  • The free limits are generous for getting started. Check them when the project becomes something people depend on.

Appendix · useful next steps

Keep the secret key out of the browser

Before any deploy, it is worth one check: the publishable key may appear in client code, the secret key must not. Ask Claude to confirm where each key is used.

Back up what matters

Once real data lives in the database, know how you would get it back. Supabase can export a table or the whole database from the dashboard. Do this before any large change.

Let the structure follow the need

You do not have to design the whole database up front. Add a table when the project needs to remember a new thing, the same way you added the first one. Describe the need, let Claude shape and apply it, and check the result when it works.