You’ve created a dashboard that shows the right things but:
Our articles on Metabase at scale and making dashboards faster will help set the stage for the steps below.
If you get an error message that says “Your question took too long”, go to Troubleshooting timeouts.
Root cause: Metabase is not an island, complete unto itself, so if the dashboards and the cards it shows haven’t changed, the slowdown is probably due to a change in the environment.
Steps to take:
Root cause: When Metabase displays a dashboard, it re-runs all of the questions. We do our best to do this concurrently, but a dashboard with a hundred cards is going to be slower than one with a single question. And if your dashboard contains filters, then each time someone changes a filter setting, all of the cards that depend on it have to re-execute.
Steps to take:
Note: this is a good way to design dashboards even when there aren’t performance issues. A dashboard with a hundred cards isn’t just slow, it’s also hard to understand. Breaking things up improves comprehension as well as performance. Please read this article for tips on making dashboards more performant, and this one for designing good dashboards in general.
Root cause: Metabase is usually not the only application using your database, and you may not be the only person using Metabase. If someone else has opened a dashboard that launches a couple of dozen long-running queries, everyone else may then have to wait until database connections become free.
Steps to take:
Note: you may also see your database being overloaded if you’re using the same database for Metabase’s app database and for your own data. We strongly recommend that you don’t do this in a production system or if you have more than a handful of users. If you are doing this, set up a second database for Metabase’s own use.
Root cause: Joining half a dozen tables, each with a few million rows, simply takes a lot of time. While we do our best to create fully-formed SQL queries from graphical questions, SQL snippets, and questions that use other questions as starting points, it’s a hard problem—particularly across as many databases as we support.
Steps to take:
psql
. (If you have written the question in SQL you can just copy and paste it.) If the query runs noticeably faster this way than it does when you run it through Metabase, the problem is almost certainly one of the ones described above.Root cause: Metabase saves questions created graphically in Metabase Query Language (MBQL), then translate MBQL into queries for particular back-end databases. It creates the most efficient queries it can, but for the sake of portability, it doesn’t take advantage of every database’s idiosyncracies, so sometimes a GUI question will be slower than the equivalent hand-written SQL.
Steps to take:
Root cause: If the database schema is poorly designed, questions cannot run quickly.
Steps to take: The difference between OLTP and OLAP, and how to design database schemas to support them, are out of scope for this troubleshooting guide. In brief, you must look at the data schema of the data warehouse, or ask the database administrator whether the database is designed for online transaction processing (OLTP) or online analytical processing (OLAP). Metabase is an OLAP application; if the database schema is designed for OLTP, you may need to create views that reorganize the data.
Similarly, you probably don’t need indexes for simple tables with a few tens of thousands of rows, but you almost certainly do if you have a few million rows. All of this is very dependent on the underlying database: Redshift can easily handle millions of rows with thousands of columns, but MySQL or PostgreSQL may require a star schema designed for OLAP to deliver the performance you need.
Root cause: By default caching is disabled so that we always re-run every question. However, if your data is only being updated every few seconds or minutes, you will improve performance by enabling caching. Note that:
Steps to take:
Root cause: Low performance can be caused by incorrect typing of columns, e.g., by storing a numeric value as a string. When this happens, the query converts values on the fly each time it runs. (Even a handwritten query will be slow if it has to do this conversion every time.)
Steps to take:
Root cause: You can embed the charts and dashboards you create in Metabase in other websites in several ways. If people have to authenticate in order to view the dashboard in that other website, then you can pass their credentials to Metabase and use them to filter data. If they don’t have to authenticate, though, then you can’t do that, which means you may return a larger result set than you expect.
Steps to take: This is almost always a result of a design error—if are only allowed to see a subset of the data when they’re in Metabase, they shouldn’t be able to see more (or all) of the data when the same question is displayed in an external web page. Please read the introduction to embedding to see how you can pass credentials from your site to Metabase.
Root cause: If you run Metabase or the underlying data warehouse on a ten-year-old machine with only 1 GByte of RAM, it may not be able to keep up with your demands.
Steps to take:
Root cause: If you save a question that has never been executed, Metabase runs the question while saving it, which can make the UI look frozen.
Steps to take: This is a bug and we are working to fix it. Until it’s corrected, the workaround is to run the question before saving it. However, it’s very likely that the root cause is one of the more common problems described above.