Cloud-native compute refers to the architectural pattern of deploying analytical processing workloads on elastic, managed compute infrastructure provided by cloud platforms (AWS, Azure, GCP), rather than on fixed, on-premises server hardware. The defining characteristics of cloud-native compute for data lakehouses are elasticity, ephemerality, and the strict separation of compute from storage.
Elasticity
A cloud-native query engine can provision additional compute nodes in seconds when query demand spikes (for example, during a quarterly business review when hundreds of analysts simultaneously refresh their dashboards) and release those nodes back to the cloud provider's pool when demand subsides. This "pay for what you use" model replaces the traditional approach of buying enough fixed server hardware to handle peak demand, which then sits mostly idle during off-peak hours.
Compute-Storage Separation
Cloud-native compute architectures completely separate compute nodes from storage. Data lives permanently in object storage (Amazon S3, Azure Data Lake Storage, Google Cloud Storage). Compute nodes are stateless processing engines that read data from storage, execute queries, and return results. Because compute nodes hold no data, they can be added or removed freely without affecting data durability or accessibility. Multiple independent compute engines (Spark for ETL, Dremio for BI, Ray for ML) can all operate simultaneously on the same Iceberg data stored in S3.
Implications for Data Cost
The economics of cloud-native compute fundamentally change the Total Cost of Ownership for analytics. Storage costs on S3 are measured in cents per GB-month. Compute costs are incurred only while queries execute. An organization can store petabytes of Iceberg data cheaply in S3 and only pay for the compute minutes needed to answer specific analytical questions, replacing the expensive, always-on managed warehouse model with a more surgical, workload-proportionate spending approach.
