Metabase vs Lightdash: which to choose

Metabase vs Lightdash: when to choose each for self-serve BI

Choose Metabase when the main job is letting business users explore data without writing SQL, building questions and dashboards in the UI against tables your analysts already maintain. Its open source edition is free to self-host under the AGPL, and it covers the core question builder. Choose Lightdash when your metric definitions should live in the dbt project, reviewed in pull requests and versioned in Git next to the models they depend on. Lightdash reads its semantic layer from dbt, supports dbt v1.4.0 and above, and its free self-hosted Open Source edition covers core BI features. Metric logic then follows the same review path as the rest of your transformations.

The decision turns on three questions. First, where should metric definitions live: in dbt YAML under meta: metrics: in your Git repository, or in the BI tool's own configuration maintained by a BI team? Second, which paid features are non-negotiable. Metabase's row and column level permissions, SSO, usage analytics and auditing sit in its Pro and Enterprise plans, while Lightdash's SSO with SAML and SCIM 2.0, custom roles and on-premises licensing are tied to Enterprise, with the license key set through LIGHTDASH_LICENSE_KEY. Confirm which of these your compliance team requires before comparing list prices, and check the current plan terms with each vendor.

Third, how much upgrade work your team can carry. Metabase publishes version support windows, with LTS releases supported for 14 months and non-LTS releases usually ending after 2 months, and its upgrades run application database migrations automatically, so a backup of the application database comes first. Lightdash ships new versions frequently, so a self-hosted instance needs a standing routine for pulling images, reviewing changes and testing dbt compatibility. If your platform team cannot commit to that cadence, factor it into the decision, and ask each vendor or your implementation partner to document the upgrade steps for your exact deployment before you commit.

Which scenario favors which platform

This table maps common situations to the platform that fits them better, and names the condition that tips the decision. Read each row as a question about your team: if the condition holds, the matching platform is the stronger starting point. Check the paid-edition column before you commit, because the answer changes once you need row-level permissions, SSO or embedding.

Scenario	Better fit	Condition that drives the choice
Business users build their own questions and dashboards	Metabase	Most of the work is point-and-click exploration by non-SQL users. Lightdash exploration depends on metrics that already exist in the dbt project, so it suits teams where analysts maintain those models.
Mature dbt project with governed metrics in Git	Lightdash	Metric definitions live in dbt YAML under meta: metrics: and sit in the same repository as the models. Choose Lightdash when reviewers must approve metric changes through the same pull request process as the models.
Metrics must be governed across many warehouses or non-dbt sources	Metabase	Lightdash reads its semantic layer from a dbt project, so it works best when dbt already models the data. Confirm whether your sources are modeled in dbt before assuming Lightdash covers them.
Customer-facing embedded analytics	Confirm before choosing	Metabase guest embedding is in the open-source edition, while SSO-based embedding and removing Metabase branding need Pro or Enterprise. Lightdash lists embedding on Cloud Pro and Enterprise, so compare the license key and plan costs for your tenant model.
Row-level or column-level access by user group	Metabase on Pro or Enterprise	Metabase lists row and column level permissions as paid Pro or Enterprise features. Confirm the Lightdash edition and role model that covers your access rules before you rely on it.
Small team without a DevOps function, wanting free self-hosting	Metabase	Metabase runs as a single JAR with an embedded H2 database for demos, though PostgreSQL is recommended for production. Lightdash self-hosting targets engineers familiar with Docker and Kubernetes and needs PostgreSQL with pgvector plus S3-compatible storage.
Team already runs Kubernetes and a dbt CI pipeline	Lightdash	The official Helm chart and dbt integration fit an engineering-led platform team. Confirm that your cluster and object storage meet the documented requirements before committing.
Self-hosted with frequent, low-risk upgrades required	Metabase	Metabase LTS releases are supported for 14 months, and upgrades run application database migrations automatically. Lightdash ships new versions frequently, so you will need a regular upgrade routine on your own schedule.
Need for an enterprise license key and on-premises support	Confirm before choosing	Lightdash Enterprise on-premises requires a LIGHTDASH_LICENSE_KEY and unlocks features such as SCIM and custom roles. Ask Metabase and Lightdash sales for written terms covering your support window and air-gapped requirements.

How Metabase and Lightdash are built and deployed

Both platforms are self-hosted, but they ask different things of your team. Metabase is a single application with an application database you choose, while Lightdash pairs a web service with PostgreSQL, object storage and a dbt project that defines its metrics. The cards below set out what each shape means for daily operations.

