← Library

Part 5 · Tools of the trade · 2 of 6

Warehouses and Lakehouses: Snowflake, Databricks, BigQuery, Redshift, Fabric

The platforms where data lands and SQL runs. How each one thinks, what it charges you for, and the questions a Data PM asks before a workload lands on it.

3 min read

All five do the same core job: store large tables and run SQL over them at scale. They differ in how they think and what you pay for.

PlatformHow it thinksBills you forDistinctive pieces
SnowflakeA cloud data warehouse. Storage and compute are separate; you spin up "virtual warehouses" (compute clusters) per team or workload.Compute credits per second a warehouse runs, plus storage.Time Travel (query a table as of yesterday), zero-copy cloning, secure data sharing and a marketplace, Snowpark for Python/Java, Horizon for governance.
DatabricksA lakehouse: open files (Parquet) in your cloud storage, made table-like by Delta Lake, processed by Apache Spark. Notebooks in Python, SQL, Scala, R.Compute (DBUs) for clusters and SQL warehouses, plus your own cloud storage.Delta Lake, Unity Catalog (governance across workspaces), MLflow (experiments and model registry), Databricks SQL. The medallion Bronze/Silver/Gold pattern comes from here.
Google BigQueryServerless warehouse: no clusters to manage; you submit SQL and Google allocates capacity.Bytes scanned per query (on-demand) or reserved "slots"; plus storage.Tight fit with Google Analytics/Ads, BigQuery ML in SQL, native streaming inserts.
Amazon RedshiftAWS's warehouse; provisioned clusters or Serverless.Node-hours (provisioned) or RPU-seconds (serverless); plus S3 storage via Spectrum.Deep AWS integration (S3, Glue, Kinesis), Spectrum to query S3 files in place.
Microsoft FabricA unified SaaS analytics platform: OneLake storage, Synapse warehousing, Data Factory pipelines, Power BI, all in one workspace.Capacity units (a pooled reservation) rather than per-service meters.One security and billing model across engineering and BI; the natural choice for Power BI-centric organisations.

Your first hour on any of them

  1. Find the catalog / database / schema hierarchy and the table you care about.
  2. Run SELECT * FROM table LIMIT 20; and SELECT COUNT(*) .... Everything you practised in the labs works here; the dialect differs slightly (LIMIT vs TOP, date functions).
  3. Open the query history: who runs what, how often, how expensive. This is the fastest way to learn what a company actually uses.
  4. Look for a cost or usage dashboard. Warehouses are where data budgets go.

Questions a Data PM asks

  • Which layer is this table? Raw landing (Bronze), modelled (Silver), or metric-ready (Gold)? Is a dashboard reading from raw?
  • What does a query cost, and who pays? A single SELECT * on BigQuery can scan terabytes. Snowflake warehouses left running burn credits.
  • Who can see what? Row/column-level security, PII masking, and where the access policy lives (Unity Catalog, Horizon, IAM).
  • How fresh is it? Load time vs. query time; the freshness SLO from week 3 is a query against the warehouse's load metadata.
  • Can we share it without copying it? Snowflake sharing and Delta Sharing let you publish a data product to another team or company as a live view.

Source: Synthesized for DPM Lab from vendor documentation and public positioning (as of 2026).

Where this shows up