RLS Policies

The RLS (Row Level Security) component copies the row-level access policies from your tables.

What Is RLS?

Row Level Security is a PostgreSQL (and Supabase) feature that controls which rows a user can view or modify in a table. For example:

  • "A user can only see their own orders"
  • "Only admins can modify settings"
  • "Public data is readable by everyone"

What Is Copied

For each RLS policy:

  • Name of the policy
  • Table it applies to
  • Operation — SELECT, INSERT, UPDATE, DELETE, or ALL
  • Role targeted (e.g. authenticated, anon, service_role)
  • USING expression — read condition
  • WITH CHECK expression — write condition
  • RLS status of the table (enabled/disabled)

Example

A policy like:

CREATE POLICY "Users can read own data"
  ON profiles
  FOR SELECT
  USING (auth.uid() = user_id);

...will be exactly recreated on the target project.

Re-cloning

During a re-clone, existing policies on the target are dropped and recreated with the definitions from the source. This ensures that the target exactly reflects the source policies.

Interaction with Other Components

RLS policies are cloned after tables and functions, because:

  • Policies reference tables
  • USING/WITH CHECK expressions can call functions

Key Considerations

SituationBehavior
RLS enabled on a source tableRLS is enabled on the target table
RLS disabled on a source tableRLS remains in its current state on the target
Policy using auth.uid()Works if Supabase Auth is configured on the target
Policy with a custom functionThe function must also be cloned (Functions component)

Important: If you clone RLS policies without cloning the functions they use, the policies may fail at runtime. Enable both components together.

Next Steps

PreviousFunctions & TriggersNextEdge Functions