Metabase runs as a JAR

Metabase's backend is written in Clojure and Java and runs as a JAR, so a self-hosted instance is one application process you start, monitor and restart on a host you control. Your team needs Java-based runtime familiarity and a process supervisor or container setup, but not a Kubernetes cluster to begin. Check whether your hosting standard accepts a single application process for BI that business users depend on daily.

H2 is the default, not the production choice

Out of the box, Metabase stores questions, dashboards and settings in an embedded H2 application database, which suits demos. Metabase recommends PostgreSQL for production, and MySQL 8.4.0 or MariaDB 10.6.0 and later are also supported. Moving off H2 later uses a one-time load-from-h2 command that must run with the same Metabase version that last wrote the H2 file, so decide the database before business users build content.

Lightdash needs PostgreSQL and object storage

Lightdash documents a PostgreSQL metadata database and S3-compatible object storage as core pieces of a self-hosted install. Your platform team must provision, back up and secure both, along with the web service itself. Confirm that your storage standard supports S3-compatible APIs before you commit, since that is a hard requirement rather than an optional extra.

Kubernetes with Helm or Docker Compose

Lightdash offers an official Helm chart for Kubernetes and a minimal Docker Compose deployment. The Helm path suits teams already running clusters with their own ingress, secrets and backup tooling, while Compose suits smaller footprints and evaluation. The guide targets DevOps engineers familiar with Docker and Kubernetes, so a team without that experience should plan for ramp-up time before going to production.

A dbt project is part of the deployment

Lightdash reads its semantic layer from a dbt project and supports dbt v1.4.0 and above, working with both dbt Core targets and dbt Cloud environments. Metrics live in dbt YAML in your Git repository, so someone must own the dbt project, its CI and its deployment alongside the Lightdash instance. Metabase has no such dependency, which changes who must be on the team from day one.

Enterprise on-prem needs a license key

Lightdash's Enterprise Edition features, including AI agents, embedding, custom roles, service accounts and SCIM, need a license key supplied through the LIGHTDASH_LICENSE_KEY environment variable. Enterprise on-prem also requires PostgreSQL with the pgvector extension. Confirm the database extension is available in your managed PostgreSQL service before planning an install, because it can block an otherwise standard setup.

How each handles governed metrics and the dbt layer

Lightdash takes its metric definitions from the dbt project. Metrics are declared in dbt YAML under meta: metrics: at the column or model level, using aggregate types such as count, count_distinct, sum, average, median and percentile, plus post-calculation types such as running_total and percent_of_total. Because those files sit in the customer's own Git repository beside the dbt models, a metric change goes through the same review and version history as a model change. Lightdash supports dbt v1.4.0 and above and works with both dbt Core targets and dbt Cloud environments. The definition of a metric lives in code, not in the BI tool's database. Confirm your dbt version against the Lightdash dbt projects reference before you commit to this path, because an older dbt project will need an upgrade first.

Metabase works from a different starting point. Business users build questions and dashboards in the UI, and governance is applied on top through permissions. Row and column level permissions, SSO, and usage analytics and auditing are listed on the pricing page as Pro or Enterprise features, so a team that needs to restrict who sees which rows or columns should price that tier in from the start. Metabase does not require a dbt project to answer a question, which is the right trade for a team whose analysts need self-serve access before their transformation layer is mature. The risk is that metric logic can drift across saved questions unless someone owns a shared definition of each measure. Ask your analysts where each core KPI is calculated today and whether two dashboards would agree on it.

The choice turns on where your metric discipline already lives. A team with a well-maintained dbt project, code review on models and a clear owner for each metric will get more from Lightdash, because the semantic layer is already there and the BI tool inherits it. A team that needs business users building questions this quarter, and has no dbt metric definitions yet, will move faster with Metabase and should plan to add governance as the metric catalog matures. Both paths carry a self-hosting cost. Lightdash releases frequently, so an instance needs a regular upgrade routine, and Metabase upgrades run application database migrations automatically, so back up the application database first.

Capabilities, licensing and paid features compared

This table sets Metabase open source and its paid plans against Lightdash open core on license, free self-hosted scope, identity, permissions, embedding, dbt integration and AI features. Read each row for the condition under which it matters, and confirm any edition detail against the current vendor pricing page before you buy.

