Lantide Data
← Back to blog
Integrate with Lantide

Why Do You Still Need Lantide When Using dbt?

dbt is built for production transformations, tests, and CI. For one-off hypothesis validation, use Lantide as a local sandbox, then write standard SQL back to the dbt repository once the definition is proven.

dbt turns reviewed SQL into repeatably deployable models with tests, version control, CI, and development techniques such as defer, clone, and selector that reduce rebuild cost. See Defer, dbt clone, and Optimize costs.

You do not need a PR for every hypothesis that changes its denominator one afternoon. Lantide acts as a local sandbox: validate the definition without polluting the dbt repo or repeatedly scanning a cloud warehouse, then write it back as a ref() model if it deserves long-term maintenance.

Where the production pipeline creates friction

1. Temporary logic fills the repository

If every one-off question adds tmp_marketing_analysis_v2.sql, a PR, and a CI run, the project quickly fills with short-lived models. Slim CI reduces work, but review and merge cost remain.

2. Exploration and deployment have different feedback loops

Defer and clone reduce the need to rebuild an entire upstream chain for one downstream change. But repeatedly trying joins or changing filters on large warehouse tables can still create meaningful compute. Exploration needs rapid iteration; deployment needs stricter tests and review.

3. Hypotheses often come before formal semantics

A Semantic Layer is appropriate for defined, high-accuracy enterprise metrics. Ad hoc and narrow explorations can be validated with a more flexible query first, then promoted into the semantic layer if warranted. See Semantic Layer vs. Text-to-SQL.

dbt production marts (authoritative transformations and tests)
        │
        │  Read or materialize through a configured DB / MCP source
        ▼
Lantide local sandbox (DuckDB exploration, Plan, paginated cache)
        │
        │  Once the logic is worth maintaining
        ▼
Write back to a dbt model (ref(), tests, CI review)

Lantide does not have an official dbt connector. Connect to warehouse tables that dbt has written, or to an MCP / database source that exposes them, then query locally. See MCP Sources basics and USER_GUIDE §4.6.

What the sandbox can do

Materialize once, query repeatedly locally

Use tools such as mcp_pull_table on a connected source to materialize only the tables needed for exploration. The initial pull and later refresh still have remote and storage costs; the saving is repeated experimentation on the same materialized result instead of hitting the warehouse for every ten-line filter change.

Paginated cache and Source Run

Exploration SQL can become a persistent tab; Source Run can rebuild the upstream chain when needed. Local materialized caches are usually temporary, session- or workspace-level results. After reopening or changing workspaces, you may need to reconnect and run Source Run again—they are not a permanent warehouse. See USER_GUIDE §7–8.

Turn a validated query into an engineering artifact

After local validation, rewrite the logic in dbt style instead of copying local table names directly:

-- Logic validated in the Lantide sandbox
SELECT o.customer_id, COUNT(o.order_id) AS total_orders,
       SUM(o.amount) AS lifetime_value
FROM "mcp_wh__fct_orders" o
INNER JOIN "mcp_wh__dim_customers" c ON o.customer_id = c.customer_id
WHERE c.is_active = true
GROUP BY 1;

-- Rewrite it for dbt
WITH orders AS (SELECT * FROM {{ ref('fct_orders') }}),
customers AS (SELECT * FROM {{ ref('dim_customers') }})
SELECT o.customer_id, COUNT(o.order_id) AS total_orders,
       SUM(o.amount) AS lifetime_value
FROM orders o INNER JOIN customers c ON o.customer_id = c.customer_id
WHERE c.is_active = true
GROUP BY 1;

Add tests, materialization, naming, and the normal PR / CI process after writing it back.

A practical three-step workflow

  1. Confirm the source: a warehouse connection or MCP Source can read the relevant marts; materialize only what this hypothesis needs.
  2. Validate locally: use a Plan to define the denominator and time window, iterate in DuckDB, and check fan-out before joins. See JOIN fan-out.
  3. Promote only durable logic to dbt: rewrite with ref(), add tests, and follow the existing Slim CI / defer process.
Dimension Primarily dbt dbt with Lantide
Production transformations and tests Yes —
One-off or early hypotheses Higher friction Local sandbox
Remote compute Charged for each build / large query Repeated queries after materialization run locally
Repository cleanliness Temporary models can accumulate Validate before adding to the repo

Conclusion

dbt turns correct transformations into deployable assets; Lantide provides a low-friction, reviewable local sandbox before that point. Validate first, then use ref()—usually more sustainable than pushing every question into CI.

Next steps

  • Read Why SQL still matters in 2026.
  • Take the next hypothesis that is not yet in the Semantic Layer, validate it in Lantide, and then decide whether to open a dbt PR.

References