How to choose a cloud data warehouse

A cloud data warehouse stores structured and semi-structured data in a columnar format and answers analytical SQL — aggregations across millions or billions of rows — far faster than a transactional database built for individual reads and writes. Most organizations reach for one once BI dashboards, reporting, or data-science workloads have outgrown what an operational database can serve without slowing everything else down.

Every warehouse in this category can run a GROUP BY over a big table quickly. What actually separates them is where they run, how pricing behaves at your scale, and whether the architecture fits a general BI workload or something more specific — sub-second concurrency, decades of mixed-workload tuning, or a governance layer over data you would rather not move.

Start with the cloud you are already on

This eliminates more options than any feature comparison. Amazon Redshift runs only on AWS. Google BigQuery runs only on Google Cloud. Azure Synapse Analytics and Microsoft Fabric run only on Azure. Oracle Autonomous Data Warehouse runs only on Oracle Cloud Infrastructure. If your organization already has committed spend, identity and networking set up on one of those clouds, the matching warehouse starts with a real advantage in cost, latency to other services, and procurement simplicity — and that advantage is often larger than any performance difference you will find in a benchmark.

If you are genuinely multi-cloud, or want to avoid tying your warehouse to one provider, look at Snowflake (available on AWS, Azure and Google Cloud), Teradata VantageCloud, Exasol, OpenText Vertica or SingleStore, all of which run across more than one cloud or on-premises.

Architecture: separated storage and compute, or a traditional cluster

Snowflake, BigQuery, Redshift Serverless, Firebolt and Microsoft Fabric's OneLake all separate storage from compute, so you scale or pause compute independently of how much data you store, and multiple compute workloads can query the same data without contending for resources. This tends to suit variable, bursty workloads well. Teradata, Vertica, Exasol and Greenplum come from a more traditional MPP cluster lineage, tuned over many years for complex, high-concurrency, mixed SQL workloads at very large scale — a strength in demanding enterprise environments, though it typically means capacity planning is more deliberate than "resize a warehouse in seconds." SingleStore takes a different approach again, storing data in both row and columnar formats so the same system handles transactional writes and analytical queries together (HTAP) rather than requiring a separate operational database.

Pricing shape varies more than the feature lists do

• Pure usage-based, billed per second or per unit of work: Redshift Serverless (per RPU-hour), BigQuery (per TiB scanned or per slot-hour), Firebolt (per-second compute with auto-stop), Microsoft Fabric (per capacity unit shared across workloads) and Snowflake (per-second credits, priced by edition). These scale down as well as up — you can genuinely pay less in a quiet month — but the bill is harder to predict in advance than a flat license.
• Quote-only, enterprise licensing currency: Teradata VantageCloud (Teradata Units blending base and on-demand capacity), Exasol (historically RAM-based capacity licensing), SAP Datasphere (Capacity Unit Blocks) and Oracle ADW's underlying Oracle licensing model for larger deployments. Budgeting requires a conversation with sales rather than a public price list.
• Open source, infrastructure cost only: Greenplum has no vendor license at all — you pay only for the compute and storage it runs on, plus the operational effort of running the cluster yourself.

No prices are listed in this guide because they change and depend on region, commitment terms and edition — check each tool's profile for current figures, verified against the vendor's own pricing page.

Match the workload, not just the brand

• General-purpose BI and ELT, no strong cloud preference beyond wanting best-in-class data sharing: Snowflake.
• Already on AWS, want a managed warehouse tightly wired into the rest of the AWS data stack: Amazon Redshift.
• Already on Google Cloud, want zero infrastructure to size and in-warehouse ML via SQL: Google BigQuery.
• Azure-centric and need a dedicated SQL warehouse alongside Spark and serverless lake querying today: Azure Synapse Analytics.
• Azure-centric and want the newer unified SaaS platform — warehouse, lakehouse and Power BI sharing one copy of data on OneLake: Microsoft Fabric, Microsoft's designated successor to Synapse.
• Already running Oracle Database and want a managed, autoscaling warehouse without leaving Oracle's SQL ecosystem: Oracle Autonomous Data Warehouse.
• SAP-centric, need governed access to S/4HANA and BW data blended with external sources without a full migration: SAP Datasphere — note this is closer to a data-virtualization and fabric layer than a traditional warehouse you load data into.
• Sub-second, high-concurrency analytics behind a customer-facing application: Firebolt, or SingleStore if the same system also needs to absorb transactional writes.
• Large enterprise with complex, high-concurrency mixed workloads and decades of proven tuning at scale — banking, telecom, travel: Teradata VantageCloud.
• Want an open-source, self-managed MPP warehouse with full PostgreSQL compatibility and no vendor license: Greenplum.
• Need flexible on-premises-to-cloud deployment for heavy analytical SQL with in-database machine learning: OpenText Vertica.
• In-memory MPP that self-tunes indexing without manual administration, available as SaaS, self-managed, or a free Community Edition: Exasol.

Questions to ask vendors or in a trial

1. What does a realistic month cost at your actual query volume and concurrency, not the sales demo's numbers?
2. Does compute truly pause when idle, and how quickly does it resume when a query arrives?
3. Can you run your two or three heaviest real queries — not a sample dataset — and see the plan, not just the result?
4. What is the actual multi-cloud or portability story if you need to leave — is your data in an open format (like Delta or Iceberg) or a proprietary one?
5. How is row-level and column-level security implemented, and does it satisfy your specific compliance requirement today, not eventually?

Common mistakes

• Picking a warehouse before confirming which cloud the rest of the data stack already lives on, then paying an egress and integration tax indefinitely.
• Benchmarking on a small sample dataset that fits in cache on every platform, which hides the differences that show up at real scale and concurrency.
• Treating "serverless" as "free when idle" without checking minimum billing increments and resume latency.
• Assuming an open-source option like Greenplum is free overall, when the operational cost of running and tuning the cluster is often larger than a managed service's bill.
• Choosing based on a single flagship feature (in-database ML, native vector search) that turns out to be unused six months later, while the everyday cost of running standard SQL was never compared.

See Amazon Redshift vs Snowflake, Google BigQuery vs Snowflake and Azure Synapse Analytics vs Microsoft Fabric, or browse every tool in this category.