The Cloud Data Warehouse Landscape in 2026

I wanted to understand the cloud data warehouse space beyond the usual names. Snowflake, BigQuery, Redshift are the defaults everyone reaches for, but a lot has changed, especially with Iceberg reshaping how storage lock-in works. Here’s what I found.

What Changed: The Open Format Shift⌗

Traditional warehouses stored your data in their own proprietary formats. A columnar format stores data column-by-column rather than row-by-row, which makes aggregations much faster since queries only read the columns they need. Snowflake’s format was good: automatic micro-partitioning (splitting data into small chunks with metadata about each, so queries can skip irrelevant chunks entirely), compression, clustering. But your data lived inside Snowflake. Migrating away was painful by design.

Apache Iceberg changed that. It’s an open table format that sits on top of object storage (S3, GCS). Your data stays as Parquet files in your own storage bucket, with an Iceberg metadata layer on top that adds schema evolution (adding or renaming columns without breaking existing queries), time travel (querying data as it looked at a past point in time), and richer metadata that enables engines to prune partitions and files efficiently.

The key shift: any query engine that supports Iceberg can read your data. Snowflake, Databricks, Spark, Trino, DuckDB. You’re not locked into one vendor’s runtime.

Delta Lake, created by Databricks, solves the same problem and is the dominant format in the Databricks ecosystem.

Snowflake eventually added Iceberg table support. When the market leader adopts the open standard, you know the standard won.

Worth being precise about what Iceberg actually changes: it removes storage lock-in. You can move your Parquet files to a different engine without reformatting data. What it doesn’t change is governance lock-in (each platform has its own catalog, access control model, and permission system), ecosystem coupling (dbt integrations, BI tool optimizations, and ML pipelines built around a specific runtime), or the operational knowledge your team has built up around a platform. Compute portability and operational portability are not the same thing. The switching cost is lower than it was, not gone.

The Commercial Platforms⌗

Snowflake

The benchmark most teams compare against.

Compute runs on virtual warehouses, clusters that spin up on demand, run your queries, and bill by the second. Storage is billed separately per TB per month. This separation of compute and storage was Snowflake’s core innovation when it launched: you can scale processing power independently from how much data you hold, without paying for idle capacity overnight. Pricing is in credits, which map to warehouse size and runtime. Credits cost roughly $2-4 each depending on cloud and tier, with storage around $23/TB/month (Snowflake pricing).

Two differentiators: Data Sharing (live data shared with other Snowflake accounts, no copies) and Snowpark (run Python or Java directly in-warehouse without moving data out).

The main complaints are cost predictability (a forgotten running warehouse will run up your bill quietly) and the fact that even with Iceberg support added later, Snowflake’s native format remains proprietary.

Snowflake’s enterprise dominance isn’t primarily about the format, though. It’s about governance tooling that actually works for large organizations: role-based access control that non-engineers can reason about, audit logging, compliance certifications, solid SLAs, and a product polished enough that a finance analyst can use it without filing a support ticket. Open formats help you move data. They don’t replace any of that.

BigQuery

Google’s serverless data warehouse. No clusters to configure, no warehouses to size. You run a query, it runs, you get charged for how much data it scanned.

On-demand pricing at $6.25/TB scanned is intuitive at first and surprising later. A query that scans a 5TB unpartitioned table costs the same whether it returns one row or a million. The fix is partitioning your tables by a column like date, so queries only scan the slices they actually need. Ignore this and your bill will reflect it.

For predictable workloads, BigQuery offers flat-rate reservations where you buy capacity measured in slots (each slot is a unit of processing capacity) rather than paying per query. This completely changes the economics for teams running many queries daily.

Storage runs $0.02/GB/month for active data, $0.01/GB/month for data untouched for 90+ days. Compute on-demand is $6.25/TB scanned (BigQuery pricing).

Amazon Redshift

The oldest of the main three, and it shows in parts of its design.

Redshift started as a provisioned MPP (Massively Parallel Processing) warehouse, meaning a distributed system where query work is split across many nodes simultaneously. You pick a node type and count, those nodes run around the clock, and you pay hourly whether you’re using them or not. Amazon added Redshift Serverless more recently, billing by RPU-hour (Redshift Processing Unit, their measure of compute capacity) so you only pay for what you use.

