Thanks for the information, Andreas, Stephen.
Our use-case is for a multi-tenancy scenario - we are considering using different databases to store different customer's data, however, for cost-efficiency, we want to host them in the same server (to reduce the CPU/mem idle time and to reduce the server management efforts). Now there is a compliance related feature that we need to let our customer control the KEK for their databases so they can rotate their KEKs independently, so we cannot use one KEK for the whole PG server. Conceptually, different databases are independent of each other, it also makes sense to allow them to have completely independent encryption facilities?
Thanks,
Our use-case is for a multi-tenancy scenario - we are considering using different databases to store different customer's data, however, for cost-efficiency, we want to host them in the same server (to reduce the CPU/mem idle time and to reduce the server management efforts). Now there is a compliance related feature that we need to let our customer control the KEK for their databases so they can rotate their KEKs independently, so we cannot use one KEK for the whole PG server. Conceptually, different databases are independent of each other, it also makes sense to allow them to have completely independent encryption facilities?
Thanks,
Tony
On Thu, May 18, 2023 at 8:54 AM Stephen Frost <sfrost@xxxxxxxxxxx> wrote:
Greetings,
* Tony Xu (tony.xu@xxxxxxxxxx) wrote:
> The FAQ (copied below) mentioned that native transparent data encryption
> might be included in 16. Is it fair to assume that it will support database
> level encryption, that is, we can use two encryption keys for two databases
> in the same server, respectively? How can one verify that?
The current work to include TDE in PG isn't contemplating a per-database
key option. What's the use-case for that? Why do you feel that you'd
need two independent keys? Also, the general idea currently is that
we'll have one key provided by the user which will be a KEK and then
multiple DEKs (different ones for relation data vs. temporary data vs.
the WAL).
If you're interested in TDE in PG, we could certainly use more folks
being involved and working to push it forward.
Thanks,
Stephen
