Evaluating Encryption Strategies for Vertica – by Avi Haim, Data Architect at EMERSON

Emerson’s Perspective on Performance, Security, and Practical Trade-offs

Avi Haim - Data Architect at EMERSON

As part of Emerson’s ongoing commitment to secure data operations across our analytics and media platforms, we recently completed a detailed review of encryption options available for Vertica, with a particular focus on the operational impact of each method. Vertica provides a mature ecosystem of encryption and data-protection technologies, but these options come with different performance, operational complexity, and infrastructure requirements. We conducted an internal benchmark to evaluate the performance of LUKS disk encryption compared to unencrypted storage. (LUKS is the RH file system encryption option - Linux Unified Key Setup-on-disk-format)

Our tests revealed a 35%–50% increase in CPU utilization when LUKS is enabled, a factor we considered carefully when making architectural decisions.

Below, we share our findings to help other Vertica customers - especially those running at scale - make informed choices.

Why Emerson Evaluated Vertica Encryption Options

Vertica is a core part of our analytical data ecosystem, powering high-volume workloads that demand both performance and security. Emerson manages a wide mix of sensitive data - PII, financial data, business intelligence, operational metrics - and our global compliance standards require robust encryption both at rest and in motion.

However, encryption must not compromise the high-throughput analytical workloads Vertica is known for.

For this reason, we performed a comprehensive evaluation of the encryption mechanisms Vertica supports: 

1. Data-centric encryption (Voltage – OpenText Data Privacy & Protection Foundation)
2. Hardware-based encryption (HPE Secure Encryption)
3. Vertica’s GitHub AES Extension Package
4. Filesystem encryption using LUKS
5. Password hashing (SHA-512)
6. TLS/SSL encryption for client connections and Kafka pipelines
7. Backup encryption via VBR.py

Each offers different protection levels and performance characteristics.

Summary of Vertica Encryption Technologies

1. Data-Centric Encryption: OpenText Voltage (FPE & SST)

Voltage provides encryption and tokenization at field or sub-field level, protecting the most sensitive data elements (PII, PHI, PCI). With features like Format-Preserving Encryption (FPE) and Secure Stateless Tokenization (SST), Voltage allows analytics on masked or encrypted data with preserved referential integrity.

Emerson found Voltage particularly valuable for highly selective encryption (for example, encrypting customer identifiers). However, the trade-off is measurable query-time overhead proportional to the number of encrypted columns, and query tuning becomes critical. Vertica’s access-policy integration allows transparent encryption/decryption based on user roles - powerful for governance, but requiring careful operational design. 

2. Hardware Encryption (HPE Secure Encryption)

This option provides near-zero performance degradation by offloading encryption to Smart Array controllers. For environments running exclusively on HPE hardware, this is the most attractive choice from a performance standpoint.

However, Emerson’s infrastructure includes diverse server families, so hardware encryption was not universally applicable. 

3. AES Field-Level Encryption via the GitHub Extension Package

This extension exposes AES-based encryption/decryption functions directly inside Vertica. Its lightweight implementation is attractive for limited-scope column encryption, but it does not provide the full data-masking capabilities of Voltage. CPU load is proportional to the number of encrypted fields and operations. 

4. LUKS File-System Encryption (Encryption at Rest)

LUKS encrypts the entire disk at the block-device layer, providing broad “full-disk style” protection without needing to modify databases or applications.

Vertica’s documentation typically describes LUKS overhead as negligible. However, Emerson’s internal results suggested a more nuanced reality - particularly with high parallel I/O loads and modern NVMe storage.

Below is the benchmark summary.

Emerson’s Benchmark: LUKS vs. Non-Encrypted Vertica Storage

Emerson executed vsioperf benchmarks on identical Vertica clusters, using the same workload, filesystem layout, and storage media, with the only difference being:

• Non-Encrypted Ext4/XFS
• LUKS-Encrypted Block Device (dm-crypt, AES-XTS)

Our goal was to measure real-world CPU and I/O impact under typical analytical loads.

 Key Findings

1. CPU Usage Increased Significantly Under LUKS

Across write, read, rewrite, and skip-read tests, we consistently measured:
35% to 50% higher CPU utilization under LUKS
This was mirrored in both raw device testing and file-system-level I/O.

The results (from the screenshot provided) show:

• CPU usage jumps from ~16–25% without encryption
• To ~25–38% with LUKS
• Peaks reaching 50% higher in certain write-intensive operations

2. I/O Throughput Stayed Stable

Vertica’s I/O throughput numbers (MB/s, seeks/s) remained almost identical between encrypted and non-encrypted environments.

This matches community expectations: LUKS rarely limits throughput with modern CPUs, but encryption consumes CPU cycles.

3. Latency Differences Were Minimal

Elapsed time and remaining time remained nearly unchanged, showing LUKS encryption overhead falls almost entirely on CPU, not I/O wait.

4. LUKS Overhead Becomes More Noticeable at Scale

In multi-node parallel workloads—especially those with many concurrent I/O operations—CPU headroom becomes a key factor.

For Emerson, this was particularly relevant because analytic workloads are CPU-intensive even without encryption.

Ranking Vertica Encryption Options (From Emerson’s Perspective)

Vertica’s recommended performance ranking matches our own observations:

Emerson’s Takeaways and Recommendations

Based on the testing and Vertica’s encryption ecosystem, Emerson’s conclusions are:

1. LUKS is reliable but not “free”

While LUKS is frequently described as low-impact, our benchmarks show 35–50% CPU overhead under typical Vertica load patterns. For CPU-bound clusters, this overhead must be considered.

2. Hardware encryption is ideal when available

Where HPE Secure Encryption is supported, it provides full-disk encryption with negligible performance loss.

3. Voltage remains essential for per-column governance

Field-level encryption, masking, and tokenization continue to play a crucial role in Emerson’s data security, especially where compliance requires selective visibility.

4. Mixed-strategy encryption is often the best design

For a global enterprise with varied sensitivity levels, Emerson benefits most from a layered approach:

• Hardware or LUKS for broad at-rest protection
• TLS/SSL for secure transmission
• Voltage for business-driven data governance
• Backup encryption for end-to-end protection

5. Capacity planning must include encryption overhead

CPU sizing must account for LUKS or Voltage workloads, ensuring analytics performance remains unaffected.

Conclusion

Emerson’s evaluation confirms that Vertica offers a rich and flexible suite of encryption tools suited for enterprises with diverse security and compliance requirements.

Our testing shows that while LUKS is a strong at-rest encryption option, organizations should plan for a 35–50% increase in CPU usage, particularly in high-throughput analytical environments.

Choosing the right strategy ultimately depends on each organization’s blend of performance requirements, compliance mandates, and infrastructure standards. Vertica’s architecture makes it possible to combine multiple encryption approaches to achieve both security and performance at scale.