Capability	Metabase	Lightdash
Core license	AGPL for the open source edition; commercial editions under the Metabase Commercial Software License	MIT for code outside the ee directory; the ee directory uses a separate license
Free self-hosted scope	Open Source edition is free and includes guest embedding and Google sign-in or LDAP	Open Source edition is free for core BI features; confirm which features sit outside it on the pricing page
Single sign-on	JWT, OIDC and SAML require Pro or Enterprise; Google and LDAP are available on the free tier	SAML and SCIM 2.0 are listed on Enterprise; confirm whether any SSO option is available on Cloud Pro
Provisioning and group sync	SCIM provisioning and advanced LDAP group and attribute sync require Pro or Enterprise	SCIM 2.0 is listed on Enterprise, alongside custom roles and service accounts
Row and column permissions	Row and column level permissions are a paid Pro or Enterprise feature	Custom roles are listed on Enterprise; confirm how row-level restrictions are handled in your setup
Embedding	Guest embedding works on the open source edition; SSO-based modular and full app embedding need Pro or Enterprise	Embedding is listed on Cloud Pro; confirm whether self-hosted embedding requires an Enterprise license key
Metric definitions	Governed metrics are built in the Metabase model layer and questions, with permissions set in the app	Metrics are defined in dbt YAML under meta: metrics: and stay in the customer's Git repository
dbt integration	Works against a warehouse directly; no dbt-native metrics layer is listed in the supplied facts	Reads the semantic layer from a dbt project, supporting dbt v1.4.0 and above with dbt Core or dbt Cloud
AI features	No AI feature is listed in the supplied facts; confirm current AI options with Metabase	AI agents and MCP are listed on Cloud Pro and unlocked on self-hosted Enterprise through a license key
Self-hosted licensing dependency	Pro and Enterprise features need a paid plan but no separate key is described in the supplied facts; confirm the activation method	Enterprise features need a LIGHTDASH_LICENSE_KEY and a PostgreSQL database with pgvector

What is free and what is paid on each platform

Metabase Open Source is free to run and ships under the AGPL. The repository keeps the open source edition under LICENSE-AGPL.txt and the commercial editions under the Metabase Commercial Software License, so the free tier covers self-serve questions, dashboards and warehouse connections without a license fee. Your costs are the server, the application database and the staff time to operate it. The features below sit only in paid tiers, so each one marks the point where the free edition stops being enough.

Single sign-on: JWT, OIDC and SAML are not available on this tier. Google sign-in and LDAP are. You need a paid plan when your identity provider must be the only login path.
Row and column level permissions: Restricting which rows or columns each group sees requires Pro or Enterprise. This matters when several business units share one instance.
Usage analytics and auditing: Reporting on who queried what requires a paid plan. Teams with audit evidence obligations usually hit this first.
Multi-tenant data segregation: Keeping separate customers or legal entities apart in one instance requires Pro or Enterprise.
Application database: The free edition runs on the embedded H2 database for demos. Metabase recommends PostgreSQL for production, and hosting that database is your responsibility.

Before you commit to the free tier, confirm which login methods and access controls your auditors and identity team require.

The upgrade routine each platform needs when self-hosted

Both platforms need a scheduled upgrade routine, but the routine differs in cadence and in how much a database migration can block you. For Metabase, start with the support window. Metabase 64 is an LTS release published on 16 September 2026 with end of life on 1 December 2027, and Metabase 65 followed on 12 October 2026. LTS versions get support for 14 months, while non-LTS versions usually reach end of life after about two months. Choosing an LTS line for a self-hosted BI instance that business users depend on gives you a longer window between mandatory moves. Confirm the current end-of-life dates on the Metabase version support page before you pick a line.

Metabase runs application database migrations automatically on upgrade, so a Metabase upgrade is also a schema change to the database holding your questions, dashboards and settings. The upgrade documentation recommends backing up the application database first, reducing a cluster to a single node for major upgrades because of a migration lock, and upgrading one release at a time when you start from a version older than 40. Put those steps in a written runbook with a restore test, and plan the maintenance window around them. Ask Metabase to confirm how the migration lock behaves on your application database version before scheduling the upgrade.

Lightdash moves faster. Version 2.603.0 was released on 17 October 2026, and the project ships new versions frequently, so a self-hosted instance needs a regular upgrade cadence rather than an occasional project. Your routine should cover the Helm chart or Docker Compose files, the PostgreSQL metadata database, the S3-compatible object storage, and the dbt project that feeds the semantic layer, since metric definitions live in your Git repository. If you run Enterprise Edition, also confirm with Lightdash that your LIGHTDASH_LICENSE_KEY and the pgvector requirement carry across each upgrade. Before you commit, ask both vendors for their upgrade notes, deprecation policy and the migration path between the versions you plan to run.

