Metabase is easy to install and deceptively easy to use badly. The gap between a dashboard that answers in 300 ms and one that stalls on every filter is rarely in Metabase — it is in the data modeling underneath. This is the method Meta Dados runs in production, from our own products to logistics operations.
Why modeling decides the experience
Metabase queries the database you point it at. If every business question becomes a full scan over transactional tables, no interface tweak will save performance. Modeling means deciding, upfront: where the heavy aggregation happens, what vocabulary the business sees, and how the analytical layer stays isolated from what is live for the customer.
Materialized views: where the weight should live
The most-queried cuts — the ones that would show up in every dashboard — become materialized views in PostgreSQL, pre-aggregated and indexed. Metabase reads the finished result instead of recomputing on every click.
- Materialize what is expensive and repeated (aggregations by period, region, category), not the whole table.
- Set the refresh cadence by the freshness the business needs — from minutes to a daily cycle.
- Index the filter and join columns the dashboard actually uses.
Native Models: the semantic layer business users understand
On top of the views, Metabase Models form the semantic layer: they rename columns into business vocabulary, hide technical keys, type fields (currency, date, city) and become the starting point of the query builder. The analyst builds a question about "Trip" or "Company", not about a fact table with a cryptic name.
Isolate analytical from transactional
Analytical queries and the production API should not fight over the same database. We use a dedicated data warehouse — a replica or a separate database — for the BI workload. The operation serving customers never feels the weight of a heavy report, and the BI layer can be modeled freely without risking what is live.
Maintenance: refresh, tests and evolution
Modeling is not a one-off delivery. Pipelines validate completeness and consistency on every load, view refresh is monitored, and new Models appear as the business asks new questions. That is what keeps self-service alive after the handover.
Frequently asked questions
Do I need a separate data warehouse to use Metabase?
For small volumes, no — Metabase can query your database directly. But as soon as analytical queries start competing with the operation (slowness, locks), moving analytics to a dedicated warehouse stops being a luxury and becomes what keeps both BI and production from stalling.
Does a Metabase Model replace a database view?
No, they complement each other. The materialized view solves performance and pre-aggregation in the database; the Model solves semantics and usability in Metabase. Together they deliver a dashboard that is both fast and understandable by the business team.