Redshift Spectrum lets you query S3 files directly without loading data into Redshift first. Lake Formation and Glue integration is tight if you’re already deep in AWS. Reserved instance discounts on provisioned clusters can make it the cheapest option when your workload is stable and predictable. If you’re not already committed to AWS, that’s not a compelling reason to start here.

Serverless pricing is $0.375/RPU-hour, provisioned pricing varies heavily by node type (Redshift pricing).

Databricks

Databricks started as a data engineering and machine learning platform, but Databricks SQL has matured into a genuine competitor to Snowflake and BigQuery for SQL analytics workloads. It’s a Lakehouse platform, a term they coined for combining the flexibility of a data lake (raw files in object storage) with the structure and performance of a data warehouse. The pitch is a single platform for all of it, built on top of Delta Lake in your own object storage.

Where Databricks SQL excels is when SQL is one part of a broader workflow that already involves Spark jobs, ML pipelines, or streaming. The shared data model means you’re not copying data between systems. For purely SQL-focused teams with no ML ambitions, Snowflake or BigQuery will feel more streamlined, but Databricks SQL is no longer an awkward choice for analytics on its own.

Compute is billed in DBUs (Databricks Units), which represent processing capacity per hour. DBU pricing varies by workload type (SQL Serverless, Jobs clusters, All-Purpose clusters) which makes cost estimation less straightforward than the other platforms. SQL Serverless runs roughly $0.22/DBU (Databricks pricing). Storage costs are whatever you pay for S3 or GCS, since your data lives there.

Microsoft Fabric

Microsoft Fabric is the successor to Azure Synapse Analytics. Synapse remains supported, but Microsoft has shifted its investment and roadmap to Fabric. If you’re starting fresh on Azure today, Fabric is where you’d land.

Fabric is a unified analytics platform in the same mold as Databricks: one product covering a SQL data warehouse, data engineering, real-time analytics, data pipelines, and Power BI, all on top of OneLake (Microsoft’s unified storage layer, built on Azure Data Lake Storage Gen2 using Delta Lake and Parquet underneath). The SQL component is called Warehouse, and it’s a proper T-SQL data warehouse. Because OneLake uses Delta Lake, your data is stored in Delta/Parquet on ADLS Gen2, though cross-engine interoperability depends on how you catalog and govern it.

Power BI integration is tighter here than anywhere else. For organizations already on Microsoft 365, identity and permissions integrate cleanly.

Pricing is capacity-based. You purchase an F SKU billed by the hour, and all Fabric workloads share that capacity pool. F2 starts at roughly $0.36/hour, F8 around $1.44/hour. Capacity can be paused when not in use. OneLake storage runs ~$0.023/GB/month (Microsoft Fabric pricing).

The downside: Fabric is still maturing, and some features that were stable in Synapse are newer here.

The Open Source Alternatives⌗

DuckDB

DuckDB is the most interesting development in analytics in recent years. It’s an in-process analytical database: no server, no cluster to manage, just a binary you run locally or a library you embed in an application. It can query Parquet files, CSV, JSON, and Iceberg tables directly from S3.

-- DuckDB querying S3 directly, no warehouse required
SELECT year, COUNT(*) AS trips, AVG(fare_amount) AS avg_fare
FROM read_parquet('s3://my-bucket/trips/*.parquet')
GROUP BY year
ORDER BY year;

For datasets that fit in memory, it’s shockingly fast. For datasets that exceed memory, it has out-of-core execution that spills to disk gracefully. And it’s free.

I’d reach for DuckDB first for exploratory analysis, local development, or smaller datasets. The moment you need multiple users querying a shared dataset concurrently, petabyte-scale data, or centralized access control, you’ll want something else. Two options exist for pushing that ceiling. MotherDuck is the managed cloud version that adds collaborative features without you managing infrastructure. DuckLake is a new open catalog format from the DuckDB team that lets multiple DuckDB instances share and write to the same dataset with ACID guarantees and time travel. DuckLake is still early but it’s the open-format path: you bring your own storage, no managed service required (DuckDB).

ClickHouse

ClickHouse is an open-source columnar database built for a specific workload: aggregations over huge volumes of event or time-series data. User behavior analytics, metrics pipelines, log analysis. For that use case, it’s the fastest option available. For general-purpose warehousing with varied query patterns, it’s less of a natural fit.

