Metabase is one of the best ways to give your business team data autonomy: open source, self-hosted, and with a query builder that people who don't know SQL actually use. But the gap between "spinning up Metabase in a container" and having a reliable BI platform in production is exactly where most projects get stuck — in modeling, governance, and operations.
Meta Dados deploys and operates Metabase end to end, from our own products (such as BaseCNPJ) to logistics operations. We're not a dashboard agency: we're data engineering that treats Metabase as the consumption layer on top of a solid architecture underneath.
What we deliver
- Self-hosted deployment — Metabase in Docker on your infrastructure (or ours), with sensitive data under your control — essential for LGPD.
- Modeling — materialized views in PostgreSQL and native Models as a semantic layer, so the dashboard is fast and the business can help itself. How we do it →
- Multi-unit governance — each branch/client sees only what belongs to them, by connection, groups, and permissions. The architecture →
- Multi-tenant embedding — dashboards embedded in your SaaS product, with leak-proof per-client isolation. The three modes →
- Migration — from Power BI, Tableau, or spreadsheets to Metabase, without losing metrics or history.
- Support and evolution — handover so your team can build their own questions, with Meta Dados providing ongoing specialized support.
Real cases in production
- BaseCNPJ — a self-hosted BI layer over a base of more than 62 million companies: an isolated data warehouse, materialized views, and native Models monitoring more than 1.6 million queries.
- Carrier (fleet of ~150 vehicles) — telemetry, TMS, and ERP integrated into a single Metabase, with per-branch segregation and a full handover to the internal team.
Behind these projects is serious data engineering — including a nationwide-scale enrichment methodology (~68 million entities, geolocation by exact address, corporate ownership graph).
Why Metabase — and when not
Metabase shines when the business team needs autonomy over the database with cost that scales by team size, not by data volume, and when control of the data (self-hosted, LGPD) matters. It's truly open source: no lock-in, no mandatory per-seat license.
But the tool serves the problem. Features like automatic row-level filtering (data sandboxing) and advanced interactive embedding belong to Metabase Pro/Enterprise — and we're transparent about when open source solves it and when the paid edition pays for itself. If the case calls for Power BI, Tableau, or Grafana, we say so. We recommend what makes sense for your operation, not what earns a license.
Why Meta Dados
We treat Metabase as the visible tip of an engineering effort most don't do: careful modeling, a warehouse isolated from production, validated pipelines, governance, and security by design. That's what separates a pretty dashboard on bad data from a single source of truth the leadership trusts.
Led by people who master both ends — a background in engineering (ITA) and research (PhD from USP), with the same governance and security discipline as the rest of the operation. It starts with a free assessment in 48h: you show us your sources and pain points, and we return a concrete path.
Frequently asked questions
Metabase open source or the paid version?
It depends on the requirement. Most projects do very well on open source, self-hosted Metabase. The Pro/Enterprise edition is justified when you need automatic row-level filtering (data sandboxing) or advanced interactive embedding for many clients. In the assessment we tell you clearly which one makes sense — and what can be solved in the OSS edition with the right architecture.
Do you host Metabase or does it stay on our infrastructure?
Both models work. The default is self-hosted on your infrastructure, so sensitive data doesn't leave your control (important for LGPD); when it makes sense, we operate it on ours. In both cases, Metabase runs in Docker, versioned and monitored.
Can we migrate from Power BI or Tableau to Metabase?
Yes. We migrate metrics, models, and dashboards while preserving the business definitions — "cost per km" still means the same thing. In general, migration is a good opportunity to fix the modeling underneath, not just swap the tool on top.
Can Metabase handle a large database?
It can — as long as the modeling is right. The bottleneck is rarely Metabase, but rather the database behind it. That's why we separate the analytical load into a dedicated data warehouse and materialize the heavy cuts; that's how we serve BI over bases of tens of millions of records without degrading production.