Metabase + BigQuery/Snowflake optimisation tips

Introduction: Why Metabase + BigQuery/Snowflake optimisation matters in 2025

If your South African business is scaling up self-service analytics on Metabase + BigQuery/Snowflake, you are probably starting to feel the pain of slow dashboards and rising cloud data warehouse bills. In 2025, cloud cost optimisation and BI performance tuning are among the most searched topics in data engineering, driven by teams trying to control spend while keeping stakeholders happy with fast insights.[1][2]

Metabase is designed to be simple for business users, but performance and cost are ultimately governed by how you configure BigQuery or Snowflake, how you model your data, and how you design dashboards.[3][4] This guide focuses on practical, actionable Metabase + BigQuery/Snowflake optimisation tips tailored for South African teams building analytics on top of modern cloud warehouses.

1. Start with the data warehouse: tune BigQuery and Snowflake first

1.1 Structure data for the questions Metabase users actually ask

Metabase’s own documentation recommends shaping your warehouse around real analytics questions: denormalise heavily queried data, pre-join common dimensions, and materialise summary tables.[3][4] Instead of letting Metabase hit raw, highly normalised tables, create:

• Dashboard-optimised tables (e.g. daily sales by region, product, and channel)
• Wide denormalised fact tables for common reporting journeys
• Materialised views to pre-aggregate expensive metrics[4]

1.2 BigQuery: partition, cluster, and reduce data scanned

On BigQuery, performance and cost are tightly linked to how much data is scanned per query.[2] For Metabase dashboards that slice by date, region, or product:

• Partition big fact tables by date (e.g. event_date, order_date).[2]
• Cluster by the dimensions you filter by most (e.g. region, product_category, customer_segment).[2]
• Always select only the columns you need – avoid SELECT * from Metabase SQL questions.[2]

-- Example: dashboard-optimised table for Metabase
CREATE OR REPLACE TABLE `project.dataset.sales_dashboard_optimized`
PARTITION BY order_date
CLUSTER BY region, product_category, customer_segment AS
SELECT
  o.order_id,
  o.order_date,
  o.revenue,
  c.customer_segment,
  c.region,
  p.product_category
FROM `project.dataset.orders` o
JOIN `project.dataset.customers` c USING (customer_id)
JOIN `project.dataset.products` p USING (product_id);

You can also enforce require_partition_filter = true on large partitioned tables so mis-configured Metabase questions cannot scan entire tables accidentally.[2]

ALTER TABLE `project.dataset.sales_partitioned`
SET OPTIONS (
  require_partition_filter = true
);

1.3 Snowflake: right-size warehouses and use auto-suspend

Snowflake charges primarily on compute credits, so right-sizing your virtual warehouses and limiting idle time are critical for Metabase workloads.[1]

• Use XS or S warehouses for BI/Metabase queries first; only scale up when you see sustained high utilisation.[1]
• Set aggressive AUTO_SUSPEND on Metabase-facing warehouses (e.g. 60 seconds) to cut idle cost.[1]
• Enable resource monitors with spend alerts for BI warehouses so runaway Metabase queries don’t blow your budget.[1]

ALTER WAREHOUSE analytics_wh
SET
  WAREHOUSE_SIZE = 'XSMALL',
  AUTO_SUSPEND = 60,
  AUTO_RESUME = TRUE;

Snowflake’s 24‑hour result cache also gives you “free” repeated queries when dashboards or pulses run with identical SQL, so standardise queries where possible.[1]

2. Metabase configuration tips for BigQuery and Snowflake

2.1 Separate connections for different workloads

Create dedicated Metabase database connections for:

• Interactive analytics (ad-hoc questions, drill-downs)
• Executive dashboards (scheduled refreshes)
• Heavy reporting (month-end, regulatory, exports)

Point each connection to an appropriate BigQuery dataset / Snowflake warehouse so spiky workloads don’t degrade business-critical dashboards.[3][4]

2.2 Control sync & scan behaviour

On large warehouses, Metabase’s automatic schema sync and field value scanning can put unnecessary load on BigQuery or Snowflake.[3]

• Reduce sync frequency to off-peak hours.
• Disable “searchable values” on extremely large, high-cardinality columns.
• Mark non-essential tables as “hidden” so users don’t accidentally query raw, massive datasets.[3]

2.3 Use filters and summarise blocks instead of raw table queries

Metabase encourages users to filter and summarise data rather than pulling full tables.[3][4] Train your users to:

• Always add a date range and relevant dimension filters.
• Use aggregations (sum, count, avg) instead of raw rows for dashboards.
• Avoid “table” visualisations on huge datasets unless heavily filtered.

3. Dashboard design: make Metabase fast for end users

3.1 Reduce heavy cards and limit simultaneous queries

Dashboards that issue many heavy queries at once will feel slow even on powerful warehouses.[4]

• Keep executive dashboards to a focused set of KPIs rather than dozens of cards.
• Split massive dashboards into thematic ones (Sales, Marketing, Finance) with drill‑throughs.[4]
• Where possible, reuse the same question on multiple dashboards to benefit from caching.

3.2 Pre-aggregate for the grain you need

If your leadership only needs daily or weekly views, avoid querying at transaction or event level from Metabase.[4] Instead:

• Create daily aggregates (e.g. daily_revenue_by_region) in BigQuery/Snowflake.
• Point dashboard cards to those aggregate tables.
• Reserve raw-level tables for drill‑downs or specialised analysis.

3.3 Use parameters & templates for reusable queries

Metabase’s SQL questions support parameters and filters. Build reusable parameterised queries that:

• Encourage filtering by partitioned/clustered columns in BigQuery.
• Leverage consistent, cache-friendly patterns in Snowflake.

SELECT
  order_date,
  region,
  SUM(revenue) AS total_revenue
FROM analytics.sales_dashboard_optimized
WHERE order_date BETWEEN {{start_date}} AND {{end_date}}
  [[AND region = {{region}}]]
GROUP BY order_date, region
ORDER BY order_date;

4. Cost optimisation tactics for South African teams

4.1 Monitor warehouse spend by BI tool

On Snowflake, use query tags or dedicated warehouses to attribute cost to Metabase-specific workloads and catch anomalies early.[1]

ALTER SESSION SET QUERY_TAG = 'tool=metabase,env=prod';

SELECT QUERY_TAG, SUM(CREDITS_USED) AS credits
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE START_TIME > DATEADD(day, -7, CURRENT_TIMESTAMP())
GROUP BY QUERY_TAG;

For BigQuery, track bytes processed and slot consumption for Metabase service accounts. Set budget alerts in your GCP project so sudden dashboard usage spikes don’t surprise finance.

4.2 Align data retention with local complianc