In a multi-tenant cloud application, multiple distinct client organizations share the same underlying computing or database infrastructure. While shared infrastructure provides operational scalability, it demands rigorous engineering to ensure Tenant A cannot access, modify, or leak records belonging to Tenant B.

Primary Sources: PostgreSQL Global Development Group: Row Security Policies (postgresql.org); NIST Special Publication 800-57 Part 1: Recommendation for Key Management (csrc.nist.gov); GDPR Article 32 (EUR-Lex).

1. Comparing Multi-Tenant Storage Architectures

Software architects evaluate three primary database tenancy models:

Tenancy Model Architecture Description Isolation Characteristics Operational Overhead
Silo Model
(Database-per-Tenant)		 Each tenant receives a dedicated physical or virtual database instance. Substantially lowers cross-tenant bleed risk via process and network boundaries. Higher infrastructure cost; complex schema migration orchestration across multiple instances.
Bridge Model
(Schema-per-Tenant)		 Single database instance hosting isolated PostgreSQL schemas per tenant. Provides schema-level access controls within a shared database engine. Moderate cost; high tenant counts can stress database catalog metadata.
Pool Model
(Shared Schema + RLS)		 Single shared schema with tenant records filtered via PostgreSQL Row-Level Security. Enforced at the query engine level via session context when properly configured. Optimal resource efficiency and unified migrations; requires strict role permissions.

2. Database-Enforced Row-Level Security & Its Boundaries

Relying solely on application developers to remember WHERE tenant_id = @current_tenant in every application query introduces human error. Moving isolation into the database engine via PostgreSQL Row-Level Security (RLS) ensures that every SELECT, UPDATE, and DELETE query automatically filters records against a session variable (e.g., SET LOCAL app.current_tenant_id = '...').

Critical Engineering Caveats on RLS

While RLS significantly strengthens data separation compared to application-only filtering, it is not an absolute barrier:

  • Table Owners & Superusers: By default in PostgreSQL, table owners and superuser roles bypass RLS policies completely unless FORCE ROW LEVEL SECURITY is explicitly enabled. Application connections must run under an unprivileged database role.
  • Security-Definer Functions: Functions executing with the privileges of their creator can inadvertently bypass tenant policies if search paths and execution contexts are not strictly hardened.
  • Session Context Management: If connection pooling (e.g., PgBouncer) does not properly reset session state between transactions, an incorrect tenant ID could persist across connections.

3. Defense-in-Depth: Tenant Envelope Encryption

To supplement database-level access controls, multi-tenant architectures frequently deploy envelope encryption:

  • Tenant-Specific Keys: Each tenant is assigned a distinct Data Encryption Key (DEK).
  • Field-Level Encryption: Highly sensitive columns (such as stored API credentials or personal identifiers) are encrypted in the application layer before reaching database storage.
  • Key Encryption Key (KEK): The DEKs are encrypted under a Key Encryption Key managed in a dedicated Hardware Security Module or sovereign Key Management Service (KMS).

Even if an unauthorized query returns raw database rows, sensitive payload columns cannot be deciphered without the corresponding tenant key in memory.

4. Isolation as a Control, Not a Full Compliance Shield

Under European data protection standards (GDPR Article 32), multi-tenant logical and cryptographic isolation represents an essential technical and organizational measure (TOM). However, achieving robust data isolation does not, on its own, guarantee complete GDPR compliance. Full compliance requires lawful processing grounds, data subject rights workflows, sub-processor agreements, retention schedules, and continuous governance.

In pilot architectures (such as Sorentix Prism's deployment on sovereign Hetzner infrastructure in Frankfurt and Falkenstein), combining PostgreSQL RLS, application-level role validation, and tenant envelope encryption provides a robust, defense-in-depth technical baseline without claiming unrealistic immunity from all security risks.