Supabase is an open-source backend platform built on Postgres. It gives you a database, authentication, file storage, and auto-generated APIs, so you can build a full-stack app without setting up and managing your own server.
What it is good at: small to medium apps. User sign-up and login, saving user data, storing uploaded files, and building dashboards or internal tools are all straightforward. Because it is built on Postgres, you are learning real SQL and a real database, not a closed system you cannot leave.
How to use it well:
- Start with the table editor. Create one table, add a few rows by hand, and see how the data looks before you write any code.
- Turn on Row Level Security early. By default you must write policies that say who can read or write each row. Skipping this step is the most common beginner mistake, and it can leave data open.
- Use the built-in authentication first. Email login is enough for most prototypes. Add social login only after the basic flow works.
- Use the generated API from your client code, and keep the service key on the server only. The public key is safe to use in the browser, but the service key bypasses security rules and must never ship in frontend code.
- Test with real users early. Create a second account, log in, and check that each user sees only their own data. That one test catches most permission mistakes.
Limits to know: Supabase handles a lot, but it is not magic. Complex queries, heavy background jobs, and large-scale performance tuning still need real database knowledge. Its free tier has limits on database size and usage, so check those before launching something you expect to grow quickly.
Who is it for? Beginners building their first full-stack app, indie developers shipping a side project, and teams that want a Postgres backend without server setup. It is not a reason to skip learning how databases, authentication, and APIs actually work.
Try this: build a tiny app where a user signs up, saves three notes, and sees only their own notes after logging back in. If that works, you understand the core of Supabase, and everything after that is adding features on a solid base.
Top comments (1)
Nice intro. One thing I'd add to step 2: if a brand-new table throws "permission denied" (42501) even though your policy looks right, check the table's grants first. Supabase checks grants before any policy runs, and it has said that once its change (scheduled from Oct 30) reaches a project, new tables in the public schema need those grants added explicitly before the Data API can reach them.