Type Ana into the filter below and watch which rows light up.
select * from orders;
| id | user_id | item | total |
|---|---|---|---|
| 101 | 1 | Running shoes | 89 |
| 102 | 2 | Desk lamp | 34 |
| 103 | 1 | Headphones | 149 |
| 104 | 3 | Coffee grinder | 59 |
| 105 | 2 | Monitor arm | 72 |
The database answered with 5 of 5 rows. A query is a question; the where line is the part that decides which rows count. Your AI writes these for you — this is what it's asking.
You just ran a query: a question to the database. The filter part, "only Ana's", decides which rows come back.
PostgreSQL's tutorial: "To retrieve data from a table, the table is queried." Databases speak a language called SQL.
select * from orders
where user_id = 1;In plain English: give me every column of every order, but only where the owner is user 1. The where part is the filter.
Which rows come back?
Ana's mug (user 1)
- with where user_id = 1
- Returned
- with no where
- Returned
Ana's poster (user 1)
- with where user_id = 1
- Returned
- with no where
- Returned
Ben's mug (user 2)
- with where user_id = 1
- Left out
- with no where
- Returned
PostgreSQL again: "only rows for which the Boolean expression is true are returned." A yes-or-no test, run on every row.
Remove the filter and the answer is every order from everyone. The database isn't being careless; that's what was asked.
That's why Row Level Security exists. Supabase says: "Think of a policy as adding a WHERE clause to every query." A filter nobody can forget.
Try it with the rules off. In the sandbox, delete the filter and run it as a stranger. Every row comes back. Now switch RLS on and run the same filterless query: you get only what the rules allow.
Check yourself
0/3 got itSaved on this device only. No account, no streaks.
Next in where your data lives: Row Level Security, explained.
