Looker cost vs self-hosted Lightdash

Cost components on each side and what recurs

This table sets each cost component of a Looker edition against the matching component of a self-hosted Lightdash deployment, marking whether it is paid once or recurs. Read it as a checklist for a quote request: the recurring rows drive the annual total, while the one-time rows drive the cost of the migration itself.

What moves the totals most for Looker and Lightdash

Looker and self-hosted Lightdash share one cost center that is easy to miss: the warehouse bill, which grows with query volume and model size. The licensing, hosting and people costs sit on top, and each one scales differently with users, edition needs and upgrade cadence.

How to build the comparison with your own numbers

This sequence turns a Looker renewal into a like-for-like cost model, so you compare your actual seats, warehouse spend and conversion effort with a self-hosted Lightdash footprint instead of list prices. The result is a one-time and annual cost table over a horizon you state in advance.

1. Inventory Looker seats and editions

   Pull the Looker contract and order form and record the edition, the number of named users by role, any add-ons, the renewal date and the notice period. Ask your account team to confirm which charges are fixed and which scale with usage. Done when every license line in the contract maps to a row in one spreadsheet, with the source clause noted beside it.

2. Count LookML objects and dependencies

   Have a LookML developer count views, explores, models, dashboards, Looks and persistent derived tables (PDTs) in the project repository, and note which dashboards are used weekly. Record which PDTs are materialized in the warehouse, since each one carries storage and rebuild load. Done when you have a count per object type and a list of the top used dashboards that a migration must reproduce.

3. Measure dbt readiness

   Check whether the warehouse transformations already live in a dbt project, which dbt version runs in production, and whether dbt Core or dbt Cloud is the execution target. Lightdash reads its semantic layer from dbt and supports dbt v1.4.0 and above, so any model that is not in dbt will need to be built there. Done when you can state the share of LookML measures that already have a matching dbt model and column.

4. Price the warehouse query load

   Export the last full billing period of warehouse charges and split them into scheduled transformation jobs, PDT rebuilds, interactive dashboard queries and extracts. Tag which share is caused by Looker, because Lightdash and Superset issue their own queries and the same dashboards may scan data differently. Done when you have a monthly warehouse cost baseline by source, and a note on which costs stay the same after migration and which may change.

5. Cost the hosting footprint

   Estimate the compute for Lightdash on Kubernetes with the official Helm chart or on a minimal Docker Compose setup, plus a PostgreSQL metadata database and S3-compatible object storage. Your platform or cloud team sets the rates, and any Enterprise on-premises deployment also needs a LIGHTDASH_LICENSE_KEY and a PostgreSQL database with the pgvector extension. Done when each infrastructure line has a unit, a quantity and a rate sourced from your own price sheet or a written quote.

6. Scope conversion and validation effort

   Turn the object counts from step two into a conversion plan covering metric translation into dbt YAML, rebuilt joins and explores, PDT replacement, and side-by-side dashboard checks. Estimate the effort either from your own team's capacity or request a fixed-scope quote from an implementation partner, using the same object list for both. Ask each quote to state included items, exclusions, client-side dependencies, and the acceptance tests used to close the work. Done when every conversion line has a named owner and an estimate source.

7. Model one-time and annual lines

   Build a table over a stated horizon, for example three years if that matches your budgeting cycle, with one-time items (conversion, validation, initial setup, training, parallel running) in one column and recurring items (Looker renewal avoided, hosting, storage, warehouse change, support, upgrades, and staff time for the Lightdash upgrade routine) in another. Run a sensitivity check on seat count and warehouse query volume, since those two drivers move the total most. Done when the model shows the cumulative cost each year for both paths and the assumptions behind each cell are documented for review.

Why LookML conversion and dbt work decide the first-year total

Costs teams forget on each side

Licence fees are the line item most teams compare, but the totals shift on both sides once the work of running the platform is counted. The cards below cover costs that appear after the decision, on the Looker side and on the self-hosted Lightdash side, and each one is a question to put into a written scope or quote.

Which option changes the math: Lightdash, Superset or staying on Looker

Questions buyers ask about Looker and self-hosted Lightdash costs

When a self-hosted total is lower and when it is not

What a fixed-scope implementation quote should cover

This sequence turns the cost comparison into a written scope that both sides can price and test. Each step ends with an agreed artifact, so the quote follows from documented sources, deliverables, acceptance checks and an operating model rather than from assumptions.

1. Inventory the Looker sources and models

   Start by listing the LookML projects, their Git repositories and branches, the views, explores and persistent derived tables in scope, and the warehouse connections they read from. Your team confirms which Looker instance and edition runs each project, and which dashboards and Looks are still used. The step closes with a signed inventory that fixes the model count and the warehouse objects in scope, because those counts drive conversion effort and query load.

2. Agree the dbt and warehouse sources in writing

   Confirm which dbt project will hold the Lightdash metrics, whether it already exists, and which dbt version and target (dbt Core or dbt Cloud) the team runs. Decide in writing whether persistent derived tables move into dbt models or stay in the warehouse, and who owns that decision. DeployOpen and your data team sign off on the source list, so nothing is priced against an undefined dbt starting point.

3. Define the conversion deliverables

   Write down exactly what the conversion produces: dbt YAML metric definitions under the meta metrics keys, rebuilt explores and joins as dbt models, recreated dashboards, and the list of LookML logic that is retired or moved into the warehouse. Each deliverable gets a named owner and a short description of what it contains. The step is complete when every LookML object in the inventory maps to a deliverable or to a documented exclusion.

4. Set validation criteria for side-by-side dashboards

   Agree how converted dashboards will be compared with Looker output before the Looker renewal decision. Typical criteria are matching row counts and metric values for an agreed set of dashboards and filters, the same date and timezone handling, and documented differences that business owners accept. Your analysts run the comparison in both tools, and the step closes when the acceptance list is signed and every open difference has an owner.

5. Specify hosting, upgrades and backup handover

   Document the target environment, including the Kubernetes or Docker Compose option, the PostgreSQL metadata database with the pgvector extension if the Enterprise license is in scope, S3-compatible object storage, secrets handling and network placement. Define the backup schedule and restore test, the upgrade routine for frequent Lightdash releases, and who receives credentials and runbooks. The handover is complete when your operations team has the runbook and has observed a restore.

6. Decide the license tier and identity setup

   Record which features the business needs, such as SSO with SAML or SCIM, custom roles, service accounts or AI features, and map each one to the free Open Source edition or a paid Lightdash plan. Your security and identity team confirms the identity provider and group mapping. The step closes with a written license decision, so the quote states which license keys, if any, the implementation includes and which are purchased separately from Lightdash.

7. Agree the support or retainer model

   Choose between a fixed-scope handover with no ongoing services, a support retainer, or a retainer that covers upgrades and continuous testing, and write the response expectations, the named contacts and the change process for new dashboards. Ask for the quote to show these as separate line items so recurring costs are visible next to one-time conversion work. The step is complete when the chosen model is in the signed scope.

8. Issue the written quote from the signed scope

   DeployOpen does not publish a price list, so the quote follows from the written scope agreed in the steps above. Ask the quote to state each deliverable, the assumptions behind it, what the client provides, what is one-time and what recurs, and which warehouse query costs and Looker renewal costs sit outside the quote. The quote is accepted when the scope, deliverables and validation criteria match what was agreed.