Want to explore possibility of schema level keys with tde

[mathewjustin]

I’ve gone through the pg_tde multi-tenancy documentation and see that it supports encrypting multiple databases within a single PostgreSQL instance, each with its own Data Encryption Key (DEK).

This is a great feature for database-level multi-tenancy.

However, in my setup, we follow a schema-based multi-tenancy model, where:
• We have one database, say app_db
• Each tenant is represented by a separate schema within app_db (e.g., tenant1, tenant2, etc.)

My questions:
1. Does pg_tde support schema-level encryption (i.e., separate keys for different schemas within the same database)?
2. If not, is splitting tenants into separate databases the only way to get encryption isolation using pg_tde?
3. Is schema-level multi-tenancy considered a supported or recommended architecture with pg_tde + Percona PostgreSQL Operator, or is database-per-tenant more aligned with TDE capabilities?

[janwieremjewicz]

Thanks for your questions, and apologies for the delayed response, this came right before GA during a particularly busy period.

Let me address your points one by one:

1. Schema-level encryption: currently, pg_tde does not support schema-level encryption.
   While we considered this approach, we decided against it for the initial release because it would have significantly complicated the design. It’s not entirely off the table for the future, but there are no immediate plans. I’d be very interested to hear from others who are looking for this capability. What I would love to learn from you is to better understand the reasons for preferring schema-level separation. Why do you feel it should be added?

2. Database-per-tenant as an alternative: database level multi tenancy is supported.
   given that database-level multi-tenancy is supported, splitting tenants into separate databases is the recommended approach if you need encryption isolation with pg_tde.

3. Recommended architecture: To be clear, schema-level multi-tenancy is not currently supported with pg_tde.
   The system was designed to allow for future expansion in this direction, but for now, database-per-tenant aligns best with TDE capabilities.