What drives the running cost of each platform

Running either tool is mostly a question of who pays for infrastructure, who does the upgrades, and whether a paid tier is needed for the controls you require. Metabase and Lightdash spread these costs differently, so the same team can end up with very different bills depending on user count, hosting choices and how much dbt work already exists.

Infrastructure for app database and queries

Self-hosted Metabase needs compute for the application, an application database and the warehouse queries that dashboards trigger. Metabase recommends PostgreSQL for production over the embedded H2 default. Lightdash self-hosting needs a PostgreSQL metadata database with the pgvector extension and S3-compatible object storage. Ask the vendor or your platform team to size each component against your user count, query volume and refresh schedule, and confirm which cloud resources you will pay for directly.

Staff time for upgrades and migrations

Metabase upgrades run application database migrations automatically, and the docs advise backing up first, reducing a cluster to one node for major upgrades, and upgrading release by release from versions older than 40. Lightdash ships new versions frequently, so self-hosted instances need a regular routine. Budget recurring engineer hours for both, and ask any partner to state in writing who runs upgrades, test environments and rollback.

Per-user or flat subscription on paid tiers

Metabase Pro is priced per month with users included and extra seats billed separately, so cost grows with headcount. Lightdash Cloud Pro is a flat monthly price with no per-seat pricing, while its self-hosted Enterprise tier is quoted. Pro and Enterprise are only needed if you require features such as SSO, row and column permissions or SAML, so price the controls you need before choosing a tier. Ask for the license term and whether renewals change the per-user rate.

Dbt maintenance effort for Lightdash

Lightdash reads metrics from a dbt project in your Git repository, so metric definitions need the same review, testing and ownership as your models. This is recurring work that falls on analytics engineers, and it is the main cost Metabase does not add in the same form. Ask who maintains the dbt project, how metric changes are reviewed, and whether your team already uses dbt Core or dbt Cloud.

Support options and what they include

Metabase's paid plans and Lightdash's Cloud Pro and Enterprise tiers differ in dedicated support, migration assistance and hands-on help. Open-source use relies on community channels and your own staff. Before signing, confirm response expectations in writing, what migration help covers, whether on-premises deployment support is included, and what happens to your running instance if you let a subscription lapse.

Moving from Metabase to Lightdash, or back, step by step

This sequence moves a team's questions, dashboards, metrics, permissions and sign-in from one tool to the other without losing track of which numbers are authoritative. The result is a tested target instance, a documented metric set in version control, and a cutover decision made on evidence.

Inventory questions, dashboards and users
The BI owner, with input from the heaviest dashboard users, lists every saved question, dashboard, collection, data source connection, scheduled delivery and user group in the current Metabase instance. Mark each item as active, seasonal or abandoned, since the abandoned ones are usually not worth rebuilding. The step is done when the inventory has an owner and a retirement decision for every item, and the team has confirmed which data sources the target tool will need to reach.
Map permissions and access rules
The security or platform lead records how row and column restrictions, groups and collection permissions are used today, because these rules are where access mistakes hide after a migration. Confirm with Metabase which of these features sit on a paid plan in your configuration, and confirm with Lightdash how its custom roles and access controls map to your current groups, including any features that depend on an Enterprise license key. The step is done when every access rule has a written equivalent or a documented gap.
Decide which metrics move into dbt
The analytics engineering lead reviews the metrics that appear across several dashboards and decides which ones should be defined once in dbt YAML under the Lightdash metrics reference, and which exploratory questions can stay as ad hoc analysis. Each metric is written down with its filters, grain and owner, and the team checks the existing SQL against the dbt models to find conflicting definitions. The step is done when a short list of governed metrics exists in a Git branch, reviewed by the people who own the business numbers.
Rebuild dashboards and questions in the target
Analysts and business owners recreate the retained dashboards in the target tool, starting with the most-used ones and linking each chart to the governed metrics where they exist. Questions are rebuilt rather than exported, because the query logic, filters and chart settings are tool-specific, and metric logic should be validated against the source system. The step is done when each rebuilt dashboard has been checked against the original for the same date range and the business owner has signed off on the figures.
Migrate identity and sign-in
The identity administrator confirms which sign-in methods each tool supports on the plan the team will run, then sets up SSO for the target and maps existing users and groups to it. Metabase's documented SSO and group sync options depend on its plan, and Lightdash's SAML and SCIM options depend on its edition, so confirm both in writing before cutover. User accounts usually do not transfer as data, so the team reconciles who needs access on day one. The step is done when a test group of users can sign in through the target and see only the content their role allows.
Run both tools in parallel
For an agreed period, business users keep using the current tool while the rebuilt dashboards run in the target, and the team logs every figure that differs between them. Each difference is traced to a cause: a metric definition, a time zone, a filter or a data freshness issue. The step is done when the differences are either explained and fixed or accepted by the business owner, and the discrepancy log is empty for the governed metrics.
Cut over and keep a rollback path
The platform team announces the cutover date, redirects links and scheduled deliveries to the target, and keeps the source instance in read-only mode with a verified backup of its application database. Before switching, confirm the backup restores cleanly, and for Metabase follow its upgrading and migration guidance on the application database. The step is done when users work in the target, the backup has been restored once in a test environment, and the rollback steps are written down.
Set the upgrade routine for the new tool
The platform team records the release cadence of the target and assigns an owner for upgrades, since both tools change often and self-hosted instances fall behind quickly. For Metabase, track its version support page to see which releases are long-term and when others reach end of life. For Lightdash, follow its GitHub releases and test each upgrade against a staging copy with the dbt project. The step is done when a calendar of upgrade checks and a staging environment exist, and the owner has tested one upgrade end to end.

