Business Intelligence - Metabase
Metabase is easy to start.
Hard to operate at scale.
We build the data models, question logic, and permission structures that keep Metabase from turning into a dashboard graveyard - so your team gets answers they can trust, not charts they have to second-guess.
Get your free AI roadmap.
See exactly where AI and automation fit your Metabase stack - delivered to your inbox. No call required.
Free, personalized roadmap. We never share your data.
$250M+
Pipeline generated
42%
Average pipeline growth
18.3%
Average budget saved
Results from actual client engagements.
Trusted by the teams we build with
Self-serve BI only works when the underlying data model is sound
Metabase makes it genuinely easy for non-technical users to build questions and dashboards - until it doesn't. The failure mode is predictable: someone builds a question off the wrong table, a filter silently returns no rows, two dashboards show different revenue numbers for the same period, and now your leadership team is debating which chart to believe instead of making a decision. Without a clean semantic layer, proper field metadata, and enforced data permissions, Metabase's self-serve promise collapses into a trust problem. The tool didn't fail - the foundation was never built.
Revenue Institute goes into your Metabase instance and your underlying data warehouse together. We audit your existing questions and models, rebuild the table relationships and field descriptions that power the GUI query builder, set up Collections and permission groups that match how your org actually works, and write or clean up the SQL models that sit behind your most critical dashboards. The result is a Metabase environment where self-serve actually works because the guardrails are in place before users start clicking.
What we do with Metabase
What we build inside your Metabase
Data model and metadata cleanup
Metabase's GUI query builder is only as good as the field metadata behind it. We audit your connected database or warehouse, set display names, add descriptions, configure field types and semantic categories, and hide tables that should never appear in self-serve queries. This is the work most teams skip and then wonder why users can't find anything.
SQL question and model architecture
For metrics that can't be built in the GUI - cohort logic, multi-step funnels, blended revenue calculations - we write and document native SQL questions and Metabase Models. Models act as a governed layer that other questions can build on top of, so complex logic lives in one place instead of being copy-pasted across twenty dashboards.
Dashboard design and filter logic
We build the dashboards your operators and executives actually use: linked filters, cross-filter click behavior, drill-through questions, and parameter chaining that makes a single dashboard answer multiple follow-up questions without requiring a new chart for every slice. We also set up dashboard subscriptions and alerts so the right people get the right numbers without logging in.
Collections, permissions, and governance
Metabase's Collections and Groups system can enforce who sees what data and who can edit versus only view. We map your org structure to permission groups, lock down sensitive dashboards, and set up a folder hierarchy that doesn't become chaos six months later when ten more people have editor access.
Warehouse and source connection optimization
A slow Metabase is usually a warehouse problem, not a Metabase problem. We review your query patterns, identify dashboards running full table scans, work with your data team on materialized views or pre-aggregated tables, and configure Metabase's caching settings so frequently-viewed dashboards don't hammer your warehouse on every load.
Embedded analytics and public sharing setup
Metabase's signed embedding feature lets you surface dashboards inside your own product or customer portal without exposing your full BI environment. We configure the embedding parameters, set up row-level security so each customer sees only their own data, and handle the JWT signing logic - so you ship customer-facing analytics without building a custom reporting layer from scratch.
Our framework
How a Metabase engagement runs
Audit and diagnosis
We connect to your Metabase instance and your underlying data source together. We inventory existing questions, models, and dashboards, identify broken or misleading logic, map your current permission structure, and document where the gaps are. You get a written findings report before we write a single line of SQL or move a single dashboard.
Build and restructure
We execute against the findings: rebuild the data model layer, write or refactor SQL models, reorganize Collections, reconfigure permissions, and rebuild or replace the dashboards that matter most to your business. We work in a staging environment where possible and document every change so your team understands what was done and why.
Handoff and enablement
We don't hand you a finished product and disappear. We run working sessions with the people who will maintain Metabase day to day, document naming conventions and governance rules, and set up a lightweight process for adding new questions and dashboards without breaking what's already working. Ongoing support is available if you need it.
Why Metabase works - and where it breaks down in practice
Metabase occupies a specific and legitimate position in the BI landscape. It is genuinely easier to deploy than Tableau or Power BI, its GUI query builder is approachable for operations and finance users who have no SQL background, and its open-source core means mid-market companies can get real dashboards running without a six-figure analytics budget. Those are real advantages, not marketing copy. The problem is that ease of deployment is not the same as ease of operation. Metabase's flexibility - the ability for any user with editor access to build questions off any connected table - is exactly what causes the trust collapse that most teams experience within twelve to eighteen months of going live. When there is no enforced semantic layer, no naming convention, and no permission structure that reflects how the business actually works, you end up with dozens of questions that look authoritative and return different numbers. At that point the tool has not failed. The implementation was just never finished.
The specific Metabase features that prevent this outcome are real and available, but most teams never configure them properly. Field metadata - display names, semantic field types, field descriptions - powers the GUI query builder and determines whether a non-technical user can find the right field or accidentally joins on the wrong key. Metabase Models create a governed abstraction layer on top of your warehouse tables, similar in concept to a dbt mart, that lets you expose clean, pre-joined, pre-filtered datasets to business users without giving them access to raw tables. Data sandboxes enforce row-level security so a regional sales manager sees only their territory's pipeline. Collections and Groups control who can edit versus view, and which dashboards are official versus experimental. None of these are difficult to configure once you understand them. They are simply skipped in the rush to get dashboards in front of stakeholders.
What production-grade Metabase actually looks like
A well-operated Metabase environment has a clear separation between the governed layer and the exploration layer. Official dashboards live in curated Collections with restricted edit permissions. The questions powering those dashboards are built on top of Metabase Models, not raw tables, so when the underlying warehouse schema changes, there is one place to update the logic rather than hunting through fifty individual questions. SQL models are documented with descriptions that explain what the model represents, what its grain is, and what filters are pre-applied. Field metadata is complete enough that a new employee can open the query builder and find the right table and field without asking anyone. Caching is configured on high-traffic dashboards so the warehouse is not queried on every page load during the morning standup rush. Alerts and dashboard subscriptions are set up so the people who need numbers get them pushed to email or Slack rather than having to remember to log in.
The embedded analytics use case adds another layer of operational complexity. When Metabase dashboards are surfaced inside a customer-facing product, the signed embedding configuration, the JWT parameter passing, and the sandbox filter logic all have to be correct simultaneously or customers see either an error or, worse, each other's data. Getting this right requires understanding both the Metabase configuration and the application layer that generates the signed tokens. Revenue Institute has worked through this setup enough times to know where it breaks and how to test it properly before it goes in front of customers. If your team is evaluating Metabase for embedded reporting, the architecture decisions you make at the start - which plan, how sandboxes are keyed, how tokens are generated - determine whether the implementation is maintainable or a recurring source of incidents.
We're vendor-agnostic
Other Business Intelligence platforms we specialize in
Not sure Metabase is the right fit? We implement and optimize these too - and we'll tell you honestly which one fits your business.
Metabase questions, answered
We already have Metabase set up. Do you work with existing instances or only greenfield?
Mostly existing instances. The majority of our Metabase work is rescuing environments that were set up quickly and grew without structure. We audit what's there, keep what's working, and fix what isn't. A greenfield build is faster, but the diagnostic work on an existing instance is where we usually find the most immediate value - broken questions, misleading filters, and permission gaps that have been silently causing problems for months.
What data warehouses and databases does Metabase connect to, and does that affect the engagement?
Metabase connects natively to most common sources: PostgreSQL, MySQL, BigQuery, Snowflake, Redshift, SQL Server, and others. The warehouse choice affects how we approach query optimization and model design. Snowflake and BigQuery, for example, have different caching and compute behaviors than a self-hosted Postgres instance. We account for your specific source when designing the model layer and recommending caching or materialization strategies.
Can Metabase handle the reporting complexity our business actually needs, or will we hit a ceiling?
Metabase is genuinely capable for most mid-market reporting needs when the foundation is right. The GUI builder handles straightforward aggregations and filters well. Complex logic - multi-step attribution, rolling windows, blended datasets - lives in SQL models that Metabase then exposes as governed tables. The ceiling most teams hit is a data model problem, not a Metabase product limitation. We help you figure out which is which before you decide to switch tools.
How does Metabase's row-level security work, and can it handle multi-tenant reporting?
Metabase supports sandboxing at the row level using its data sandboxes feature, available on paid plans. You define a filter condition tied to a user attribute - such as company ID or region - and Metabase applies it automatically when that user runs any question against that table. For embedded analytics serving multiple customers, you pass the attribute via signed JWT tokens. We configure and test the full sandboxing setup so each user or tenant sees exactly their data and nothing else.
What Metabase plan do we need for the features you're describing?
Several of the governance and embedding features - data sandboxing, signed embedding, SSO, advanced permissions - require Metabase Pro or Enterprise. The open-source and Starter tiers cover basic dashboards and questions but lack the controls that make self-serve safe at scale. We'll tell you honestly which plan your use case requires before the engagement starts, and we don't earn anything on your Metabase subscription.
How long does a typical Metabase engagement take?
An audit and rebuild of an existing mid-market Metabase instance typically runs four to eight weeks depending on the number of data sources, the complexity of existing questions, and how much SQL model work is needed. A focused embedded analytics setup or a specific dashboard rebuild can be shorter. We scope it after the audit so you know what you're committing to before work begins.
Our data team owns the warehouse. How do you work alongside them?
We work with your data team, not around them. They own the warehouse and the transformation layer - whether that's dbt, raw SQL, or something else. We work at the Metabase layer: how the warehouse is exposed to business users, how questions are structured, and how permissions are enforced. Where warehouse-side changes are needed for performance or model correctness, we write the specifications and your team executes them, or we pair directly if that's preferred.
Make Metabase actually earn its license fee.
Tell us your two biggest bottlenecks and we'll send back a custom Metabase implementation blueprint - by email, no call required.
- A specific plan for your Metabase stack, not a generic pitch
- Reviewed by an operator, delivered to your inbox
- No call required, no obligation
Get your free AI roadmap.
Free and personalized. We never share your data.
Prefer to talk first? Book a strategy call.