What is a Supabase project?

What a project is

Supabase is a hosted platform built around PostgreSQL. When you create a project, Supabase provisions a Postgres database for it and runs a set of services next to it, all reachable at an address like your-project-ref.supabase.co. The database is a full Postgres instance: tables, views, functions, triggers, extensions and row level security. Around it, Auth handles accounts, passwords, email links and sign in with providers such as Google. Storage holds files in buckets with their own access rules. A REST and GraphQL API is generated from the database's tables, so a browser or app can read and write without a custom server. Edge functions run small pieces of server code, and Realtime can push changes to connected clients. Projects live inside an organisation, which is where billing and team members are set, and each organisation can hold several projects.

How the pieces fit

A browser app talks to a project with two pieces of information: the project's address and a public key, called the anon or publishable key. That key is meant to be in the browser; it identifies the project, not the person. When someone signs in, Auth gives them a token, and every request then carries both. The database's row level security policies read that token to decide which rows the person may see or change. That is the core design: the public key opens the door to the API, and the policies decide what is inside each room. A second, secret key, the service role key, skips every policy and must stay on servers only. Storage works the same way, with policies on the objects table deciding who can upload, read or delete each file. Because it is all Postgres underneath, the data can be dumped and restored like any other Postgres database.

When a site needs its own project

Any site that stores what visitors do, such as bookings, orders, members, messages or saved items, needs a database somewhere, and a Supabase project is one common answer because the browser can use it directly with sign in and storage included. Owning the project yourself matters when you want the data under your own account and billing, want to see the tables in Supabase's dashboard, or plan to connect other tools to the same data later. One project can serve several apps, such as a website and a phone app reading the same bookings, which is often the point. Supabase offers a free plan with limits on the number of active projects and on resources, and pauses free projects after a period without activity, so a site that must stay up for real customers usually belongs on a paid organisation once it matters to the business.

Common mistakes

Putting the service role key in front end code, which hands every visitor full access to the database. Creating tables without row level security, so the public key can read them. Assuming the anon key is a password and rotating it in a panic, when the real fix is a missing policy. Letting a free project pause before launch day. Keeping one project for development and live customers, so a test migration changes real data. Not noting which organisation owns the project, then losing access when the person who created it leaves. Storing confidential files in a public bucket. And forgetting that Auth users belong to the project: two sites sharing one project share one list of accounts, which may or may not be what you want, so decide that before the first person signs up rather than after.

Where it shows up in OneCraft

When a site's features need data, the AI enables a database for it. By default that is a schema of its own in OneCraft's pool project, reached by a login that can reach no other site; every plan includes one such hosted database. The owner can instead connect their own Supabase account, and the site's tables are then created in a project on that account. Either way every table has row level security, checked by the AI as an anonymous visitor and as a signed in person, and the migrations and a schema.sql file are written into the site's code. Two storage buckets are set up for the site: site-files, public, up to 10 MB a file, and site-private, read only through the site's own rule, up to 25 MB a file. Visitor sign in uses Supabase Auth.

Questions people ask