RLS Policies Migration

Row Level Security (RLS) is one of the most important security features in Supabase. It controls which rows individual users can read, insert, update, or delete. The RLS Policies component ensures these rules travel with your database when you migrate.

What Gets Migrated

When you select the RLS Policies component, Stack2X copies:

• Policy definitions -- Every RLS policy attached to your tables, including the policy name, the operation it applies to (SELECT, INSERT, UPDATE, DELETE), and the SQL expression that defines the rule.
• Enabled/disabled state -- If RLS is enabled on a table, it will be enabled on the destination. If a table has RLS disabled, that state is preserved too.
• Permissive and restrictive policies -- Both policy types are migrated. Stack2X preserves the exact behavior you configured on the source.

Plan Availability

RLS Policies migration is included on all plans, including the Free tier. Every Supabase project should have proper RLS configured, so Stack2X makes this available to everyone.

Tips and Considerations

• Migrate schema first. RLS policies are attached to tables, so the Database Schema component should be included in the same migration or run beforehand. Stack2X handles this ordering automatically when both components are selected.
• Review policies after migration. If your RLS policies reference specific user IDs, roles, or helper functions, double-check that those exist on the destination instance. A policy referencing a function that does not exist will cause errors.
• Auth dependency. Many RLS policies use auth.uid() or auth.role(). These functions are built into Supabase and work automatically on the destination. However, if your policies reference custom claims or metadata, make sure the Auth Users component is also included in your migration.
• Testing access. After migration, test your application's read and write operations as different user roles to confirm that RLS policies behave as expected on the new instance.