Cloud Data Warehouse Comparison

Every warehouse meters 1 of 2 things: time on a compute pool or data touched by a query. Snowflake and Databricks meter time, and so does Redshift Serverless. BigQuery offers both: on-demand queries bill the bytes they read, and its editions bill slot-hours, the time a unit of compute is allocated to you.

Time-based billing has a floor on every start. Snowflake bills per second with a 60 second minimum each time a warehouse starts, so a 10 second query on a suspended M warehouse (4 credits per hour) bills 60 seconds, 0.067 credits, about 6 times what 10 seconds would cost. A burst of tiny queries that keeps waking a warehouse pays that floor again and again, which is why auto-suspend delays belong in a cost review. Redshift Serverless has the same shape: 4 RPUs at $0.375 per RPU-hour in us-east-1 is $1.50 per hour, so the 60 second minimum charge is $0.025.

Data-based billing has a floor too, and it is easy to trip. BigQuery on-demand bills logical, uncompressed bytes, with a 10 MiB minimum per table a query references. A LIMIT clause doesn't reduce the bytes read from a table that isn't clustered, so SELECT * ... LIMIT 10 pays for the whole table. Partitioning and clustering, a dry run before a heavy query and a maximum bytes billed cap are the controls, and the cap fails a query before it incurs a charge. BigQuery's capacity model bills slot-hours with a 60 second minimum by default.

Which meter wins depends on arrival pattern. A few rare, selective queries on well-clustered tables favour bytes read, because nothing is allocated between them. A steady stream of dashboard queries favours time on a right-sized pool, because the pool stays busy and its price is spread over many queries. When a load is both, the sound design is 2 pools or 2 billing modes, one per pattern, which is only possible because storage is shared between them.

Snowflake runs on AWS and Azure as well as Google Cloud, and its unit of work is the virtual warehouse. Billing is per second, and a suspended warehouse uses no credits. Auto-suspend and auto-resume are on by default, so an idle warehouse costs nothing and the next query wakes it. Cloud services, which cover metadata and optimization, are billed only for the part of a day's usage that exceeds 10% of that day's warehouse credits.

The edition decides features, not speed. Standard keeps Time Travel to 1 day and has no multi-cluster warehouses. Enterprise extends Time Travel to 90 days and adds multi-cluster warehouses and materialized views. Row and column security come with it, as do query acceleration and search optimization. Business Critical adds customer-managed keys and private connectivity, and account failover for regulated data. Credit price depends on edition and region, so read it from Snowflake's pricing guide.

Snowflake is strong where many teams share one account: per-workload warehouses and simple resizing, with a SQL surface that analysts pick up fast. Its weak spot is cost discipline, because a forgotten large warehouse with a long auto-suspend burns credits quietly. The Snowflake interview questions cover how teams ask about it.

Standard warehouses come in 10 sizes, from X-Small at 1 credit per hour to 6X-Large at 512. Each size up doubles the credits per hour, so the largest warehouse burns 512 times the credits of the smallest, as the Snowflake warehouse documentation lists. Credits convert to money at your edition and region's credit price.

Doubling the size doubles the hourly rate, and it halves the run time only for work that spreads across all the added compute. A query that scans a large table in parallel often finishes in close to half the time, so the bill stays about the same and the wait drops. A query that is bound by one slow step does not speed up, so it costs twice as much. Test a query at 2 adjacent sizes before you standardise on the larger one.

Concurrency is a separate dial. A multi-cluster warehouse, an Enterprise feature, adds identical clusters when queries queue. In Auto-scale mode the Standard policy favours preventing queues, while Economy starts a new cluster only when about 6 minutes of work exists for it. The cluster cap falls as size rises: 300 clusters for X-Small to Medium, 160 for Large, 80 for X-Large and 10 for 4X-Large and above. Resize for single heavy queries, add clusters for many light ones.

BigQuery has no warehouse to size. Queries run on slots, units of compute that Google allocates, and you choose how to pay for them: on-demand by bytes read, or through 1 of 3 editions that bill slot-hours. That makes it the easiest of the 4 to start on and the one where a single careless query can cost the most.

The editions split the product. Standard autoscales only, offers no commitments, caps a reservation at 1,600 slots and carries a 99.9% monthly SLO. Enterprise and Enterprise Plus add baseline slots alongside autoscaling, raise the SLO to 99.99%, and offer 1 year (20% discount) or 3 year (40% discount) commitments. Customer-managed keys, BigQuery ML, fine-grained security and VPC Service Controls start at Enterprise, and managed disaster recovery is Enterprise Plus only. These are all in the BigQuery editions documentation.

Design for the meter. Partition tables by date and cluster them by the columns you filter on, so a query reads only the blocks it needs. Run a dry run on any heavy query, which reports the bytes it will process as an upper bound, and set a maximum bytes billed so a mistake fails before it charges. BigQuery suits teams with bursty analysis, many one-off questions, and a stack on Google Cloud.

Redshift is a columnar, massively parallel warehouse with data compression built in, and it comes in 2 forms. Provisioned clusters, including RA3 nodes with managed storage, give you fixed compute you size and pause. Redshift Serverless provisions and scales capacity for you and bills only while the warehouse is in use.

Serverless capacity is measured in Redshift Processing Units, each with 16 GB of memory. Base capacity runs from 4 to 1,024 RPUs. At $0.375 per RPU-hour in us-east-1, the floor of 4 RPUs (64 GB of memory) runs $1.50 per hour and the ceiling of 1,024 RPUs runs $384.00 per hour. Billing is per second with a 60 second minimum charge.

On provisioned clusters, each cluster earns up to 1 hour of free Concurrency Scaling credits a day, accumulating to 30 hours, so occasional spikes cost nothing extra. Redshift reaches into S3 data lakes and operational databases through the same SQL, and its IAM and Glue integrations, plus Kinesis, make it the low-friction choice when everything else already runs in AWS. Check feature dependencies before you commit: AWS stops supporting Python UDFs after June 30, 2026, with enforcement in phases.

Databricks starts from the data lake and adds warehouse behaviour on top. Tables are Delta Lake tables: Parquet data files extended with a file-based transaction log that provides ACID transactions. The log follows an open protocol, and Delta Lake is the default format for every table on Databricks. Spark jobs and machine learning training read the same files that SQL dashboards query, with no copy into a warehouse.

SQL queries run on SQL warehouses. Databricks recommends the serverless type where it is available (pro and classic are the others): compute is instant and elastic, and Databricks manages capacity and tuning. A stopped warehouse restarts when a query runs against it or a scheduled job is assigned to it. It also restarts when a JDBC or ODBC connection opens or a dashboard that uses it is opened. Usage is metered in DBUs, whose rate depends on the compute type, so read the current rate from the pricing calculator.

The trade is operational. Databricks gives the most control over the files and the broadest workload range, from streaming to machine learning, and it asks the team to own more of the table layout and governance. Data engineers who run Spark pipelines already often find it the shortest path. The Snowflake vs Databricks interview guide walks through how the 2 get compared in a loop.

A warehouse is one box in a chain, and most of a data engineer's daily work happens on either side of it. Data arrives through connectors or a stream, a transformation layer turns raw tables into modelled ones, an orchestrator runs the steps in order, checks catch bad data before a dashboard shows it, and a BI layer serves the result.

Choose the warehouse and the transformation layer together. dbt runs on all 4 products here, so SQL models travel between them, while Spark-heavy teams lean toward Databricks because the engine they already use is the platform. Other engines are worth a look at the edges, including ClickHouse for real-time analytics and DuckDB for local and embedded work, but they solve narrower problems than the 4 above.

How these pieces fit together is the content of data pipeline design, and it is what interviewers probe when they ask you to draw a warehouse-centred stack. The data pipeline interview questions and data pipeline practice problems work through that design.

Start with where the data and the team already are. A company that runs on AWS, with sources in S3 and RDS and streams in Kinesis, pays less friction for Redshift. A company on Google Cloud that pulls exports from Google Analytics and Ads gets BigQuery nearly free of setup. A multi-cloud company, or one that does not want its warehouse tied to its cloud, looks first at Snowflake and Databricks.

Then measure your own workload. Take the 10 heaviest queries and the 10 most frequent, run them on each candidate with realistic data volumes, and compute the cost of each meter: bytes read for per-query billing, size multiplied by seconds for time-based billing, with the minimum applied. Add the idle cost of the pools you would keep running, and the engineering time each product asks for, since a cheaper meter that needs a person to tune it is often the dearer choice.

Finally check the constraints that rule products out: compliance features (Snowflake Business Critical, BigQuery Enterprise Plus), the open file format you need for non-SQL engines (Databricks), the concurrency you need at peak (multi-cluster warehouses, slot reservations, Redshift Concurrency Scaling) and the exit cost if you switch.

Interviewers rarely ask which warehouse is best. They ask you to choose one for a stated workload and defend it: a stream of events with dashboards on top, a nightly batch with a tight deadline, or a bursty set of analysts. The strong answer names the meter and the idle cost, and says how workloads stay isolated. It ends on the number that decides it.

Expect follow-ups on partitioning and clustering to cut bytes read, and on sizing and auto-suspend to cut time billed. Another is how you would keep a load job from starving a dashboard. For the format of those rounds, see the data engineer interview prep guide, and rehearse the design side with the data pipeline practice problems.