Fixing Database Query Costs Inside Encrypted Virtual Machines

Researchers have found that databases running inside confidential virtual machines (CVMs) perform poorly not just because of encryption overhead, but because the database's own query planner is making decisions based on completely wrong assumptions about the hardware. A new lightweight calibration technique corrects those assumptions and recovers up to 48 percent of the performance gap, which matters for anyone building secure cloud data pipelines or embedded analytics on trusted execution hardware.

What Is the Core Finding?

Query optimizers in standard databases were designed around conventional virtual machine behavior. When you move those databases into a CVM like one running on AMD SEV-SNP, the cost model is still tuned for the old environment, so the optimizer picks genuinely bad query plans.

The paper identifies two specific hardware-level behaviors that the optimizer cannot see but that dominate actual execution time inside a CVM. The first is data movement cost, which behaves differently because memory pages are encrypted and must be handled carefully. The second involves Reverse Map Table (RMP) translation, a security bookkeeping mechanism unique to SEV-SNP that adds overhead whenever the CPU accesses memory pages. Neither of these factors exists in a standard KVM virtual machine, so a cost model calibrated for KVM will consistently mislead the planner.

How Does the Technical Fix Work?

The calibration is intentionally lightweight. Rather than redesigning the query optimizer, the researchers add simple physical proxy measurements that the optimizer can use to adjust its cost estimates to match CVM reality.

The proxies capture the two dominant overhead sources without requiring the optimizer to understand cryptographic internals. Data movement costs are modeled by observing how memory transfer behavior changes under encryption constraints. RMP translation overhead is modeled by tracking how frequently page-level security checks are triggered during typical query patterns. These proxies slot into the existing cost framework, meaning you are not replacing the optimizer, you are just giving it accurate numbers to work with. The result is that the optimizer starts choosing plans that are actually efficient on CVM hardware rather than plans that would have been efficient on a plain KVM instance.

What Does This Mean for Embedded and Cloud Engineers?

If you are building a system that stores or processes sensitive data in a cloud environment, confidential computing is an increasingly practical option. AMD SEV-SNP and similar technologies let you run an unmodified database inside a hardware-isolated VM where even the cloud provider cannot read your data in use. The problem has always been the performance cost, which made it hard to justify for analytical workloads.

This work suggests that a significant chunk of that performance cost is not fundamental to the encryption itself. It is an artifact of the optimizer making bad decisions. For engineers evaluating whether to move a workload into a CVM, this is meaningful: the raw hardware overhead is smaller than benchmarks have suggested, because those benchmarks were also measuring optimizer misbehavior. A properly calibrated system running inside SEV-SNP can in some cases actually outperform the same workload running in a standard KVM VM, because the calibration forces the planner to choose smarter execution paths overall.

What Are the Current Limits?

The research focuses specifically on analytical queries and the cost model layer. It does not address every source of CVM overhead, and the calibration targets AMD SEV-SNP in particular, so behavior on other confidential computing platforms like Intel TDX may differ.

The proxy measurements also need to be collected and applied as a calibration step, which means integrating this into a production database system requires engineering work beyond what a typical DBMS ships with today. The paper demonstrates the principle and the performance recovery, but turning it into a deployable module for PostgreSQL or another open source DBMS would be a separate engineering project. Additionally, workloads that are not bottlenecked by the two identified overhead sources would see less benefit from this specific calibration.

As confidential computing support matures across cloud providers and FPGA-based security accelerators become more common, cost-model-aware calibration for trusted execution environments will likely become a standard part of database deployment tooling.