dbt + BigQuery: the analytics stack we keep recommending

When a client asks us to help them build their analytics stack, we almost always start by asking three questions: How much data do you have? How often does it change? Who needs to query it? The answers vary. The recommendation is usually the same: BigQuery for storage and compute, dbt for transformation, and Looker or Metabase for consumption.

This isn't dogma. It's the outcome of seeing what breaks at scale — and this stack breaks gracefully.

Why BigQuery

BigQuery's pricing model — pay for what you query, storage is cheap — aligns almost perfectly with how analytics workloads actually behave. Most queries scan a small fraction of your data most of the time. The separation of storage and compute means you can have a petabyte-scale warehouse without paying for petabyte-scale compute when you're running three reports a day.

The operational simplicity is underrated. No clusters to size, no vacuuming, no index tuning. For most teams, the time saved on database administration alone justifies the choice.

Why dbt

dbt brought software engineering practice to the analytics layer — and the industry needed it badly. Version control, testing, documentation, and modular transformations expressed in SQL that anyone on the data team can read. The `ref()` function alone — which lets you build a DAG of interdependent models without writing a scheduler — is worth the adoption cost.

• Write transformations in SQL, not Python or Spark jobs
• Lineage is automatic — dbt generates a full DAG from your refs
• Tests on your models catch data quality issues before they reach dashboards
• Documentation lives next to the code, not in a separate wiki that goes stale

When this stack is the wrong choice

BigQuery and dbt are not the right answer when your data volumes are small and your queries are transactional. If you're running a reporting layer over a Postgres database with 50GB of data, you don't need a data warehouse — you need a few good read replicas and materialised views. Adding BigQuery to that stack introduces latency, cost, and operational complexity with no upside.

The best analytics stack is the one your team will actually maintain. Start with what you know, migrate when you feel the ceiling.

The teams we've seen struggle with this stack are the ones who adopted it before they had the data volumes or query patterns to justify it. Premature scaling in data infrastructure is just as costly as premature scaling in application infrastructure. Match the tool to the problem you have today, with some headroom for where you're going.