Practice vocabulary for multi-tenant data isolation: row-level security, tenant_id filtering, schema-per-tenant, data residency, and tenant data export.
0 / 5 completed
1 / 5
A PostgreSQL feature that automatically restricts which rows a user can see or modify based on their session identity is called:
Row-level security (RLS) enforces tenant isolation — when RLS is enabled, every query is automatically filtered so a tenant can only access their own rows.
2 / 5
The defensive practice of including a tenant identifier in every database query to prevent cross-tenant data access is described as:
The query always includes the tenant_id filter — even if RLS is in place, explicitly filtering by tenant_id in application code provides defense-in-depth.
3 / 5
A multi-tenancy model where each tenant has their own isolated set of database tables within the same database instance is called:
The tenant gets their own schema in the database — schema-per-tenant provides strong isolation (no shared tables) while using less infrastructure than database-per-tenant.
4 / 5
The requirement that a tenant's data is stored and processed only within a specific geographic region is called:
Data residency per tenant vocabulary includes phrases like 'This tenant requires EU data residency', 'Data is stored in AWS eu-west-1', and 'We have a data processing agreement for this region'.
5 / 5
When a tenant requests a full export of all their data from the SaaS platform, this is described as:
The tenant can request data export for their data only — isolating tenant data enables compliant exports; it also satisfies GDPR's right to data portability.