What implementing each platform involves and where projects run long

Implementing Metabase starts with the application database. The embedded H2 database is meant for demos, so a production rollout points Metabase at PostgreSQL from the first day, because moving questions, dashboards and settings later means running the one-time load-from-h2 command with the same Metabase version that last wrote the H2 file. Identity comes next. Google sign-in and LDAP work on the open-source edition, but JWT, OIDC, SAML and SCIM provisioning need Pro or Enterprise, so the team should confirm which identity path it needs before building anything. Business users then build collections, questions and dashboards, which is the part that grows fastest and usually needs a named owner for each collection. Confirm the plan that covers row and column permissions before you design them, since that design determines what each group sees.

Implementing Lightdash is mostly a modeling project. The platform reads its semantic layer from a dbt project (dbt v1.4.0 and above, with dbt Core or dbt Cloud), and metrics are defined in dbt YAML under meta: metrics:. Your data team must agree on metric definitions, filters and dimensions in Git before business users see them. Deployment is either the official Helm chart on Kubernetes or a minimal Docker Compose setup, both needing a PostgreSQL metadata database and S3-compatible object storage. If you want Enterprise Edition features, plan for the LIGHTDASH_LICENSE_KEY environment variable and a PostgreSQL database with the pgvector extension. Confirm the license key process with Lightdash before the build starts, because it gates custom roles, SCIM and AI features.

Projects usually run long in four places: metric modeling in dbt, permission design, identity integration and upgrade testing. Metric disagreements between teams take longer to settle than any YAML takes to write. On Metabase, group and permission mapping tends to grow once row-level rules are added. Lightdash ships new versions often (2.603.0 was released on October 17, 2026), so self-hosted instances need a scheduled test-and-upgrade cycle, and Metabase upgrades run application database migrations automatically, so back up first and test on a copy. DeployOpen plans, implements and tests these pieces inside your own infrastructure, and scopes them in writing before work starts, so the ownership of each item is settled up front. Ask any partner for the modeling, identity and upgrade effort as separate line items in the written scope.

Questions buyers ask before choosing or hiring help

Can Metabase open source enforce row-level security?

No. Row and column level permissions are listed on Metabase's pricing page as a paid feature on the Pro and Enterprise plans, not in the free Open Source edition. The same applies to SSO and usage analytics and auditing, which are also limited to Pro and Enterprise according to the pricing page. If your data access rules require row-level restrictions, budget for Pro or Enterprise from the start and confirm the current plan terms with Metabase before you design your permission model. Ask Metabase for a written statement of which features each plan includes at the version you intend to deploy, since plan contents can change between releases.

Can a team run Lightdash without dbt?

Not in the way Lightdash is designed to work. Lightdash reads its semantic layer from a dbt project and supports dbt v1.4.0 and above, with both dbt Core targets and dbt Cloud environments. Metrics are defined in dbt YAML under meta: metrics: at the column or model level, so the dbt project is the source of truth for metric definitions. If your team does not maintain dbt models, you will need to create and version that project before Lightdash delivers its governed metrics layer. Confirm with Lightdash how much of the dbt setup it expects your team to own, and whether any non-dbt modeling path is offered on your plan.

What does Lightdash Enterprise require technically?

