The Cloud Data Warehouse replaced on-premise Teradata and Oracle Exadata clusters with managed, elastic SQL analytics services delivered over the internet. Products like Amazon Redshift (2013), Google BigQuery (2011), and Snowflake (2014) fundamentally changed enterprise data analytics by eliminating hardware procurement cycles and replacing fixed capacity with per-query or per-second billing. Understanding what these platforms do well, and where they run into limits, is essential context for any open lakehouse architecture decision.
What Cloud Data Warehouses Do Well
Cloud data warehouses excel at managed operational simplicity. The vendor handles storage management, query optimization, automatic scaling, backup, and security patching. A data team with no infrastructure expertise can have a fully functional analytical SQL environment running in hours. For teams with primarily SQL BI workloads and data volumes under the hundred-terabyte range, this managed simplicity is genuinely valuable.
They also provide predictable performance. Massive parallel processing (MPP) architectures distribute query execution across hundreds of nodes. Well-designed schemas with proper clustering and distribution keys produce sub-second query latency on pre-computed aggregations.
Where Cloud Data Warehouses Fall Short
Three limitations become significant at scale:
- Storage cost: Cloud data warehouses charge for proprietary compressed storage at rates that are 5-20x higher than equivalent data stored in open Parquet files on S3. At petabyte scale, this cost difference becomes a significant budget line.
- ML/AI workload lock-in: Machine learning training jobs cannot read directly from Snowflake's proprietary micro-partitions or BigQuery's capacitor format. Data scientists must export CSVs or use specialized connectors, adding latency and duplicating storage.
- Engine lock-in: Queries must run through the vendor's engine. Organizations cannot substitute a different query engine for specific workloads without migrating the data.
The Migration Path to Open Lakehouse
Organizations do not need to abandon their cloud data warehouse overnight to adopt open lakehouse principles. Dremio can federate queries across both Snowflake tables and Iceberg tables simultaneously. A typical migration pattern starts new datasets in Iceberg (gaining open format benefits immediately), runs the two systems in parallel while migrating high-cost, high-volume datasets to Iceberg, and eventually consolidates all analytical workloads onto the open lakehouse as the team builds confidence in the new platform.