Available self-hosted or as ClickHouse Cloud (managed). Data modeling has a learning curve and the ecosystem is less mature than the commercial options, but for its target workload nothing here is faster.

Trino

Trino (formerly PrestoSQL) is a distributed SQL query engine. It doesn’t store data. It queries wherever your data already lives: S3, Iceberg tables, Hive Metastore (a metadata catalog used to track table schemas and file locations, originally from the Hadoop ecosystem), relational databases, Kafka. You bring the infrastructure, it brings the SQL.

If you already have data in Parquet on S3 and don’t want to pay to load it into a proprietary warehouse, Trino is a compelling option. It also supports federated queries, meaning a single SQL statement that joins data from S3, a Postgres database, and a Kafka topic simultaneously, something the commercial warehouses can’t do natively.

The trade-off is operational complexity: cluster sizing, autoscaling, caching strategy, and the security controls you’d get out of the box on a managed warehouse. Self-host or use a managed offering like Starburst (Trino).

Cost at a Fixed Workload⌗

To get a directional sense of relative costs, I estimated monthly spend for a fixed workload. These are order-of-magnitude comparisons, not a budget. The actual number for your situation depends on runtime, concurrency, and configuration choices that vary significantly by team. Use these to understand which pricing models favor which workload patterns, not to forecast a bill.

The assumed workload:

• 10TB stored
• 500GB scanned per day (~15TB/month)
• ~100 queries/day, a mix of short lookups and longer aggregations

One thing that makes these hard to compare directly: for scan-priced systems (BigQuery), the primary cost driver is bytes processed; for warehouse-priced systems (Snowflake, Databricks, Redshift), it’s wall-clock runtime × warehouse size. The same workload hits each pricing model differently.

Prices from each platform’s public pricing pages as of early 2026.

Concurrency changes the picture significantly. These estimates model one user running queries sequentially. In practice, if ten analysts are querying at the same time, Snowflake scales by adding warehouse clusters (each cluster multiplies cost), BigQuery absorbs concurrent queries but slot reservations become attractive, and DuckDB is single-process and will queue concurrent requests. What looks cheap at single-user scale can look very different under real team workloads.

The broader picture: BigQuery can significantly undercut Snowflake for bursty workloads with well-partitioned tables. Microsoft Fabric’s capacity model makes direct per-query comparisons tricky, but pausing capacity aggressively keeps costs reasonable. ClickHouse Cloud is competitive at mid-scale if your workload fits its strengths. DuckDB is free until it stops being the right tool.

What to Pick⌗

Infrequent queries and no interest in managing infrastructure: BigQuery. Pay for what you scan, nothing else. Works well when query volume is unpredictable.

All-in on AWS: Redshift. Spectrum for querying existing S3 data without loading it, tight Glue integration, and reserved instance savings for stable workloads.

All-in on Azure or heavy Power BI usage: Microsoft Fabric. SQL analytics, data engineering, and Power BI on top of open Delta Lake storage. Synapse is still around but Fabric is where Microsoft is investing.

ML, data engineering, and SQL on the same data: Databricks. The Lakehouse model makes sense when you’re running the full data stack in one place.

Federated queries across many data sources: Trino. Query Iceberg on S3, Postgres, Kafka, and Hive tables from a single SQL statement. More operational complexity, but nothing else does this as cleanly.

Ultra-fast event analytics or time-series: ClickHouse. For aggregations over billions of events (user behavior, logs, metrics) it’s the fastest option here. Less suited to general-purpose warehousing but excellent at its target workload.

Smaller datasets, prototyping, or embedded analytics: DuckDB. Reach for this first. It’s free and shockingly capable before you outgrow it.

Enterprise polish, Data Sharing, mature ecosystem: Snowflake. Still the most complete product. You pay for it.

Final Thoughts⌗

The obvious-choice era is over. Iceberg made data portable, DuckDB made local analytics viable, and the managed platforms have each addressed their weakest spots. The decision now is less about which platform is best and more about which trade-offs fit your workload, team, and existing cloud provider.

Worth keeping an eye on: Iceberg adoption is accelerating and more engines are adding support. The pressure is toward commoditized compute sitting on top of open storage, which is good for buyers and bad for anyone whose business model depends on proprietary formats.