KPI dashboards are loading way too slow - anyone else?

That query pattern is a good clue. Counting distinct users over 30 days of session data can get heavy fast, even with 50k visitors, because each visitor might have many sessions.

Start by checking if there's an index on the date column in your sessions table. If not, adding one is the quickest win. You can also ask Metabase to show you the slow query log, which often points straight to the problem.

Beyond that, you might consider pre-aggregating that daily campaign data into a separate summary table that you update once a day. It's a common step when dashboards start to slow down.

Great point about pre-aggregating. That's often the only way to make user-facing dashboards feel snappy.

Just want to add that when you create that summary table, make sure you also model it for how people *use* the dashboard. For example, if your team always filters by region or campaign type, bake those dimensions into the summary. It saves a ton of processing time versus trying to filter on the fly.

We hit this wall last year and moving to a daily-aggregated table cut load times from ~25 seconds to under 2. The trick is setting up a reliable refresh schedule so the data stays useful.

That query is scanning every session row from the last 30 days. Counting users over a rolling window is always a resource hog.

Indexing the date column is a band-aid. You need to measure actual query execution time in PostgreSQL with EXPLAIN ANALYZE. Show the plan.

The real issue is your data model. You're asking for aggregated metrics on-demand. Build a daily aggregated table. Refresh it with a cron job. Serve the dashboard from that.

Yeah, that sample query is a classic culprit. While indexes and summary tables help a lot, I'd also check if your Metabase questions are using its native query builder or if you've written custom SQL. The builder sometimes generates less efficient queries, especially with joins.

One thing that bit us was having a dashboard with, say, 10 cards that all looked at the last 30 days. Each one was firing its own query simultaneously, hammering the database. We started using Metabase's dashboard filters with a single date parameter, so all cards reuse the same filtered dataset. It cut down the concurrent load significantly.

Also, peek at your sessions table growth. 50k visitors can easily turn into millions of session rows over time. A simple `COUNT` on that table can start to drag.

The dashboard filter tip is spot on - we saw the same improvement. But that only works if every card is pulling from the same underlying table.

If you've got a dashboard mixing data from sessions, orders, and ad spend, the shared filter doesn't help and you're back to concurrent queries. That's where you need to push aggregates to a single summary table first, *then* build the dashboard.

Yeah, that's the catch with dashboard filters. They're magic when everything comes from one place, but fall apart with mixed sources.

We tried building a "marketing overview" dashboard last month with cards from sessions, ad_spend, and conversions. Even with a shared date filter, it felt slow because Metabase was still hitting three different tables at once. Ended up creating a separate reporting schema with a single denormalized table that gets populated nightly. Now the whole dashboard is snappy.

How do you handle the nightly refresh though? Do you use a simple cron with a SQL script, or something like an Airflow DAG? I'm still figuring out the orchestration part.

Good point about dashboard filters cutting down concurrent queries. That worked for us too.

But I've noticed Metabase sometimes gets confused if the date column has a different name in each table, even when the filter is supposed to apply to all. Had to rename a few columns to get it to work smoothly.

What would you recommend if your tables are in different schemas?

Yeah, that's a classic query pattern that'll get you every time. The problem is you're asking the database to scan and count raw session rows on the fly, which gets heavier as your data grows.

First, check if that `date` column is indexed. If not, add one. That's the quickest fix you can do right now.

But the real fix is setting up a daily summary table. Schedule a job to run once a day that populates a new table with pre-aggregated counts, like `daily_campaign_summary`. Your dashboard query then becomes a simple `SELECT * FROM daily_campaign_summary WHERE date > ...`, which is almost instant.

You can start with a simple cron job running a SQL script. It's less intimidating than bringing in a full orchestration tool.

Spot on about the cron job being less intimidating. That's the right first step. But people always forget the second half, which is making that job robust enough to actually trust.

A simple cron SQL script will fail silently when the source table is locked or a column gets renamed. At a minimum, you need to log its runs and have some basic error handling that sends an alert. Otherwise you'll end up serving a dashboard from stale data for two weeks before anyone notices.

The jump from cron to Airflow or Prefect is huge, but you don't need to make it. Stick a `BEGIN...EXCEPTION...END` block in your script and pipe the cron output to a file. Check that file daily. It's ugly, but it's a start.

That query is the problem. It's a full table scan every time.

Indexing the date column is a start, but you need to see the actual query plan. Run it with EXPLAIN ANALYZE and you'll see the cost.

The real fix is a daily rollup table. Run a nightly job to summarize the counts. Your dashboard query then becomes a simple lookup.

That sample query is a textbook example of where performance issues begin. You've correctly identified the core pattern, which is a real-time aggregation scanning a large window of raw data.

The suggestions about indexing and summary tables are sound, but there's a diagnostic step before you jump into engineering solutions. In Metabase, check the "x-ray" feature on that question or the underlying table. It often highlights if a query is scanning an unusually high number of rows. This can confirm whether the slowness is isolated to this specific query logic or if it's part of a broader dashboard problem where multiple cards are firing similar heavy queries at once.

A simple but often overlooked point: ensure your Metabase instance itself has adequate resources. A dashboard loading slowly isn't always the database's fault. If the Metabase application server is under-provisioned, it can bottleneck while processing and rendering the results, even if the database query finishes moderately quickly.

That's a great point about mixing data sources. So if I want a dashboard with, say, user logins and support tickets, I'd need to combine them into one summary table first for the shared filter to work properly?

How do you usually handle joining data from different systems for those nightly summary tables, especially if they're in different databases?

Everyone's jumping to indexing and rollups. But the first thing I'd check is whether Metabase is generating a dozen versions of that same basic query for every card on your dashboard. It loves to do that.

Look at your dashboard in edit mode. If each card has its own date filter, you're hammering the database with near-identical heavy scans. Combine them into a single dashboard filter first. It's a two minute fix that might cut your load time in half.