A decision framework for choosing a data warehouse platform: billing shape vs workload shape, ecosystem gravity, open-format posture, and exit economics.
TL;DR. The major warehouse platforms are more alike than their marketing admits: storage-compute separation, columnar engines, and open-table-format support are now table stakes everywhere. What still separates them is the shape of the bill (per-second compute, per-query scanning, reserved capacity, or an always-on pool), how hard your existing cloud pulls, catalog and governance gravity, and what leaving would cost. Match billing shape to workload shape, weight ecosystem honestly, treat vendor benchmarks as marketing, and test with your own worst month of queries, not the vendor's demo dataset.
Choosing a warehouse platform is the rare architecture decision that is simultaneously lower-stakes and higher-stakes than teams believe. Lower, because the modern platforms have converged: your dimensional model, your loading patterns, and most of your SQL will carry across any of them, so a defensible choice exists in every direction. Higher, because the bill and the operational texture differ enormously by workload, and because the gravitational pull of a platform, its catalog, its governance stack, its ecosystem, compounds for years after the signature. This framework is for making the choice deliberately. It assumes the fundamentals of what a warehouse is and focuses on the decision itself.
What you are actually choosing between
Names first, since the shortlist writes itself in most organizations. Snowflake sells the cloud-neutral warehouse, running on any of the three major clouds with per-second compute billing. BigQuery is Google's serverless take, billed per query scanned or through reserved capacity. Redshift is Amazon's, provisioned or serverless, and the default conversation inside AWS-committed shops. Databricks arrives from the lake side, selling SQL warehousing and machine learning on one platform. Microsoft Fabric bundles warehouse, Spark, and BI into a pooled capacity model, always-on by default. Others exist and sometimes win (ClickHouse for latency-obsessed analytics, DuckDB-family for small-data pragmatism), but the five above are the decision most readers face.
What you are choosing between is not query engines in any way that will decide the outcome. Practitioners have made this point for years; Jordan Tigani made it most sharply, writing from inside the vendor world, arguing that benchmark performance is a poor predictor of experienced performance. The platforms' own behavior confirms it: the era of forbidding published benchmarks (the DeWitt clause, named for the researcher whose 1982 results embarrassed Oracle into inventing it) has partly ended, with Databricks dropping its clause in 2021 and Snowflake's current terms permitting replicable published results. The benchmark war that followed settled nothing a buyer can use. The real differences live on five quieter axes.
The framework: five axes that decide it
Billing shape against workload shape. This is the axis with the most money on it. The platforms bill in genuinely different shapes: per-second compute clusters you size and suspend; per-query pricing on bytes scanned, with reserved slots as the steady-state alternative; per-second serverless capacity units; consumption units on warehouses that scale by t-shirt size; and a pooled always-on capacity shared across every workload in the suite. None of these is cheapest in general; each is cheapest for a workload shape. Spiky, bursty analytics with idle nights favors per-second and per-query models that cost nothing when silent. Steady all-day concurrency favors reservations and capacity pools whose unit economics reward constant use. The practical move is to profile your own query calendar (a month of concurrency, burst, and idle patterns) and price that calendar under each model using current published rates, which change often enough that any figure printed here would be stale by the time you read it. The five models collapse into the four commitment shapes the figure below orders.
Ecosystem gravity. Where your data, identity, and engineering habits already live pulls harder than any feature. An AWS-committed organization pays a real integration tax to run its warehouse elsewhere, and the same holds for Google and Azure commitments; the bundled options win many selections on this axis alone, on adequacy plus adjacency. The honest question is how much better a non-native choice must be to beat the one your cloud already ships. Sometimes the answer is meaningfully better and the neutral platform earns it; pretending the pull does not exist just moves the cost into integration work.
Open-format posture and the new lock-in surface.Apache Iceberg support has stopped being a differentiator in kind: every major platform now reads it, and, as of late 2025, every major platform writes it in some form. What still differs is maturity and, more importantly, where the catalog lives. As table formats opened up, the lock-in moved one layer: into the catalogs and governance stacks that decide who can read those open files. Evaluating open-format support therefore means asking not can it read Iceberg but which catalog owns my tables, what happens to permissions and lineage if I leave, and can an external engine actually write, not just read. The lakehouse convergence is the background story here.
FIGURE 1Billing shapes, by workload fit
Figure 1. The platforms' billing models ordered by commitment. Leftward models cost nothing when idle and suit spiky workloads; rightward models reward constant utilization with lower unit cost and suit steady concurrency. The expensive mistake is buying a shape that fights your query calendar.
Governance and concurrency at your actual scale. BI concurrency, row- and column-level policy, audit logging, and workload isolation are where platform maturity differences still bite in production. These are unglamorous evaluation items that demos gloss and governance requirements eventually enforce; test them with your real user counts and your real classification needs.
Exit economics. The clouds waived their headline egress fees for customers leaving entirely, a 2024 change driven by European regulation, but routine cross-cloud data movement still costs money, and the practical exit cost was never mostly egress anyway. It is the accumulated platform-specific surface: catalog contents, security policies, stored procedures, and the operational knowledge in the team's hands. The exit question from the warehouse automation evaluation applies verbatim: if you leave in four years, what do you keep? Open formats improve the answer for the data itself; the catalog question above decides the rest.
Worked examples: three shortlists, three answers
A retail analytics team on Google Cloud, spiky dashboard workload, small data engineering staff. The serverless native option wins on gravity and billing shape together: idle-heavy workloads price beautifully per query, and there is no cluster to operate. The evaluation's real job is guarding against the on-demand model's failure mode, unbounded scans, with cost controls from day one.
An AWS-committed enterprise with steady all-day concurrency, a large analyst population, and an ML platform ambition. Here the decision is genuinely contested: the native option wins on adjacency, the lake-side platform wins if the ML ambition is real rather than aspirational, and the neutral warehouse wins if multi-cloud is a stated strategy rather than a slide. This shortlist is where the billing-calendar exercise and a two-platform proof of concept on your own workload pay for themselves.
A Microsoft-standardized mid-market firm whose analytics center of gravity is Power BI. The capacity-pool suite is the default for a reason, one bill, one identity model, native BI, and the evaluation should focus on whether the pooled model fits the workload calendar and where its warehouse engine's maturity edges matter for the team's SQL patterns.
Choosing on benchmarks is the classic, and it fails twice: the published numbers are vendor-authored artillery from a war with no neutral referee, and per-query speed is rarely the binding constraint in real analytical estates. Choosing on list price rather than on your own priced workload is its financial twin; the platforms' models differ enough in shape that ranking them requires a workload to price. Underweighting gravity produces elegant architectures with permanent integration taxes. Ignoring the catalog question buys open formats while re-acquiring lock-in one layer up. And skipping the proof of concept on your own ugliest month of queries, in favor of the vendor's dataset and the vendor's demo, is the same demo-driven selection failure that afflicts every tool category; your workload is the only benchmark with predictive power.
Sources
Billing-model mechanics are documented in the platforms' official materials, which are the only current source for rates and should be re-checked at decision time: Snowflake's compute cost documentation (per-second credit billing), BigQuery's editions and pricing documentation (on-demand and slot models), Redshift pricing (serverless RPU and provisioned models), and Microsoft's Fabric licensing documentation (capacity units). Iceberg support status per platform: Snowflake Iceberg tables, BigQuery managed Iceberg tables, and Redshift's Iceberg support, with append-only write support announced in November 2025; all vendor documentation, current as of mid-2026. The benchmark-skepticism argument is Jordan Tigani's Perf is not enough (2023; the author co-founded a database vendor, labeled accordingly), alongside the DeWitt-clause history and its partial demise (Databricks' 2021 removal, vendor-authored; Snowflake's acceptable use policy permitting replicable published benchmarks). Egress-fee waivers for departing customers were reported across the three clouds in early 2024 (e.g., InfoQ's coverage of the AWS change). Specific dollar rates and TCO comparisons are deliberately absent: they age in months, and the framework is built to be applied to whatever the current numbers are.
