All posts

February 6, 2026 · 5 min read · The Sherpsy team

Row-level security, explained at the kitchen table

Any product serving many households faces the same question, and it is the one that matters more than every feature combined: what stops one family's data from appearing in another family's app.

The usual answer is a filter, and filters get forgotten

Most systems handle this in application code — every query carries a clause restricting it to the current household. It works right up until somebody writes a new query and forgets the clause. There is no error, no test failure, nothing red. The feature works. It just returns more than it should.

Push the rule down to the data

The database can enforce it instead. A policy attached to each table says which rows a given user may see, and the database applies it to every query whether or not the developer remembered. A forgotten clause returns nothing rather than everything, which is the correct direction for that failure to point.

Application-level checks still exist on top of that — defense in depth is real — but they are the second line. The primary control lives where the data lives.

A security boundary you can forget to type is not a boundary. It is a habit.

Give the household one place to look.