Skip to content

Cross-source analysis for data teams

Your data lives apart.
Your question doesn’t.

Join data from connected databases and files in one SQL query. Explore a cross-source question in an on-demand DuckDB session without setting up a pipeline first.

Connect databases and files in an on-demand DuckDB session.

Queries read from the selected sources. Availability, permissions, and the query plan determine cost and freshness.

A closer look at Tangents.

Product preview · Sample data

Tangents / How it connects

Different sources. One conversation.

Illustrative query · Sample data

01Your connected sources

  • Postgres

    orders.production

    pg_orders

  • MySQL

    crm.customers

    mysql_customers

  • Parquet

    regions.parquet

    regions_file

  • SQLite

    catalog.db

    catalog

4 attached · 3 used in this query

02A shared query session

Revenue by regionSQL
SELECT region,
  sum(order_total) AS revenue
FROM pg_orders
JOIN mysql_customers
  USING (customer_id)
JOIN regions_file USING (region_id)
WHERE order_date >= current_date - 30
GROUP BY region;

DuckDB engine

sample_tangent_07 · Federated

Read on demand. Join inside the session.

03One result to work with

Last 30 days

Sample

$557,810

Revenue across regions

North America$284,120
EMEA$179,480
APAC$94,210
3 illustrative rows
  1. 01

    Attach

    Choose sources and aliases

  2. 02

    Push down

    Filters where supported

  3. 03

    Read

    Bring needed data into session

  4. 04

    Join

    Combine relations in DuckDB

No live execution. Filter and projection pushdown depends on the connector and query. Data can move from sources into the session.

Why Tangents

One SQL query across the sources you need.

01

Bring the sources together.

Combine connected databases with CSV, JSON, Parquet, or DuckDB files in a single session.

Databases + working files

02

Test the join sooner.

Explore a cross-source question without building an ETL pipeline first. DuckDB plans the query.

On-demand federated SQL

03

Keep the source in sight.

Browse attached schemas and qualify tables by source so the next person can follow the result.

Inspectable sources and SQL

Put the question across the sources

Compare customer records in PostgreSQL with orders in MySQL. Bring a CSV mapping or a Parquet extract into the same investigation. Select the connections, inspect their schemas, and use source-qualified SQL to make the join explicit.

Illustrative interface

Browse & Query

Query Console

SQLcross-source-revenue.sql
Read only sample
SELECT
  u.id,
  u.name,
  SUM(o.amount) AS revenue
FROM postgres_db.public.users u
JOIN mysql_db.sales.orders o ON u.id = o.user_id
GROUP BY u.id, u.name
ORDER BY revenue DESC
LIMIT 10;

Source work

postgres_db.public.users

Read user identifiers and names at the Postgres source.

Source work

mysql_db.sales.orders

Read order totals and user keys at the MySQL source.

Tangent session

Join, aggregate, sort, limit

Combine the bounded result set in the active query session.

● Sample query completeIllustrative elapsed time: sampleSample rows: 4 shown
No live execution

Results

Sample result grid

Illustrative cross-source query results
u.nameu.idrevenue
Sample user 01usr_sample_001Illustrative $12,480.00
Sample user 02usr_sample_002Illustrative $9,840.00
Sample user 03usr_sample_003Illustrative $7,260.00
Sample user 04usr_sample_004Illustrative $5,910.00

Illustrative results only · Materialization is preview-only

Keep the useful work

Refine the query as you inspect the result. If an intermediate result will support more work, materialize a bounded working set in the session. Otherwise, keep the analysis federated and query the sources again when needed.

Data moves into the session as required by the query plan. Source filters and column selection can reduce the work when the connector supports them. See the supported sources and examples.

Before you get started

A few useful answers.

Talk through your use case
Which sources can I combine?

Supported sources include PostgreSQL, MySQL, SQLite, DuckDB files, CSV, JSON, and Parquet, using connections and files accessible to your session.

Do I need to copy everything into a warehouse first?

No prebuilt ETL pipeline is required. Data still moves into the query session as the plan needs it. Connector support, filters, and the query shape determine how much is fetched.

What determines performance and freshness?

The query plan, source availability, network access, and connection permissions. Begin with selective filters and explicit columns. A federated result is only as current as the sources it reads.

One question. Bring the sources it needs.

Test a cross-source query before committing to a new data pipeline.