Executive Summary
Price a month of your own workload on each platform’s meter before the demos. Credits, slots, RPUs, DBUs, capacity units and ECPUs do not convert into each other.
An enterprise cloud data warehouse is a managed service that holds an organization’s structured and semi-structured data in one place and runs SQL analytics and reporting on it, while the provider runs the servers and storage. Google Cloud describes a data warehouse, also called an enterprise data warehouse (EDW), as an enterprise data platform used for the analysis and reporting of structured and semi-structured data from multiple data sources.
Choose one on five things: how compute is provisioned and kept apart between workloads; how it behaves with hundreds of users at once; which clouds and data centers it runs in; whether it reads open table formats in your own storage; and what its price meter counts.
The companies that sell cloud data warehouses divide by where they started: an independent service that runs on several clouds, the cloud providers’ own warehouses, a warehouse inside a SaaS analytics suite, a SQL warehouse on a lakehouse platform, database vendors that moved their warehouses to the cloud, and an open-source columnar database sold as a service. The vendor landscape below names eight platforms and the approach each takes.
What Is an Enterprise Cloud Data Warehouse?
A data warehouse is the system an organization queries to answer questions across its applications. AWS describes a data warehouse as a central repository of information that can be analyzed to make more informed decisions, with data flowing in from transactional systems, relational databases, and other sources, typically on a regular cadence. Analysts, data engineers and executives reach it through BI tools, SQL clients and spreadsheets.
The difference from an operational database is the workload. AWS states that a data warehouse is specially designed for data analytics, which involves reading large amounts of data to understand relationships and trends across the data, while a database is used to capture and store data, such as recording details of a transaction. That is why warehouses store data in columns, compress it heavily and spread each query across many processors.
A cloud data warehouse is the same system delivered as a managed service. The provider runs the hardware, storage, patching and scaling, and you pay for what you use. Storage and compute are usually separate, so data can grow without buying more compute, and compute can be added for a busy hour without copying data.
Enterprise adds requirements a departmental warehouse can skip: hundreds of concurrent users, workloads that must not slow each other, data residency, single sign-on and audit logs, private network connections, and a recovery plan someone has tested.
Warehouses and lakehouses now overlap. Most warehouses read open table formats, and lakehouse platforms include SQL warehouses. This guide covers platforms bought mainly to run SQL analytics. Open table formats, catalogs and the engines that share them are compared in the data lakehouse guide.
How Do Cloud Data Warehouses Run Compute?
In one of three ways: clusters you size, serverless capacity the service sizes for you, or capacity you reserve for a period and share across workloads. Google Cloud states that some cloud data warehouses may use a cluster-based architecture similar to a traditional data warehouse, while others adopt a serverless architecture, which further minimizes data management responsibilities.
Sized clusters run until you suspend them, and the bill follows the size and the hours. Snowflake states that each virtual warehouse is an independent compute cluster that doesn’t share compute resources with other virtual warehouses and has no effect on the performance of other virtual warehouses. A separate cluster per team is the simplest way to keep workloads apart. Its cost is clusters left running when nobody is querying.
Serverless capacity is sized by the service from the queries it receives. Google states that BigQuery's separation of compute and storage layers lets each layer dynamically allocate resources without impacting the performance or availability of the other. You give up control of sizing and gain no idle clusters; you then need limits that stop one runaway query from setting the month’s bill.
Several platforms offer more than one model, or let you decide whose cloud account runs the compute. Databricks states that Databricks SQL supports serverless, pro, and classic types. Databricks states that with a pro SQL warehouse, unlike a serverless SQL warehouse, the compute layer exists in your AWS account rather than in your Databricks account. Teradata states that Teradata Cloud, the cloud deployment of the Teradata Autonomous Knowledge Platform, runs always-on active compute and on-demand elastic compute in a single managed system.
Who tunes and maintains the system also differs. Oracle states that Autonomous AI Database does not require database administration and handles provisioning, backing up, patching and upgrading, and growing or shrinking the database. Ask each vendor which tasks stay with your team: clustering or distribution keys, materialized views, workload queues, warehouse sizes and spending limits.
| Compute model | How capacity is set | How workloads are kept apart | Ask the vendor |
|---|---|---|---|
| Sized clusters | You choose a size and when it runs | A separate cluster per workload | What does an idle cluster cost, and how fast does a suspended one resume? |
| Serverless | The service sizes capacity from the queries | Limits or reservations per workload | What caps spending, and which queries wait when the cap is reached? |
| Reserved capacity | You buy capacity for a month or a year and workloads share it | Priority rules or separate reservations | What happens to queries when the capacity is fully used? |
| Steady plus burst | Fixed capacity for routine work and on-demand compute for peaks | Routine and burst work on separate compute | How is burst compute metered, and is it capped? |
What Should an Enterprise Cloud Data Warehouse Do?
Answer SQL quickly for many users at once, keep workloads from slowing each other, load fresh data, control who sees what, and read data it does not store. Most platforms do all five. They differ in how much happens automatically and how much your team configures and pays for.
Concurrency is where platforms separate under real load. Snowflake states that multi-cluster warehouses enable you to scale compute resources to manage your user and query concurrency needs as they change. AWS states that when you turn on concurrency scaling, Amazon Redshift automatically adds additional cluster capacity to process an increase in both read and write queries. Ask what the added capacity costs and how long a query waits before it arrives.
Fresh data depends on how it gets in. Scheduled batch loads are the default. Some platforms also replicate operational databases without a pipeline you run. AWS states that zero-ETL integration is a fully managed solution that makes transactional and operational data available in Amazon Redshift without the need to maintain an extract, transform, and load (ETL) pipeline. Ask which sources each platform replicates without a pipeline you run, and how far behind the source the copy runs.
Warehouses now read and write open table formats in object storage, so other engines can use the same data. Snowflake states that Iceberg tables store their data and metadata files in an external cloud storage location, such as Amazon S3, Google Cloud Storage, or Microsoft Azure Storage, that isn’t part of Snowflake. Teradata states that its elastic compute is on-demand compute that operates directly on Iceberg and Delta tables in object storage. Ask which features work only on the vendor’s own table type.
Published benchmarks need care. The TPC describes TPC-DS as an industry-standard benchmark that simulates complex decision-support systems and big data environments. The TPC states that, due to fundamental architectural shifts in how costs and performance are calculated, V4 results are not comparable with any previous versions of the benchmark. A vendor’s own benchmark is the vendor’s test on its chosen queries. Your queries on your data are the test that applies to you.
Access control must hold in every tool that reaches the data. Test row filters and column masks from the BI tool, a notebook and any outside engine that reads the same tables, and confirm that every query is logged with the user who ran it.
| Capability | What to test | Why it matters |
|---|---|---|
| Concurrency | Your peak number of users and queries, with queue times recorded | Dashboards slow down when queries wait |
| Workload isolation | Month-end jobs and dashboards running at the same time | One team’s job should not delay another’s |
| Loading and replication | Batch loads, streaming and replication from operational databases | How current the reports are |
| Semi-structured data | JSON and nested data queried with SQL without flattening first | Event and application data arrive this way |
| Open table formats | Reading and writing Iceberg or Delta tables in your storage | Lets other engines use the data without copies |
| Access control | Row filters, column masks and audit logs across every tool | Regulated data stays governed |
| Data sharing | Live tables shared with other accounts and organizations | Replaces extract files sent by email or SFTP |
| Recovery | Restoring a dropped table and failing over to another region | The recovery plan works only if it has been tested |
| Deployment | Clouds, regions, private networking and on-premises options | Residency and who operates the system |
Vendors in Enterprise Cloud Data Warehouse Platforms
Representative vendors include Amazon Redshift, ClickHouse Cloud, Databricks, Google BigQuery, Microsoft Fabric / Synapse, Oracle Autonomous AI Lakehouse, Snowflake and Teradata Cloud. The list is alphabetical, is not a ranking, and is not for sale. How we choose vendors
Cloud data warehouse companies divide by the product they started from. That origin sets where the warehouse runs, how its compute is sold and what else arrives in the same contract.
The independent warehouse service runs on the large public clouds but not in your data center. Snowflake states that a Snowflake account can be hosted on Amazon Web Services (AWS), Google Cloud or Microsoft Azure (Azure). Snowflake states that you can’t install and run Snowflake locally or on private cloud infrastructures, whether on-premises or hosted.
Cloud providers sell their own warehouses, billed and integrated with the rest of their cloud. Google describes BigQuery as a fully managed, AI-ready data platform whose serverless architecture lets you use languages like SQL and Python with zero infrastructure management. Google states that BigQuery Omni lets you run BigQuery analytics on data stored in Amazon Simple Storage Service (Amazon S3) or Azure Blob Storage by using BigLake tables. AWS describes Amazon Redshift as a fully managed, petabyte-scale data warehouse service in the cloud.
One suite puts the warehouse beside data engineering, real-time analytics and BI in a single SaaS product. Microsoft describes Fabric Data Warehouse as an enterprise scale relational warehouse on a data lake foundation. Microsoft states that Fabric Data Warehouse is primarily developed with T-SQL and has full multi-table ACID transaction support. Microsoft states that Fabric Data Warehouse data, like all Fabric data, is stored in Delta tables, which are Parquet data files with a file-based transaction log. Microsoft states that the Fabric Migration Assistant for Data Warehouse provides an automated migration experience from Azure Synapse Analytics dedicated SQL pools.
A lakehouse platform sells SQL warehouses over the same tables its data engineering and machine learning use. Databricks describes Databricks SQL as a cloud data warehouse built on lakehouse architecture that runs directly on your data lake and supports ANSI SQL with Delta Lake extensions.
Database vendors that sold warehouses for data centers now sell them as cloud services, and both still run on premises. Oracle states that Autonomous AI Lakehouse provides the same platform across OCI, AWS, Microsoft Azure, Google Cloud, Cloud@Customer, and on-premises. Oracle states that you can retire aging data warehouse infrastructure without rewriting what runs on top of it, carrying forward existing schemas, SQL, and BI tools. Teradata states that Teradata Cloud is purpose-built for enterprise workloads across AWS, Microsoft Azure, and Google Cloud. Teradata states that it supports cloud, customer-managed cloud, and on-premises deployment options.
An open-source analytical database is also sold as a managed service. ClickHouse describes ClickHouse as a column-oriented SQL database management system (DBMS) for online analytical processing (OLAP), available as both open-source software and a cloud offering. ClickHouse states that its Bring Your Own Cloud deployment model allows you to experience the advantages of ClickHouse Cloud within your own Virtual Private Cloud (VPC).
The cloud data warehouse market overlaps the lakehouse market. Query engines that read open tables where they are stored, and hybrid lakehouse platforms for data centers and clouds, compete for the same budget and are compared in the data lakehouse guide.
| Vendor | Approach | Where it fits |
|---|---|---|
| Amazon Redshift | Cloud provider’s own warehouse | Provisioned clusters or Redshift Serverless measured in RPUs, with zero-ETL replication |
| Google BigQuery | Cloud provider’s own warehouse | Serverless warehouse priced by data scanned or by slots, with Omni for data in other clouds |
| Oracle Autonomous AI Lakehouse | Database vendor’s warehouse, cloud and on premises | Self-managing Oracle warehouse on OCI, other public clouds and on premises, billed by ECPUs |
| Teradata Cloud | Database vendor’s warehouse, cloud and on premises | Active and elastic compute on AWS, Azure or Google Cloud, plus customer-managed and on-premises options |
| Snowflake | Independent multi-cloud warehouse | Virtual warehouses on AWS, Google Cloud or Azure, billed per second in credits |
| ClickHouse Cloud | Open-source columnar database as a service | Managed ClickHouse with compute that scales to zero when idle, or deployed in your own VPC |
| Databricks | SQL warehouse on a lakehouse platform | Databricks SQL warehouses (serverless, pro or classic) over Delta Lake tables |
| Microsoft Fabric / Synapse | Warehouse inside a SaaS analytics suite | Fabric Data Warehouse in T-SQL on Delta tables, with a migration assistant for Synapse dedicated SQL pools |
Eight platforms across six approaches; Google and AWS share one, as do Oracle and Teradata. The approaches were written before any platform was selected, and the platforms were chosen from the five this guide evaluated before, plus one for each approach those five did not cover. Microsoft is printed “Microsoft Fabric / Synapse” because Fabric Data Warehouse is the migration target Microsoft names for Azure Synapse Analytics dedicated SQL pools. No row in this table is for sale. Other warehouse vendors can make their own case in the Spotlight below.
How Is a Cloud Data Warehouse Priced?
By compute, in a unit each vendor defines, plus storage by the terabyte per month. Price a month of your own workload in every unit you are offered: the heaviest dashboards, the month-end jobs and storage at year-three volume.
Most vendors meter compute time by size. Snowflake states that warehouses are only billed for credit usage while running, and that credits are billed per-second, with a 60-second (i.e. 1-minute) minimum. Databricks defines a Databricks Unit (DBU) as a normalized unit of processing power on the Databricks Lakehouse Platform used for measurement and pricing purposes. Microsoft states that capacity units (CUs) measure the compute power for each Microsoft Fabric SKU. Oracle states that Autonomous AI Lakehouse is billed by ECPUs. Teradata states that a Teradata Unit is a unified pricing currency used across Teradata services, including compute, storage, software, and AI. ClickHouse states that one compute unit is 8 GiB of RAM and 2 vCPUs, and that compute is metered per minute and billed per compute-unit-hour.
Scan-based pricing charges for data read instead of compute time. For BigQuery, Google lists on-demand queries at $6.25 per tebibyte, with the first 1 TiB per month free. Google states that with capacity pricing you are charged for compute capacity used to run queries, measured in slots (virtual CPUs) over time. Partitioning, clustering and selecting only the columns you need reduce what each on-demand query reads.
AWS states that Amazon Redshift offers two deployment options, Provisioned and Serverless, and lists Redshift Provisioned as starting at $0.543 per hour and Redshift Serverless as beginning at $1.50 per hour. AWS states that Redshift Serverless base capacity is measured in Redshift Processing Units (RPUs), where each RPU provides 16 GB of memory, and can be adjusted from 4 to 1024 RPUs. For concurrency scaling, AWS states that each cluster earns up to one hour of free Concurrency Scaling credits per day, and that usage exceeding the free credits is paid at a per-second on-demand rate.
Idle time and commitments move the bill as much as list prices. ClickHouse states that compute scales down to zero after a period of inactivity, while storage is billed continuously for the data you keep. ClickHouse states that you can pay as you go or commit to a contract through the AWS, GCP and Azure marketplaces, and that pricing is identical whether you buy through a marketplace or directly from ClickHouse. Ask your cloud provider whether a purchase through its marketplace counts against your existing spending commitment.
Capacity size can change what else you pay for. Microsoft states that to view Power BI content with a Microsoft Fabric free per user license, your capacity must reside on an F64 or larger SKU.
| Meter | You pay for | Grows with | Where it goes wrong |
|---|---|---|---|
| Compute time by size | A sized cluster or capacity for the minutes it runs | Hours running and the sizes chosen | Clusters left running, and sizes set for the peak |
| Data scanned | Bytes read by each query | Query volume and table design | Queries that read every column of unpartitioned tables |
| Serverless capacity | Capacity units the service assigns per workload | Query complexity and concurrency | No spending limit on a workload that grows |
| Committed capacity | Capacity bought for a year or more at a discount | The size of the commitment | Capacity paid for and not used |
| Storage | Compressed data, backups and retained history | Data volume and retention settings | History and backups kept longer than needed |
| Data transfer | Data moved between regions, clouds and the internet | Cross-region and cross-cloud queries | Replicas and extracts nobody reads |
How Do You Migrate to a Cloud Data Warehouse?
Move one subject area at a time, and run the old and new warehouses side by side until the numbers match. Convert code and security before the first users move, not after. The phases below assume a pilot of about three months.
List every source, scheduled job, report, extract and user of the current warehouse, with how often each runs. Pick two or three subject areas for the pilot, including the heaviest dashboards and the month-end close.
Load the pilot data at production volume. Replay a recorded busy day of queries at peak concurrency, and record queue times, compute consumed and the bill in each vendor’s unit.
Convert SQL, stored procedures and scheduled jobs to the new dialect. Re-create roles, row filters and column masks, and test every BI tool and extract that connects to the warehouse.
Move subject areas in waves. Reconcile row counts and totals against the old warehouse, switch users over, then retire each old table so it is not stored and paid for twice.
What should you ask vendors about Enterprise Cloud Data Warehouse Platforms?
Put these questions in the RFP, and ask for each answer to be shown on a sample of your own data.
-
Do most of your applications and data already run on one cloud provider?Yes Shortlist that provider’s warehouse and at least one platform from another approach, and run the same pilot on both.No Shortlist platforms that run on every cloud you use, and price data transfer between them.
-
Must data or compute stay in your own data center?Yes Shortlist platforms with on-premises or customer-managed deployment, and compare them on the same workload.No Compare whose cloud account holds the data and the compute, and who is responsible for recovery.
-
Do data engineering and machine learning need to work on the same tables as SQL users?Yes Test SQL warehouses on lakehouse platforms and warehouses that write open table formats.No Weight concurrency, SQL compatibility with your current code, and cost per query most heavily.
Cloud Data Warehouse RFP package: 127 questions, 10 demo scenarios and a vendor scorecard
RFP packages are a separate paid product. Vendors do not pay to appear in buyer guides.