All your sources. Treated as one database.

Join across every database, warehouse, and lakehouse in a single SELECT — no pipelines, no sync jobs. Copy data only when you actually want to.

Copy-optional

Only copy data if you want to

We firmly believe that copying data should be an optimization strategy — not a requirement. Cross-source joins can be surprisingly fast, and they come with some added benefits.

Fresher data — every query reads the source live, nothing to sync
More flexibility — change the query freely, no pipeline to rebuild
Lower compute — pay only when you actually run the query
Nothing to maintain — no ETL jobs to babysit or watch drift

postgres ⋈ snowflake — one query

-- One SELECT. Two databases. No copies.
SELECT c.name,
       c.region,
       SUM(o.total) AS lifetime_value
FROM postgres.crm.customers c
JOIN snowflake.sales.orders o
  ON o.customer_id = c.id
GROUP BY 1, 2;

One SQL dialect across every source. Query Postgres, Snowflake, MySQL, and your lakehouse with the same standard SQL — no juggling per-engine syntax.

Materialize in dbt

Need it faster? Pre-join it in dbt.

Hitting a heavy cross-source view constantly? Pre-join it in dbt. Materializing a cross-source join is just a model with materialized='table' — the same SELECT, now pre-computed and refreshed on every dbt run. As easy as pre-joining two tables in the same database. Seriously.

Just a dbt model with materialized='table' — the same SELECT
Lands in any connected source you target — here, we chose Redshift
Pre-computed and refreshed on every dbt run
Governed like any other table — RLS and masking still apply

See how dbt works on Datattach →

customer_ltv.sql — a dbt model

-- models/marts/customer_ltv.sql
{{ config(materialized='table', database='redshift') }}

SELECT c.name,
       c.region,
       SUM(o.total) AS lifetime_value
FROM postgres.crm.customers c
JOIN snowflake.sales.orders o
  ON o.customer_id = c.id
GROUP BY 1, 2

Federate by default. Copy when it pays off.

Same query either way — you choose where each view lands on the spectrum, table by table.

Federated · default

Materialized · optional

Freshness

Always live

As of last refresh

Compute cost

Only when queried

Storage + scheduled refresh

Setup

None — just query

One dbt model

Best for

Infrequent or exploratory views

Hot, repeated, latency-sensitive views

Query first. Copy later — if ever.

Run a cross-source join against canned data in the live demo, then book a walkthrough against your own sources.

Try the live demo → Book a demo

All your sources. Treated as one database.

Only copy data if you want to

Need it faster? Pre-join it in dbt.

Federate by default. Copy when it pays off.

Query first. Copy later — if ever.

See Datattach in action