Benchmark setup

The last performance check of Transparent Data Encryption in Cybertec's PGEE distribution dates back to 2016. The question remains interesting, so I ran a new set of benchmarks.

Because the differences between a plain instance, one with data checksums, and one with both encryption and checksums are so small, the configuration has to stress these features as hard as possible. In the spirit of deliberately making PostgreSQL slow, I used only 1MB of shared_buffers with a pgbench workload at scale factor 50. The database size of 770MB fits easily into RAM, but a buffer cache that small produces frequent cache misses, with pages re-read from the OS disk cache, checksums verified, and each page decrypted again. To amplify the effect further, I ran pgbench --skip-some-updates so the smaller pgbench tables — which stay in cache regardless — are not touched. This yields a consistent buffer cache hit rate of only 82.8%.

Throughput results

Below are the PGEE 17.6 tps numbers, averaged over several 1-minute, 3-client pgbench runs, for the combinations of data checksums on/off, TDE off, and the supported key bit lengths:

  no checksums   data checksums  
no TDE 2455,6 100,00 % 2449,7 99,76 %
128 bits 2440,9 99,40 % 2443,3 99,50 %
192 bits 2439,6 99,35 % 2446,1 99,61 %
256 bits 2450,3 99,78 % 2443,1 99,49 %

Individual runtimes show considerable noise before averaging, so the figures deserve some caution — 192-bit TDE is certainly not faster with checksums than without. Bearing that in mind, the tiny differences suggest:

  • Enabling data checksums on this poor-cache-ratio workload costs about 0.25%.
  • Enabling both TDE encryption and data checksums on this workload costs about 0.5%.

On any workload with a better shared_buffers cache hit rate, the penalty from enabling checksums and TDE would be lower than that.