What a Metabase implementation covers and when teams commission it
A Metabase implementation is the planned setup of a self-hosted analytics layer in infrastructure you control. Its scope runs from the application database that stores Metabase's own configuration, questions and users, through the data source connections that let people query your warehouses and operational databases, to the permissions model, collections, starter dashboards, identity integration and user training that determine whether analysts actually use it. Each of these is a separate decision, and the plan should name an owner for each one before installation starts.
Teams usually commission this work for one of three reasons. The first is a pilot that has to become production, where the pilot's embedded H2 application database and ad hoc connections need to be replaced with a supported setup. The second is a move off that embedded H2 database, which Metabase ships for demos and recommends replacing with PostgreSQL for production. The third is a need for governed access to several databases at once, where row and column level permissions, group mapping and auditing become requirements rather than nice-to-haves. Confirm which of these features your chosen plan includes before you assume they are available, since SSO, row and column level permissions and auditing are tied to the Pro and Enterprise plans on Metabase's pricing page.
On the build or buy question, the short answer is that a team with a database administrator, an identity engineer and someone who owns analytics governance can often build a basic installation in-house. Teams that lack one of those skills, or that need the permissions model and training finished on a fixed date, more often bring in a partner for the design and build and keep the operation internal. Ask any partner to show the scope as a written list of components, owners and acceptance checks.
Boundaries: upgrades, migration from another BI tool or between servers, customization, embedding and cost of ownership each have their own pages. They are referenced here only so you know where this plan stops. Most of the sizing and cost questions in this section are answered on those pages.
What the implementation includes and what you receive
A Metabase rollout breaks into a small set of work packages, each ending in a document or session your team keeps. Use the list below to compare a partner quote with what your own team would build.
Hosting and JAR or container deployment
The scope covers installing Metabase as a JAR or container on servers, containers or virtual machines in your environment, with a service definition, TLS termination and a configured site URL. Handover: a deployment runbook covering install, start, restart and version pinning. Confirm which hosting pattern and runtime your security team has approved.
Application database build and configuration
Metabase stores its own metadata in an application database. PostgreSQL is the recommended production choice, and MySQL 8.4.0 or MariaDB 10.6.0 and later with utf8mb4 are also supported. The embedded H2 database suits demos only, so any move off it needs a planned load-from-h2 step. Handover: a database configuration record with backup schedule and owner.
Data source connections with least-privilege credentials
Each warehouse or operational database is connected using a dedicated read-only account scoped to the schemas that analysts need. Credential storage, rotation ownership and network paths to each source are agreed before connection. Handover: a data source inventory listing each connection, its account, its owner and its grants. Ask who approves new sources.
Permissions and collection design
Groups, data permissions and collections determine who sees which tables and saved questions. Design decides which groups get view, query or no access per database and schema, and where personal and shared content lives. Handover: a permissions matrix and a collection map. Row and column level permissions require Pro or Enterprise, so confirm that need early.
Starter dashboards and saved questions
The build includes a first set of dashboards and saved questions for agreed business domains, built on the approved data sources and reviewed with the data owners who will maintain them. Scope is set by the number of domains and metrics you choose. Handover: a list of delivered dashboards, their owners and their source tables.
Sign-in: Google, LDAP, SAML, OIDC, JWT or SCIM
Google sign-in and LDAP are available on the Open Source and Starter plans. SAML, OIDC, JWT, advanced LDAP group sync and SCIM provisioning require Pro or Enterprise. Group mapping to Metabase permissions is set during this package. Handover: an identity configuration record. Confirm your identity provider and the plan before scoping.
Role-based training and admin handover
Training is delivered by role: administrators, data owners who publish content, and analysts who build questions. Sessions use your permissions model and collections, not generic demos. Handover: an admin handover session and role-specific guides. Ask how many sessions and attendees each quote includes.
What drives cost and duration in a Metabase rollout
Each row names one driver, explains why it changes effort or cost in a Metabase rollout, and gives a way to keep it contained, with paid-plan features treated as a scope decision covered in the cost of ownership and editions page.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Edition and user count | Open Source is free. Starter is $100/month ($90 billed yearly), Pro $575/month ($517.50 billed yearly), Enterprise from $20,000/year by quote. Starter includes 5 users, Pro 10, and extra users cost $6 or $12 per month (Metabase pricing page). | Count named users by role before choosing a plan. Confirm which features the edition includes, since paid-plan features change the scope. |
| Number and type of data sources | Each connection needs credentials, network paths, field-type checks and testing. Effort rises with source count and schema variety. | Start with the databases behind the first dashboards and add others in later phases. |
| Row and column permissions and multi-tenant segregation | Pro and Enterprise only. Sandboxing needs group mapping, rules per data domain and tests for each role. | Decide at scope whether row and column rules are needed at launch or can follow in a later phase. |
| Identity protocol | Google sign-in and LDAP work on Open Source and Starter. SAML, OIDC, JWT and SCIM need Pro or Enterprise. | Confirm which protocol your identity provider supports and the plan it needs before the quote is final. |
| Application database | H2 is the embedded demo database. PostgreSQL is recommended for production, with MySQL and MariaDB also supported. | Provision PostgreSQL with backups from the start to avoid a later migration from H2. |
| Number of environments | Each environment repeats installation, configuration, source connections and upgrade testing. | Use one non-production environment with sample or masked data before production. |
| Collections and dashboards to design | Each collection needs an owner, a permission map and reviewed dashboards, so effort grows with every team. | Start with a short list of governed collections and starter dashboards, then expand on request. |
| Compliance evidence requests | Assessors may ask for access reviews, configuration records and audit logs; auditing is a Pro and Enterprise feature. | Agree the evidence list in writing before build. Independent auditors, not DeployOpen, issue any assessment result. |
| Amount of training | Analysts, builders and administrators need different sessions, and refresher training grows with each new collection. | Train a small group of builders first and record a short internal guide for each collection. |
Implementation phases and the output of each
The sequence moves from agreed scope to a governed Metabase that pilot users have validated and your team can operate without us.
Inventory sources and confirm edition
We inventory the databases to connect, the user groups who will need access, and the reporting questions they must answer, then confirm the edition decision against the features they require. You receive a written scope listing sources, groups, the chosen edition and the open decisions. The schedule is set in that written scope.
Design hosting, database and network
We design where Metabase runs, which application database it uses (PostgreSQL is the production recommendation in the Metabase docs), how TLS terminates, and how backups of the application database are taken and tested. You receive an architecture document and an environment diagram that your security and platform teams review before anything is built.
Build the install and connect data sources
We install the chosen Metabase version in your environment, configure the application database, and connect each data source using a dedicated read-only database credential per source. You receive a working instance with connections confirmed, a record of the credentials and their scope, and the installed version number.
Design permissions and collections
We translate the user groups into Metabase groups, collection structure and data permissions, including which groups can query raw tables and which work only through curated models. You receive a permissions matrix that maps each group to collections and data access, signed off by the data owners who named them.
Integrate identity and build starter content
We connect sign-in to your identity provider using the method your edition supports and map groups to Metabase permissions, then build starter dashboards and saved questions for the agreed reports. You receive a sign-in test record and starter content mapped to the permissions model.
Validate with pilot users and train
Pilot users run their real questions and dashboards, we record the defects and access gaps they find and fix them, then we deliver training to each user group. You receive a validation log with each issue and its resolution, plus training material for the groups.
Go live and hand over runbooks
We move the environment to production, confirm backups and monitoring, and hand over runbooks for upgrades, rollback, credential rotation and permission changes. You receive the runbooks, the configuration record and a closing review against the written scope, so your team can operate Metabase independently or under a separate support agreement.
Which parts teams keep in-house and which they outsource
This table shows who typically owns each part of a Metabase rollout and where a partner usually helps, and the answers shift if your organization already runs PostgreSQL and identity services well.
| Work area | Typical owner | Skills required | Partner usually useful? |
|---|---|---|---|
| Data source inventory and business definitions | Data owners, with the analytics lead | Domain knowledge, metric definitions, familiarity with your data catalog | Rarely needed, unless definitions are scattered across many teams |
| Application database and hosting | Platform team, often shared with other services | PostgreSQL administration, Linux or container operations, backup practice | Useful if PostgreSQL or hosting skills are thin internally |
| Data source credentials and network access | Security team and database administrators | Least-privilege database roles, firewall rules, secrets handling | Useful for reviewing read-only access design and network paths |
| Permissions and collection design | Analytics lead, with security review | Metabase permission model, data access policy, collection structure | Useful for pattern design, which is hard to rework after launch |
| Identity integration | IAM team | Protocol setup (SAML, OIDC, JWT, SCIM), group mapping, plan feature limits | Useful for protocol setup on Pro or Enterprise, where SSO is licensed |
| Starter dashboards | Analytics team | SQL, metric logic, dashboard design, stakeholder review | Usually internal, with partner review if the team is new to BI |
| Training | Internal enablement lead or partner | Facilitation, role-based materials, admin and author walkthroughs | Useful for a first rollout or when enablement capacity is limited |
| Ongoing administration | Internal platform and analytics owners | Upgrade planning, user and group hygiene, query and performance review | Optional, through a support retainer, if internal capacity is limited |
What usually goes wrong and how to prevent it
Most Metabase rollouts stall for predictable reasons. Each card names the failure, the prevention step, and the artifact that shows it was handled before users arrive.
Dashboards built before permissions
Teams often publish dashboards first and design groups later, so access gets retrofitted across many questions and collections. Define groups, data permissions and collection ownership before the first dashboard is shared. The artifact is a signed permissions matrix mapping each group to databases, schemas, collections and write rights.
Admin credentials on data connections
Connecting sources with administrator or owner database accounts gives every Metabase user a path to data they should not see. Create a read-only database role per source, scoped to the approved schemas. The artifact is a credential register listing each connection, its role, and the date its password was last rotated.
Production on the embedded H2 database
The default H2 application database is intended for demos, so storing users, questions and settings there puts the whole instance at risk. Plan a PostgreSQL or MySQL application database before go-live, and confirm the supported versions in the Metabase documentation. The artifact is a restore test showing the application database can be rebuilt from backup.
Assuming SSO or row-level security on free tiers
SSO beyond Google sign-in or LDAP, row and column permissions, and usage auditing are limited to Pro and Enterprise plans. Confirm the edition against each requirement in the requirements document before committing to a design. The artifact is an edition-to-requirement table signed by the business owner and security lead.
Underestimating onboarding and training
Account provisioning, group assignment and training for analysts and viewers take sustained effort after the platform is working. Budget for role-based sessions, a support channel and documentation in the quote, and ask the partner who delivers them. The artifact is a training plan with attendance records and a completed onboarding checklist per user group.
Unowned collections leading to sprawl
Without named owners and a collection structure, saved questions multiply, duplicates appear and nobody knows which dashboard is authoritative. Assign an owner to each top-level collection and set a review cadence for retiring content. The artifact is a collection ownership register with owners, review dates and the archive rule.
No owner for application database backups
The application database holds dashboards, permissions and configuration, and a missing backup owner means nobody notices when backups fail. Name one person or team responsible for scheduled backups, retention and restore tests, and confirm the backup runs before each upgrade. The artifact is a backup runbook with the named owner, schedule and the most recent successful restore test record.
How the implementation changes by starting point
A fresh install has the fewest constraints, but the planning choices still come first. Settle the application database, edition and sign-in method before deployment, because changing them later becomes a separate project.
- Application database: plan PostgreSQL for production. MySQL 8.4.0 or MariaDB 10.6.0 and later, with utf8mb4, are also supported.
- Edition: check the required features against the plan list, since SSO, row and column permissions and auditing need Pro or Enterprise.
- Sign-in: Google sign-in and LDAP are available on the free tiers, so confirm your identity method early.
- Content work: budget time for collections, permissions and starter dashboards, which often takes longer than the install itself.
- Version: choose the Metabase version you will standardize on and confirm its support window.
Two starting points lead to migration work. A pilot on the default H2 database must move to a production database, and reports from another BI tool must be rebuilt in Metabase. Each path has its own planning impact.
- H2 pilot: the load-from-h2 command must run with the same Metabase version that last updated the H2 file, so confirm version matching first. See the H2 to PostgreSQL migration page for the method.
- Cutover window: plan a downtime window for the switch and confirm its length with your operations team, since it depends on your environment.
- Other BI tools: inventory questions, dashboards, collections and permissions, then decide what is rebuilt and what is retired. See the Metabase migration page.
- Validation: name who checks migrated content and the figures it must match before users are switched over.
Running Metabase on a container platform shifts ownership of storage, secrets and upgrades. The backend still runs as a JAR inside the image, so the platform team and the application team should agree on responsibilities early.
- Image source: confirm whether your team uses an official image or builds its own, and who maintains it for each release.
- Application database: decide whether it runs inside the cluster or as a service outside it, and who owns its backups.
- Upgrades: the migration lock means major upgrades on a cluster require reducing it to a single node, which affects your rolling-update design.
- Secrets: keep database credentials and SSO client secrets in your cluster's secret management, and confirm the approach with security.
Restricted networks add delivery and licensing questions before any configuration work. The planning starts with how software and updates reach the environment, and confirming these items with your vendor and security team is the first step.
- Software transfer: confirm how the JAR or container image, plugins and dependencies are moved in, scanned and approved.
- Offline licensing: confirm whether a paid plan's license can be activated without outbound connections, and how renewals are handled.
- Update path: each upgrade needs a new package transfer and a tested application database backup.
- Network access: confirm that database drivers, identity providers and email relays are reachable from inside the enclosed network.
- License terms: the open source code and the commercial editions use different licenses, so review both before deployment.
Several teams sharing one instance, or separate customers served from one deployment, usually needs a paid plan. The features that separate each group's data are not in the free tiers, so the edition decision comes before the permissions design.
- Feature check: confirm that SSO, row and column level permissions, multi-tenant data segregation and usage auditing are in the plan you buy. Per Metabase's pricing page, these are included only in Pro and Enterprise.
- Pricing: per Metabase's pricing page, Pro is $575 per month, or $517.50 per month billed yearly, with 10 users included, and Enterprise is priced by quote starting at $20,000 per year.
- Structure: map collections and groups for each team before building dashboards.
- Instance count: decide between one shared deployment and separate deployments, since each carries different operating and upgrade costs.
What your team needs to provide before work starts
Before any build work starts, your organization has to name an executive sponsor and a project owner with authority to make scope and access decisions. The sponsor settles trade-offs between speed and governance, and the project owner maintains the data source inventory: each database Metabase will query, its engine, the team that owns it and the person who approves access to it. Confirm both names in writing with the scope document, because gaps here are the most common reason a rollout stalls at the permissions stage.
Next, prepare the technical inputs. For each data source, decide whether read-only database accounts already exist or whether your database team will create them under a least-privilege process. Ask for network paths from the Metabase hosts to every source, and from user networks to the Metabase URL. Identify the hosting target (VM, container platform or data center host) and whether you will supply a managed PostgreSQL or MySQL service for the application database. Metabase recommends PostgreSQL for production, and MySQL 8.4.0 or MariaDB 10.6.0 and later with utf8mb4 is also supported, so confirm which engine your database team operates and supports.
Identity and edition decisions shape much of the design. Name a contact in your identity team who can describe your identity provider and group structure for SSO design. Confirm whether you need SSO, row-level or column-level permissions, or auditing, because those features are included only in the Pro and Enterprise plans, not Open Source or Starter. Your procurement team should use that answer to choose the edition before the quote is finalized. Also provide the list of user groups and their access needs, plus the business definitions (revenue, active customer and similar terms) that the starter dashboards will depend on.
Finally, name the people who approve and operate the system. Someone in data governance or security should approve the permissions model, covering which groups see which collections, databases and schemas. A named Metabase administrator, who will run upgrades, manage users and review access after go-live, must be identified before build starts so that handover and training can be scoped. Also provide the training audience list, separating administrators, analysts who build questions and business users who only view dashboards, since each group needs a different session.
Questions buyers ask about Metabase implementation cost and effort
What drives the cost of a Metabase implementation?
The main drivers are the edition, the number of users, the data sources, the permissions model, identity integration and the number of environments. Edition determines which features are available at all. Metabase's pricing page lists Open Source at no license fee, Starter at $100 per month ($90 per month billed yearly) with the first 5 users included, Pro at $575 per month ($517.50 per month billed yearly) with the first 10 users included, and Enterprise priced by quote starting at $20,000 per year. Each data source, permission design and environment adds build and testing work, and infrastructure and support for self-hosting are separate costs.
Is the free Open Source edition enough for SSO or row-level security?
No. According to Metabase's pricing page, SSO, row and column level permissions, multi-tenant data segregation, and usage analytics and auditing are included only in the Pro and Enterprise plans. Open Source and Starter support Google sign-in and LDAP, but JWT, OIDC, SAML and advanced group sync or SCIM provisioning require Pro or Enterprise. If you need SAML with your identity provider or row-level data restrictions, plan for a paid plan from the start and confirm current plan details on the pricing page before you commit.
How long does a Metabase implementation take?
The duration is set in the written scope, and no single figure applies to every rollout. It depends on the number of data sources to connect, how many permission groups and collections you need, whether SSO and training are included, the condition of the source data, and how many environments must be built and tested. Ask for a schedule that lists each phase, its dependencies, and the decisions and access your team must provide at each step. Agree in writing how scope changes will affect the timeline.
Can our own team implement Metabase without an outside partner?
Yes. An internal team can install and configure Metabase on infrastructure it controls if it has the skills listed in the in-house section of this page. These include Linux and container operations, PostgreSQL administration, database access management, identity administration and analytics modeling. Identify the skill gaps early, decide whether they can be filled by hiring or training, and estimate how much time staff can give the work alongside their existing duties. A partner is most useful when those gaps or deadlines are firm constraints.
What must our team provide and what should a quote contain?
Your team typically provides infrastructure access, network paths to the data sources, read-only service accounts following least privilege, an identity provider administrator, a list of user groups with the data each group may see, and a named decision maker. A quote should follow from a written scope and list each deliverable, the environments, the application database, each data source, the permissions and collection design, identity integration, training, documentation and handover. It should also state assumptions, exclusions, change handling, third-party licensing, and which costs are one-time and which recur.
Can a partner install Metabase and then hand it over to us?
Yes, handover is a normal part of an implementation scope and should be written into the deliverables. Ask for documented configuration, runbooks, access records, a tested backup and restore procedure, and a training session for the staff who will run it. Upgrades are a recurring activity, not a repeat of the implementation. Each upgrade follows Metabase's documented procedure, which includes backing up the application database first. Ongoing upgrade and support work is covered separately, and you can decide later whether to keep it in-house or retain a partner.
How DeployOpen scopes, delivers and hands over Metabase work
DeployOpen plans, builds, documents and supports self-hosted Metabase inside your own infrastructure, so the application database, data source connections and permissions model are agreed in writing before any build starts. The result is a rollout your team can scope, cost and run with a clear view of what each step includes.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope names the application database, each data source connection and the planned permissions model for your organization.
- The scope lists which edition you plan to run, since SSO and row-level permissions depend on the plan you choose.
How we build
- We deploy Metabase in your cloud accounts, data center or air-gapped network, with a production PostgreSQL application database planned from the start.
- We configure collections, starter dashboards and group-based permissions, then verify access against the agreed permissions model.
- We test data source connections and identity integration in a non-production environment before cutover to your users.
How we hand over
- You receive installation and configuration documentation covering the deployment, database backups and permission structure.
- Handover includes a walkthrough of collections, permissions and how new data sources are added under your governance.
- Training for analysts and administrators is scoped with you, so the people who own dashboards know how to maintain them.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after go-live.
- Upgrades follow Metabase's documented procedure, including a database backup and single-node handling for major upgrades.
- Ask your quote to state which support tasks sit inside the retainer and which are billed separately.
