Skip to main content
CodeSparring

Snowflake, BigQuery, Fabric: The 2026 Landscape and the Cost Showdown

Level 7: Warehouses, Lakehouse & Dimensional Modelinghard30 minwarehouse market landscapebilling archetypescost modelingCROSS JOIN cost matriceswindow functionsunscaffolded synthesis

Speak the 2026 warehouse market in one screen, then price a month of workloads under three billing archetypes and pick the cheapest platform per workload.

The landscape, in one screen

You will be asked what you know about these platforms. Here is enough to speak honestly without pretending depth.

  • Snowflake is the most-used cloud warehouse and appeared in 29.2% of the 2026 postings sample. Its interviews go dialect-deep, so QUALIFY and FLATTEN are worth recognizing.
  • Databricks is the fastest-growing (16.8% of postings) and runs a Spark-native loop. Lakehouse and Delta questions live here.
  • BigQuery leads serverless and event analytics: no cluster to size, you submit SQL and pay for what it reads.
  • Redshift is the AWS-native default, which is why Module 7.1 spent three lessons inside it.
  • Microsoft Fabric is the bundle, billed as always-on capacity units rather than per query.

Three ways to be charged

Under the brand names there are only three billing archetypes, and this is the part that transfers.

  1. Per TB scanned. You pay for bytes read. Athena's published list rate is $5.00 per TB with a 10 MB minimum per query. Cheap for selective queries on partitioned Parquet, brutal for a dashboard that rescans a fat table every 5 minutes.
  2. Per second of compute. You pay while a warehouse or cluster is awake, regardless of how much it reads. Cheap for short queries over huge scans, expensive for long-running queries that read almost nothing.
  3. Flat capacity. You buy a tier for the month and run whatever you like inside it. Wasteful when the platform is idle, unbeatable once volume is large enough.
One steady ETL workload, priced three ways
Step 1 / 3
Per second of compute$337.50
Flat monthly capacity
Per TB scanned

Per second of compute: $337.50. 1,500 runs x 90 s x $0.0025 per second. Short queries over big scans barely touch this meter.

Same workload, same month, a 27x spread. The shape of the workload picked the winner, not the brand.

The meta-lesson

Workload shape decides cost, not brand. A workload with tiny scans and long runtimes is cheap on the scan meter and expensive on the clock. Flip the shape and the answer flips with it. Volume high enough on both meters and flat capacity wins, which is the whole Fabric pitch.

The Practice exercise is the level's boss: build the full cost matrix, price all four workloads on all three platforms, and keep the cheapest per workload. There is no scaffold, only the goal state.

Common mistake: comparing the sticker rates instead of the bills. "$5.00 per TB versus $0.0025 per second" means nothing until you multiply by this workload's queries, scans, and runtimes. Two rates are not comparable; two monthly totals are.

Interview nuance: "why did your team pick X" is really asking for the archetype tradeoff. Answer with the shape of the workload and one number ("our queries scan 2 TB each and finish in 90 seconds, so per-second compute beat per-TB scanning by roughly 20x"). Doing the arithmetic out loud is the differentiator at intern level, where most candidates name a brand and stop.

On a real platform this differs. Real prices vary by region, commitment, and contract, and every vendor layers on caching, autosuspend, result reuse, and storage charges the model here ignores. The arithmetic and the three archetypes are what transfer; the exact rates in platform_pricing are illustrative. Two of them are worth naming so you do not quote them wrongly. The $5.00 per TB is Athena's published list rate, which is the source this course cited in Module 7.1, and it rides on the BigQuery row here only because BigQuery is this lesson's serverless-scan example. BigQuery's own on-demand rate was repriced upward in 2023, so say "Athena lists $5.00 per TB" and never "BigQuery is $5 per TB". The $0.0025 per compute second stands for a larger warehouse tier than the $0.0004 Module 7.1 metered, which is why the same archetype carries a different number two modules apart. Look the current rate up before you quote either one.

Sample data for this example
CREATE TABLE monthly_workloads (
  workload          TEXT,
  queries_per_month INTEGER,
  avg_tb_scanned    REAL,     -- TB read per query
  avg_runtime_s     INTEGER   -- wall-clock seconds of compute per query
);
INSERT INTO monthly_workloads (workload, queries_per_month, avg_tb_scanned, avg_runtime_s) VALUES
  ('spiky_bi',            8000, 0.002,  45),
  ('steady_etl',          1500, 1.2,    90),
  ('adhoc_analytics',      600, 3.5,   300),
  ('always_on_reporting',40000, 0.8,   120);
CREATE TABLE platform_pricing (
  platform               TEXT,
  pricing_model          TEXT,   -- per_tb_scanned | per_compute_second | flat_capacity
  usd_per_tb             REAL,   -- Athena's list rate; see the note above before quoting it
  usd_per_compute_s      REAL,   -- a larger tier than Module 7.1's 0.0004; see the note above
  usd_per_month_capacity REAL    -- billed once per month regardless of query volume
);
INSERT INTO platform_pricing (platform, pricing_model, usd_per_tb, usd_per_compute_s, usd_per_month_capacity) VALUES
  ('BigQuery',  'per_tb_scanned',     5.0, 0.0,    0.0),
  ('Snowflake', 'per_compute_second', 0.0, 0.0025, 0.0),
  ('Fabric',    'flat_capacity',      0.0, 0.0,    5000.0);
Worked example (SQL)
-- One workload, three meters. The winner is a property of the workload's shape.
SELECT p.platform,
       p.pricing_model,
       ROUND(
         CASE p.pricing_model
           WHEN 'per_tb_scanned' THEN w.queries_per_month * w.avg_tb_scanned * p.usd_per_tb
           WHEN 'per_compute_second' THEN w.queries_per_month * w.avg_runtime_s * p.usd_per_compute_s
           ELSE p.usd_per_month_capacity
         END, 2) AS monthly_cost_usd
FROM monthly_workloads w
CROSS JOIN platform_pricing p
WHERE w.workload = 'steady_etl'
ORDER BY monthly_cost_usd;

Apply

Your turn

The task this lesson builds to.

Write a query that returns each workload's monthly cost on the per-TB-scanned platform as (workload, scan_cost_usd), most expensive first, over monthly_workloads(workload, queries_per_month, avg_tb_scanned, avg_runtime_s) and platform_pricing(platform, pricing_model, usd_per_tb, usd_per_compute_s, usd_per_month_capacity).

The scan cost is queries_per_month * avg_tb_scanned * usd_per_tb for the row of platform_pricing whose pricing_model is 'per_tb_scanned'. Round scan_cost_usd to 2 decimals.

3 hints and 1 automated check are waiting in the workspace.

Practice

Make it stick

A second problem on the same idea, plus 2 bonus drills.

Write a query that returns the cheapest platform for every workload as (workload, platform, monthly_cost_usd), most expensive winner first, over monthly_workloads and platform_pricing.

Price every workload under all three pricing models: 'per_tb_scanned' costs queries_per_month * avg_tb_scanned * usd_per_tb, 'per_compute_second' costs queries_per_month * avg_runtime_s * usd_per_compute_s, and 'flat_capacity' costs usd_per_month_capacity no matter how much runs. Keep the single cheapest platform per workload and round monthly_cost_usd to 2 decimals.

This is the level's boss exercise, so there is no scaffold. Build the cost matrix yourself.

3 hints and 1 automated check are waiting in the workspace.