Lightdash's enterprise on-premises documentation says Enterprise Edition features need a license key set through the LIGHTDASH_LICENSE_KEY environment variable. It also requires a PostgreSQL database with the pgvector extension. The license key unlocks features including AI agents, embedding, custom roles, service accounts and SCIM. For self-hosting, Lightdash documents a Kubernetes deployment with an official Helm chart or a minimal Docker Compose setup, with PostgreSQL as the metadata database and S3-compatible object storage. Your platform team should check that the pgvector extension is available on your managed PostgreSQL service and that your object storage meets the S3-compatible requirement before procurement is final.

How often does each platform need upgrades when self-hosted?

The two platforms follow different release patterns, so the routines differ. Lightdash ships new versions frequently, with version 2.603.0 released on October 17, 2026, so a self-hosted instance needs a regular upgrade cadence. Metabase publishes support windows: LTS versions are supported for 14 months, and non-LTS versions usually reach end of life after 2 months. Metabase 64 is an LTS release published on 16 September 2026 with end of life on 1 December 2027. Metabase upgrades run application database migrations automatically, and the docs recommend backing up the application database first and reducing a cluster to a single node for major upgrades. Pick an LTS line for Metabase if you want fewer forced moves, and ask Lightdash for its supported-version policy in writing.

What drives the implementation cost and effort for Metabase and Lightdash?

Cost has three parts: software licensing, the infrastructure you run, and the people who build and maintain the setup. Licensing differs most. Metabase Open Source is free, Starter is listed at $100 per month or $90 per month billed yearly, and Pro is listed at $575 per month or $517.50 per month billed yearly, both per the pricing page. Lightdash lists a free self-hosted Open Source edition, Cloud Pro at $3,000 per month, and Enterprise at custom pricing. Effort rises with the number of data sources, the state of your dbt project for Lightdash, SSO and permission design, and the upgrade routine you commit to. Ask any implementation partner for a fixed-scope written proposal that names the deliverables, the environments covered and the handover, since DeployOpen agrees scope, deliverables and timelines in writing before work starts and does not publish a price list.

Can our team do the Metabase or Lightdash work in-house?

Often yes, if the skills exist on the team. Metabase has a lower technical bar for business users and a documented PostgreSQL production path, but governance features that matter to regulated teams sit in paid plans. Lightdash asks more of the engineering side: a dbt project in Git, a Kubernetes or Docker Compose deployment guide aimed at DevOps engineers familiar with those tools, PostgreSQL with pgvector, and S3-compatible storage. Before deciding, list who will own the database, the upgrades, the identity integration, the dbt models and the permission model, and whether each owner has the time. If gaps remain, DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and offers ongoing support as retainers.

How hard is it to move between Metabase and Lightdash later?

Switching cost depends mainly on where your business logic lives. Lightdash metrics sit in dbt YAML in your Git repository, so those definitions stay in version control alongside the dbt models rather than inside the BI tool's own database. That makes the metric logic portable to other tools that read dbt. Metabase keeps questions, dashboards and settings in its application database, so moving those means planning an export or rebuild rather than a file copy. Metabase's H2 to PostgreSQL migration is a separate, documented step that must use the same Metabase version that last updated the H2 file. Ask both vendors to document how their content and permissions can be exported before you commit.

How DeployOpen helps you choose, implement or migrate

DeployOpen plans, implements, integrates, hardens and supports self-hosted open-source platforms inside your own infrastructure, so the Metabase or Lightdash decision can be tested against your data, identity setup and upgrade capacity. We can help you choose between them, build the deployment you pick, or move an existing instance onto a new footing.

How we scope

Written scope lists which business teams, data sources and identity providers the BI platform must serve.
We confirm which features you need on the free edition and which would require a paid plan, such as row-level permissions or SSO.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We deploy the chosen platform in your cloud account, data center or air-gapped network, with its application database configured.
For Lightdash, we connect the dbt project and metric definitions to your Git repository and check that governed metrics resolve correctly.
For Metabase, we set up identity integration, permissions and backups, then test them against your access model.

How we hand over

Deliverables include architecture notes, configuration documentation and a runbook for the chosen BI platform.
We document the upgrade routine your team will follow, including backup steps and version checks before each release.
Handover includes a walkthrough with the team that will own dashboards, metric definitions and access reviews.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover scheduled upgrades to new releases, with testing of metric definitions and permissions before rollout.
Confirm response expectations, upgrade frequency and included testing in the written scope before signing.

Metabase vs Lightdash