Households
A household is the unit of data isolation in House. Every product’s data belongs to a household, and the platform guarantees you only ever see your own household’s rows.
How isolation is enforced
Section titled “How isolation is enforced”Isolation is enforced in the database itself, not only in application code. The shared Postgres cluster uses row-level security (RLS) on every tenant table:
- Services connect as roles that cannot bypass RLS. Requests carry the household you resolved, set
as a database session variable (
app.household_id), and every policy filters on it. - Tables are fail-closed: with no household set, a query returns zero rows — never everything.
This means a bug in a product’s query cannot leak another household’s data; the database refuses to return it.
Member-private surfaces
Section titled “Member-private surfaces”Within a household there can be multiple members. Some surfaces are member-private — for
example, things only you should see even inside your own household. These carry a second key
(app.principal_id) so the database enforces per-member visibility on top of per-household
isolation.
Which tables are member-private is declared per product and proven by an automated test that confirms two members of the same household cannot see each other’s private rows.
Backups
Section titled “Backups”Backups are taken by a dedicated, offline database role — never by a role used to serve live traffic.
Multiple people in one household
Section titled “Multiple people in one household”Support for multiple people in a single household varies by product today. See each product’s page for its current status: