Every vendor benchmark I've been sent has the sender winning. Not sometimes — every single one. That's not because anybody is lying; it's because a benchmark is a workload, and if you get to pick the workload you get to pick the winner. Choose 22 TPC-DS queries against a well-clustered fact table and one product looks unbeatable. Choose 400 concurrent dashboard refreshes and a different one does. Choose a single analyst running one enormous ad-hoc scan and it's a third.

Which is why I stopped reading warehouse benchmarks and started reading warehouse *architectures*. Snowflake, BigQuery, and Redshift solved the same problem — separate storage from compute so they can scale independently — and each arrived at a genuinely different answer. Those differences predict which workloads each is good at far more reliably than any number in a PDF. This is the comparison I actually give people when they ask, and it's mostly about matching a shape to a shape.

## What are the three architectures, actually?

### Snowflake: many independent compute clusters over one shared storage layer

Snowflake's model is **multi-cluster shared data**. Your data sits once in cloud object storage in Snowflake's own micro-partitioned columnar format. On top of it you create **virtual warehouses** — independent compute clusters, sized T-shirt style from X-Small up — and each one reads the same data with no knowledge of the others. Your ETL job runs on a Large warehouse, your BI tool runs on a Small, and they cannot contend for resources because they are physically different machines pointed at the same bytes.

That isolation is the design's whole personality. It's also the model's honest weakness: those warehouses are things you turn on, and something you turn on is something you can forget to turn off. Auto-suspend exists precisely because the architecture bills for a running cluster whether or not anyone is querying it.

### BigQuery: no clusters at all, just slots

BigQuery is genuinely serverless — there is no cluster, and there is nothing to size. Data lives in Colossus in the Capacitor columnar format; queries execute on Dremel's multi-level serving tree, with a query decomposed and distributed across a shared pool of workers and shuffled through in-memory intermediate stages, all riding Google's Jupiter network. The unit of compute is a **slot**, an abstract share of execution capacity that BigQuery allocates to your query dynamically. I went through the machinery in more depth in the [BigQuery internals](bigquery-internals-dremel) piece.

Practically, this means there is no cluster to leave running and no capacity-planning meeting — you submit SQL and Google finds the resources. The trade is control: you can't tune the cluster because you don't have one, and if the optimizer makes a poor choice you have fewer levers than the other two give you.

### Redshift: nodes you own, with storage that finally escaped them

Redshift is the oldest of the three and its architecture shows the evolution. Classic Redshift was a cluster of nodes with local storage — genuinely coupled compute and storage, which meant scaling one meant scaling the other and resizing meant downtime. **RA3 nodes with managed storage** broke that: data lives in S3-backed managed storage with an automatic local SSD cache of the hot working set, so you scale compute nodes independently of how much data you keep. **AQUA** pushes some filtering and aggregation down to a hardware-accelerated caching layer near storage. And as of July this year, **Redshift Serverless** is GA — no cluster to provision at all, which is Redshift finally answering the question BigQuery asked in 2011.

The honest read on Redshift in 2022: it has caught up architecturally, but it still exposes more of the machine than the other two. You still choose a distribution style and a sort key, and those choices still make or break performance — the design work I walked through in [Redshift schema design](redshift-schema-design) is not optional the way it mostly is elsewhere.

```mermaid
flowchart TB
    subgraph SF["Snowflake — multi-cluster shared data"]
        SFS[("Object storagemicro-partitions")]
        W1["Virtual warehouseETL — Large"]
        W2["Virtual warehouseBI — Small"]
        SFS --- W1
        SFS --- W2
    end
    subgraph BQ["BigQuery — serverless slots"]
        BQS[("ColossusCapacitor format")]
        SLOT["Shared slot poolDremel serving tree"]
        BQS --- SLOT
    end
    subgraph RS["Redshift — nodes + managed storage"]
        RSS[("RA3 managed storageS3-backed")]
        CACHE["Local SSD cachehot working set"]
        NODES["Compute nodesyou size these"]
        RSS --- CACHE --- NODES
    end
          
```

Three answers to "separate storage from compute." Snowflake gives you many isolated clusters over one copy of the data. BigQuery removes the cluster concept entirely and hands you an abstract share of a shared pool. Redshift keeps nodes you size but moved the durable data behind them into managed storage with a hot cache. Everything downstream — concurrency, cost, tuning — follows from these shapes.

## What does each pricing model punish?

This is the question I'd ask first, because pricing isn't a commercial detail here — it's the architecture's shadow, and each one punishes a different mistake.

