"Each branch manager can only see their own unit; the board sees everything." It is a common requirement — and the first reaction is usually "then we need the paid version". Not always. It can be solved on open-source Metabase with data architecture, and this article shows how (and when OSS really is not enough).
The problem: many managers, one dashboard, data that must not mix
In a multi-unit operation, the same dashboard must show different realities to different people. If the Curitiba branch manager opens the panel and sees São Paulo numbers, you have a trust problem — and sometimes a contractual one.
The OSS approach: separate at the data, not at the filter
In open source, solid segregation happens before Metabase, in the data warehouse. Each branch becomes an isolated connection — its own schema (or its own database) with only its data. Metabase connects to each one as a separate source.
- One schema per unit, populated at load time with that branch cut.
- One connection (Database) in Metabase per schema.
- Dashboards mirrored per connection, or a consolidated one only for those allowed to see everything.
Groups and collection permissions
With the connections separated, Metabase ties people to data through groups and collection permissions: the "Curitiba Branch" group only accesses the Curitiba connection and collections; the "Board" group accesses the consolidated view. It is simple, auditable access management, native to OSS.
When OSS is not enough: data sandboxing
Be honest about the limit. If you need a single question that automatically filters rows based on who is logged in — without duplicating dashboards or separating connections — that is data sandboxing, and it only exists in Metabase Pro/Enterprise. For dozens of branches with identical dashboards, sandboxing pays for itself. For a handful of units whose data can already be separated at load time, OSS handles it comfortably.
Governance checklist
- Is sensitive data separated before Metabase (schema/connection per unit)?
- Does each group access only its own connection and collections?
- Is there a restricted, consolidated group for the board?
- Are permissions reviewed when someone changes roles?
Frequently asked questions
Can you do row-level security on open-source Metabase?
Not natively — automatic per-row filtering based on the logged-in user (data sandboxing) is a Metabase Pro/Enterprise feature. In open source, you achieve the same practical effect by separating data per schema/connection and tying groups and collections to each. It works very well when the number of units is manageable.
How many connections can Metabase handle?
Many more than most operations need. The bottleneck is rarely the number of connections and more the database behind them; that is why separating by schema in a single well-indexed warehouse is usually simpler to operate than dozens of standalone databases.