Business Intelligence - Metabase
Metabase is easy to start, but 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 Metabase AI Opportunity Assessment.
See exactly where AI and automation fit your business - delivered to your inbox. No call required.
Free, personalized assessment. We never share your data.
Operators and teams we've worked with
Self-serve BI only works when the underlying data model is sound
Metabase makes it easy to build questions and dashboards - until it doesn't. The failure mode is predictable: someone builds a question off the wrong table, two dashboards show different revenue for the same period, and leadership debates which chart to believe. Without a clean semantic layer, field metadata, and enforced permissions, self-serve collapses into a trust problem. The tool didn't fail - the foundation was never built.
Revenue Institute works inside your Metabase instance and your warehouse together. We audit your questions and models, rebuild the table relationships and field descriptions that power the query builder, set up Collections and permission groups that match how your org works, and clean up the SQL behind your critical dashboards. The result: self-serve works because the guardrails are in place first.
What we do with Metabase
What we build inside your Metabase
Data model and metadata cleanup
The query builder is only as good as the field metadata behind it. We audit your warehouse, set display names and descriptions, configure field types and semantic categories, and hide tables that shouldn't appear in self-serve. Most teams skip this work.
SQL question and model architecture
For metrics the GUI can't build - cohort logic, multi-step funnels, blended revenue - we write and document native SQL questions and Metabase Models. Models act as a governed layer other questions build on, so complex logic lives in one place.
Dashboard design and filter logic
We build the dashboards your operators and executives actually use: linked filters, drill-through questions, and parameter chaining that lets one dashboard answer multiple follow-ups without a new chart per slice. Subscriptions and alerts get people the numbers without logging in.
Collections, permissions, and governance
Collections and Groups enforce who sees what data and who can edit versus view. We map your org to permission groups, lock down sensitive dashboards, and set up a folder hierarchy that stays sane as you grow.
Warehouse and source connection optimization
A slow Metabase is usually a warehouse problem. We review query patterns, find dashboards running full table scans, work with your data team on materialized tables, and configure caching so the warehouse isn't hammered on load.
Embedded analytics and public sharing setup
Signed embedding lets you surface dashboards inside your own product without exposing your full BI environment. We configure the embedding parameters, set up row-level security so each customer sees only their data, and handle JWT signing - so you ship customer-facing analytics fast.
Our framework
How a Metabase engagement runs
Audit and diagnosis
We connect to your Metabase instance and data source together, inventory existing questions, models, and dashboards, identify broken or misleading logic, and map your permissions. You get a written findings report before we write a line of SQL.
Build and restructure
We execute against the findings: rebuild the data model layer, write or refactor SQL models, reorganize Collections and permissions, and rebuild the dashboards that matter most. We document every change so your team knows 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 maintain Metabase day to day, document naming and governance rules, and set up a lightweight process for adding questions without breaking what works.
Why Metabase works - and where it breaks down in practice
Metabase holds a legitimate position in the BI landscape. It is easier to deploy than Tableau or Power BI, its GUI query builder is approachable for finance and operations users with no SQL background, and its open-source core lets mid-market companies run real dashboards without a six-figure budget. But deployment is not operation. Its flexibility - any user with editor access can build questions off any table - is what causes the trust collapse most teams hit within a year or two. With no enforced semantic layer or permission structure, you get dozens of authoritative-looking questions that return different numbers. The tool has not failed; the implementation was never finished.
The features that prevent this are real and available, but most teams never configure them. Field metadata - display names, semantic field types, descriptions - powers the query builder and determines whether a non-technical user finds the right field or joins on the wrong key. Metabase Models create a governed layer on top of your warehouse tables, like a dbt mart, exposing clean, pre-joined datasets without raw-table access. Data sandboxes enforce row-level security so a regional sales manager sees only their territory. Collections and Groups control who can edit versus view, and which dashboards are official versus experimental. None of this is hard - it is simply skipped in the rush to ship dashboards.
What production-grade Metabase actually looks like
A well-operated environment separates the governed layer from the exploration layer. Official dashboards live in curated Collections with restricted edit permissions. The questions powering them are built on Metabase Models, not raw tables, so a schema change means updating logic in one place rather than fifty questions. SQL models are documented with their grain and pre-applied filters. Field metadata is complete enough that a new employee can open the query builder and find the right table without asking. Caching is configured on high-traffic dashboards so the warehouse isn't queried on every load. Alerts and subscriptions push numbers to email or Slack instead of waiting for logins.
The embedded analytics use case adds complexity. When dashboards are surfaced inside a customer-facing product, the signed embedding config, the JWT parameter passing, and the sandbox filter logic all have to be correct at once or customers see an error or, worse, each other's data. Getting it right requires understanding both the Metabase configuration and the application layer that generates the tokens. Revenue Institute has done this enough times to know where it breaks and how to test it first. If you are evaluating Metabase for embedded reporting, the decisions you make at the start - which plan, how sandboxes are keyed, how tokens are generated - determine whether it stays maintainable or becomes a recurring source of incidents.
We're vendor-agnostic
Other Business Intelligence & Analytics 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 keep.
Stop paying for a tool your team routes around. Start running on one they trust.
Tell us about your firm and we'll send back your Metabase AI Opportunity Assessment - by email, no call required.
- A specific plan for your business, not a generic pitch
- Built from a real read of your business, delivered to your inbox
- No call required, no obligation
Get your free Metabase AI Opportunity Assessment.
Free and personalized. We never share your data.
Prefer to talk first? Book a strategy call.