Working with Supabase

The mental model for Supabase in Layout — schema, migrations, auth, storage, and bringing your own project.

Supabase is the backend Layout reaches for when your app needs persistence, users, or files. This page explains how the pieces fit together so you know what to expect when you prompt for data features.

Why it matters

A lot of confusion in AI building comes from not knowing where the backend lives. In Layout, the backend is a Supabase project: a Postgres database, an auth service, and an object store. When you ask for "a login page" or "save this to the database," the AI writes code that talks to Supabase. Knowing that shape makes every follow-up prompt sharper.

The four pieces Layout uses

Supabase is several services. Layout uses four of them.

1. Database

A Postgres database. Every table lives in the public schema unless Layout has a reason to put it elsewhere. The AI writes SQL migrations to create tables, add columns, and set up relationships.

2. Auth

Sign-up, sign-in, password reset, and session tokens. Layout generates UI that calls Supabase Auth directly. User identities live in the auth.users table, which your public tables reference by user_id.

3. Storage

An S3-compatible object store for files — avatars, uploads, generated images. Layout creates buckets and wires up uploads when you ask for them.

4. Edge functions

Server-side TypeScript that runs close to your database. Layout reaches for edge functions when the work is sensitive (API keys, webhooks, payment calls) or needs to run outside the browser.

How a data feature becomes a migration

When you ask Layout to add something that needs persistence — "let users save notes," "track completed tasks" — the AI splits the work in two steps.

Propose a migration. The AI writes the SQL to create or change the schema and shows it to you. Nothing runs until you approve.
Write the code. Once the migration is applied, the AI wires up the UI, queries, and mutations against the new schema.

You always see the SQL before it hits your database. If it looks wrong, reject it and re-prompt with corrections.

Migrations and code live in separate runs. That is why you sometimes see Layout pause after proposing a migration — it is waiting for your approval before writing any code that depends on the new schema.

Row-level security is on by default

Supabase's default posture without policies is "nothing is accessible." Layout enables Row Level Security (RLS) on every table it creates and writes policies for the common cases:

Users can only read their own rows
Users can only insert rows tied to their own user ID
Users can only update and delete their own rows

If you want a table to be publicly readable — a blog, a product catalog — ask for it explicitly. RLS will not grant public access unless a policy says so.

User profiles and the `auth.users` link

Supabase does not expose the auth.users table through the API. When you want to store profile fields — name, avatar, roles — Layout creates a profiles table in the public schema with a foreign key back to auth.users. A trigger copies the new user's ID into profiles on sign-up so the row is there when you need it.

If you ever prompt for "a users table," expect Layout to create a profiles table instead. That is the right pattern.

Storage, in one paragraph

When your prompt involves uploads, Layout creates a Supabase Storage bucket and writes client code to sign and upload files. Public read access on a bucket is opt-in — ask for it if avatars need to be viewable without a login.

Edge functions, in one paragraph

When your prompt needs to hide a secret or call an external API — Stripe, OpenAI, a webhook — Layout writes a Supabase edge function. Secrets live in Supabase's secret manager, not in your code. You set them once in the Supabase dashboard; the function reads them at runtime.