|  | Snowflake | BigQuery | Redshift |
| --- | --- | --- | --- |
| You pay for | Warehouse uptime, per second (60s minimum), by size | On-demand: bytes scanned. Or flat-rate: reserved slots | Provisioned: node-hours. Serverless: RPU-seconds |
| It punishes | **Idle warehouses** — paying for a cluster nobody queries | **Sloppy queries** — SELECT * and missing partition filters bill you | **Over-provisioning** — a cluster sized for peak, idle at 3am |
| Cost control | Auto-suspend, right-size warehouses, resource monitors | Partition + cluster your tables; custom quotas; flat-rate at scale | Pause/resume, RA3 right-sizing, or go Serverless |
| Surprise bill looks like | A dev warehouse left running all quarter | One analyst's unfiltered scan of a 40 TB table, repeated hourly | Steady spend regardless of use |

**The bytes-scanned model changes who can hurt you.** On Snowflake or provisioned Redshift, a badly written query is slow — it burns time on compute you've already paid for, and the blast radius is a grumpy analyst. On BigQuery's on-demand pricing that same query is an *invoice*, and nothing warns you: it doesn't fail, doesn't run slowly, it just costs money every time someone re-runs it. This isn't a reason to avoid BigQuery — it's a reason to know that adopting it moves cost governance from the platform team out to whoever writes SQL, and to partition your tables and set custom quotas *before* handing the keys to a hundred analysts rather than after the first monthly bill.

## How does each handle 200 people hitting a dashboard at 9am?

Concurrency is where the architectures separate most visibly, because each solved it in a way that follows directly from its shape.

**Snowflake** spins up more clusters. A multi-cluster warehouse adds clusters automatically as queued queries pile up and removes them as the queue drains — concurrency scaling is just "more of the thing we already have," which is the cleanest possible answer given the design. You pay for the extra clusters while they run.

**BigQuery** allocates slots dynamically from the pool. On-demand, you're sharing with everyone and get a large but variable allocation; on flat-rate you've reserved a fixed number of slots and your queries queue against *your* reservation. The failure mode is subtle: the query that ran in 8 seconds at 3am takes 40 at 9am, because the slots went elsewhere. Nothing is broken. It's just contention, and it's largely invisible.

**Redshift** has workload management queues and concurrency scaling that adds transient clusters for bursts. It works, and it's more configuration than the other two — you're allocating memory and slots across queues by hand, which is powerful if you want that control and a chore if you don't.

## So which one do I actually pick?

Match the architecture to the workload shape, and treat everything else as secondary:

| If your situation is… | Lean toward | Because |
| --- | --- | --- |
| Many teams with wildly different workloads that must not contend | Snowflake | Physical isolation between virtual warehouses is the architecture, not a feature |
| Spiky, unpredictable, mostly-idle analytics | BigQuery | Nothing to leave running; you pay for queries, not for existing |
| Deep in AWS, tight VPC/IAM integration required | Redshift | Native to the ecosystem you already operate and secure |
| Steady, predictable, high-utilization load | Redshift or Snowflake | Reserved capacity beats per-query billing when utilization is high |
| Hundreds of casual SQL writers you can't train | Snowflake or Redshift | A bad query costs time, not money — the blast radius is bounded |
| You want zero infrastructure decisions, ever | BigQuery | There is no cluster to have an opinion about |
| Multi-cloud is a real requirement | Snowflake | The only one that runs on all three clouds |

Two things that *shouldn't* drive the decision but usually do. The first is the benchmark, for the reason at the top — it's a workload someone chose. The second is a feature checklist, because at this point all three do the analytical SQL you need; the differences are in *shape*, not capability. And one honest thing that legitimately should drive it, however unsatisfying: your team already knows one of these, your company already has a contract with one of these clouds, and the migration cost of being clever is real. "The one we can hire for and already have a contract with" is a better answer than most architecture diagrams.

## What to carry away

All three separated storage from compute, and each did it differently enough that the difference is the decision. Snowflake gives you many isolated compute clusters over one copy of the data — so workload isolation is trivial and idle warehouses are the thing that bites you. BigQuery removed the cluster entirely and bills for bytes scanned — so there's nothing to leave running and a sloppy query becomes a recurring invoice instead of a slow afternoon. Redshift kept nodes you size but freed the storage behind them, and still asks you to make distribution and sort-key decisions the others mostly make for you, in exchange for control and AWS-native fit. Pick by matching your workload's shape and your team's reality to those properties, treat every vendor benchmark as a description of a workload someone selected, and remember that the pricing model isn't a commercial footnote — it's the architecture telling you which mistake it intends to charge you for.