Test Supabase RLS with two users: reads and writes
Use two ordinary user sessions through the API your app uses. Each user should see their own fixture and not the other user’s private row. Then attempt a cross-owner insert and an ownership change: a passing SELECT test says nothing about writes.
What to prepare
Create note-a and note-b under separate test accounts in an isolated project. Use a publishable project key and the relevant user session. Running a query in the SQL Editor as an administrator does not exercise the client’s role.
Verification procedure
Measure row visibility for each identity
Fetch both fixture IDs as A and again as B. Inspect IDs and markers, not just status codes. Two empty result sets might mean missing fixtures, failed authentication or missing privileges rather than successful isolation.
Exercise the proposed row after a write
Try inserting a B-owned row as A and changing an A-owned test row to owner B. Record the error or affected-row count and reread the data. Include a normal own-row operation as a control where writes are intended.
Run the PostgreSQL teaching fixture in a disposable database; it ends with ROLLBACK
psql -X -v ON_ERROR_STOP=1 -d rls_test -f rls-fixture.sqlDecision and limitations
Record SELECT, INSERT and UPDATE separately. Repeat through the actual client after a policy migration with the same fixture users.
What remains unverified
The local SQL exercise simulates identity. It does not test your hosted JWTs, Data API grants, Storage policies or deployment settings.