Lightdash

Lightdash asks analytics to behave like software. A context layer defines trusted metrics, joins, permissions, business logic and caching once, and everything downstream reads from it, whether that is a dashboard, an AI agent, a data app, an embedded view or the MCP server.

Metrics, charts and dashboards live as files. Changes are previewed from the command line, validated in CI and reviewed in pull requests, so analytics moves through the workflow engineers already trust. Definitions come from dbt projects or from standalone Lightdash YAML pointed at a warehouse.

That single layer is what the rest of the product is built on.

• Conversational analytics: agents answer from the context layer, respect permissions and return queries you can inspect.
• Data apps: build reports, workbooks, slide decks and forecasting tools from a prompt, with permissions and auth already wired in.
• Embedded analytics: an SDK supports row-level security, user attributes and customer-facing permissions.
• Agent skills: install the skills and MCP server so a coding agent can preview and validate before anything lands.
• Warehouse adapters: BigQuery, Snowflake, Redshift, Databricks, Postgres, Trino and ClickHouse among others.

The codebase is a TypeScript monorepo, React, Mantine and Vite on the frontend, Node, Express and PostgreSQL behind it. Self-hosting runs on Docker or Kubernetes with published Helm charts, enterprise features need a license key, and Lightdash Cloud exists for teams that would rather not operate any of it.