Query connected databases and files together with federated SQL

Related data often lives in separate systems: operational records in Postgres, orders in MySQL, a local SQLite file, and a working CSV from a teammate. An exploratory join should not always mean building a new pipeline before the question can be tested.

Tangents is a federated query workspace for that work. It attaches selected SyneHQ connections into a DuckDB-backed session so you can inspect their available schemas and write one source-qualified SQL query across them. Read the federated analytics documentation for the supported-source overview.

Start with the question, not a pipeline

Create a Tangent from Tangents, give the session a useful name, and select the connections that contain the records you need. The selected connections are attached to that Tangent session; they are not copied into a new warehouse as a prerequisite for the query.

No prebuilt ETL is required to run a federated query. Data does still move from sources into the query session when the plan needs it for a join, aggregate, sort, or result. Tangents plans the work with DuckDB and can push filters and projections down to sources when the connector and query shape support it, reducing the columns and rows fetched.

The practical boundary remains the sources themselves. A source must be available, its connection must allow the requested objects, and its engine must support the part of the plan assigned to it. These conditions affect what can be read, how current the result is, and how much work the query requires.

Sources that can meet in one session

Use a Tangent to combine sources such as:

• Postgres, MySQL, SQLite, and DuckDB files.
• CSV, JSON, and Parquet files for a working comparison.
• Existing SyneHQ connections that have already been configured for the team.

For connection and session details, see how Tangent Lake works.

Browse before composing the join

Open a Tangent card and choose Browse & Query. The schema browser shows the attached sources and the schemas, tables, and fields made available through each connection. Check names, types, and join keys before writing a query, especially when similar concepts come from different engines.

Then open the Query Console and qualify each relation with its source and schema. Clear aliases help make the join readable in review and distinguish fields with the same names.

Use the console as an investigation surface rather than assuming every compatible-looking field can be joined safely. Confirm the grain of each relation, the time window represented by the source, and whether the keys are stable enough for the comparison.

Keep source context in the SQL

Source-qualified relations make the plan easier to inspect:

connection_name.schema_name.table_name

That context matters when databases contain similarly named users, orders, or events tables. It also helps another reviewer trace a result back to the connection and objects that supplied it.

Postgres and MySQL in the same query

This official example joins users in Postgres to orders in MySQL:

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;

Start with a small result set while you validate the join and aggregation. The query reads the identifiers, names, order amounts, and other required data according to the plan; it does not assume that every table is transferred in full.

Bring a working file into the investigation

A file can be useful when it contains a temporary mapping, target list, or event extract that needs comparison with a connected database. For example:

SELECT u.email, c.last_login
FROM postgres_db.public.users u
JOIN read_csv_auto('https://example.com/logins.csv') c
  ON u.email = c.email;

The same pattern can apply to JSON or Parquet where the session can access the file. Treat the file location and its contents as part of the query's operating context, not as a replacement for the database's source-of-record rules.

Inspect the result, then decide whether to keep it

Use the console to test the logic, inspect the result, and adjust filters or projections. The query plan determines which work can happen at a source and which data must be brought into the Tangent session to complete the operation. A broad join or aggregation can require more source work than a bounded inspection.

Materialization is optional. Create a session working set when the same intermediate result will support follow-up exploration or a repeat job; otherwise, leave the analysis federated and rerun the query when the question changes. See the materialization example for a CREATE TABLE ... AS pattern.

Operating guidance

• Select only the connections needed for the question, and verify that their schemas and permissions are current.
• Begin with explicit columns, selective filters, and a LIMIT; expand after checking the result and query behavior.
• Use source-qualified names and clear aliases so the origin of each field remains visible.
• Materialize a bounded working set only when reuse justifies it; record the source timing and query assumptions for work that will be revisited.
• Monitor source availability and connection credentials. Tangents is available in SaaS and enterprise self-hosted deployments; use the deployment that fits the systems you need to reach.