The short answer
Supabase is a backend platform built on a full Postgres database, with authentication, file storage, realtime and edge functions around it. It suits AI built products because it gives a real database with row level security, so permissions live in the database itself instead of in code that changes every day.
What Supabase is
Supabase’s documentation says every project gets a full Postgres database, not an abstraction over one, that extensions such as pgvector for embeddings and pg_cron for scheduled jobs can be added, and that Auth, Storage, Realtime and Edge Functions are built on top of that database.[1]
That is why U3 Academy teaches it in the coding track. A coding agent writes SQL and understands Postgres well, the product gets a real database with relations, constraints and functions instead of a simple data store, and everything from sign in to files sits in one place. And because the database is standard Postgres, the product stays portable if needs change one day.
Row level security
Supabase recommends enabling row level security on every table in a schema exposed to the API, explains that once enabled no data is reachable through the API with the publishable key until policies are created, and that the secret key works through the service_role role, which bypasses this protection and must never be used in the browser.[2]
And the PostgreSQL documentation itself states that a table with row security enabled and no policy gets a default deny, so no rows are visible or can be modified.[3]
Designing the database
The working order in the U3 Method:
- Data model from the requirements document: tables, relations and the owner of every row.
- RLS enabled on every table with default deny.
- One policy per role and per allowed case.
- Every schema change is a migration file in one sequence, not a click in the dashboard.
- Seed data for development and testing.
- Testing policies with at least two different accounts.
Keys and the server
The rule is simple: the publishable key goes to the browser and is subject to every policy, and the service key stays on the server only, used for specific jobs such as receiving payment notifications, scheduled tasks and special admin work. It never appears in a component that runs in the browser, nor in the code repository.
Important transitions
Simple operations on the user’s own rows, such as their notes and favourites, run through the user’s client so policies apply automatically. Transitions that matter, such as confirming an order, granting access to paid content or issuing a certificate, go through functions inside the database that check authorization in SQL itself, so no interface code can bypass them.
Search by meaning
The pgvector extension stores embeddings alongside ordinary data, and it is the foundation of an assistant that answers from the product’s own content. The rule at U3: search by meaning respects the same permissions, so an assistant never retrieves a passage from content the user is not entitled to see.
From U3’s work
U3 Academy’s data model is written as one migration sequence on Postgres, with row level security enabled on every table under default deny. Students read only their own rows and published content, paid lessons go through an access function in the database, and orders and entitlements go through functions that enforce authorization. Development and testing run against a full local Supabase stack.
Example
A booking app for a salon: tables for customers, services, appointments and staff. A customer reads only their own appointments and creates one for themselves, a staff member reads today’s appointments in their branch, and management handles services and prices. Payment confirmation arrives as a signed notification from the payment provider to a server function, and only that function changes an appointment to confirmed.
Sign in and files
Sign in for a real product is more than an email and password screen: email confirmation, password recovery, external accounts when needed, and management of sessions and devices. Every database row links to the user id this service produces, so policies are written in one language: does this row belong to this user?
Files follow the same logic: storage buckets by purpose, private by default, accessed through temporary signed links, with file type, size and extension checked on upload. A public avatar is one thing; a homework file or a client document is something else entirely.
And the last rule: development and testing happen on a local copy or a separate environment, never on the production database. Migrations are tried locally first, then applied to production after review, and no column holding real data is dropped without a backup and rollback plan.
Where to start
Claude Code for Real introduces Supabase and row level security fundamentals, and The Complete Product goes deep into the database, auth, storage, policies, admin dashboards and payments. Anyone new to databases starts with Building Foundations.
Common mistakes
Mistake: Tables without RLS.
Fix: RLS on every table from day one, with default deny.
Mistake: The service key in the frontend.
Fix: On the server only, for specific jobs.
Mistake: Changing the schema by clicking in the dashboard.
Fix: Every change is a migration file in one sequence.
Mistake: Policies nobody tested.
Fix: Test with two accounts: the first never sees the second’s data.
The course that teaches this
Building Foundations
Understand how a product works, simply, write the brief before the code, and ship a real landing page in an hour.
Frequently asked questions
Sources
Every bracketed number on this page points to one of these sources. All are published, with the date we last checked each one.
- 1Database overview
Supabase · Accessed 4 October 2026
- 2Row Level Security
Supabase · Accessed 4 October 2026
- 3Row Security Policies (PostgreSQL 18 documentation)
The PostgreSQL Global Development Group · Accessed 4 October 2026