Cross-database SQL lets you run a single SQL statement that joins tables, files, and object storage from different systems. Instead of exporting Postgres data to CSV, staging Parquet into a warehouse, or building a replication pipeline, you query the live sources in place.
DBConvert Streams does this with an embedded DuckDB engine: each configured connection is attached as a virtual schema, the query is planned centrally, and results come back without persistent staging or data movement.
Most traditional tools execute queries against a single active connection. Cross-connection joins typically require database-level federation or external pipelines.
DBeaver, DataGrip, and similar tools run queries against a single active connection per SQL editor tab. Cross-database joins depend on database-level federation such as FDW or linked servers.
BigQuery, Snowflake, and Redshift typically require data to be ingested or staged before cross-source joins. External querying is possible but requires additional configuration and managed integrations.
Airbyte, Fivetran, and dbt focus on extracting and loading data into a destination before it can be joined or analyzed. Ad-hoc cross-source queries are not their primary workflow.
Joining data from two databases typically means exporting one dataset to CSV, importing it into a staging table, running the query, then discarding the staging data. Any scope change means repeating the cycle.
DBConvert Streams removes all of this overhead with a built-in federated SQL engine.
Architecture
An embedded DuckDB engine that attaches to your live sources and executes queries in place.
Attach
Each source is attached as a virtual schema
Plan
Query planned centrally by DuckDB optimizer
Execute
Results returned instantly from attached sources
No Staging
No persistent staging or replication required
Results open below the SQL code with page-size controls and pagination for large result sets.
The SQL console keeps query and results in one vertical flow, with pagination at the bottom of the results grid.
Copy-paste queries across databases and files.
Note: pg1 and my1 are connection aliases defined in DBConvert Streams. They represent configured PostgreSQL and MySQL connections.
SELECT
a.first_name || ' ' || a.last_name AS actor_name,
f.title AS film_title
FROM pg1.public.actor a
JOIN pg1.public.film_actor fa ON a.actor_id = fa.actor_id
JOIN my1.sakila.film f ON fa.film_id = f.film_id
LIMIT 20;Joins tables across PostgreSQL and MySQL in a single query — no export, no import, no staging.
(SELECT 'PostgreSQL' as source, film_id, title, release_year
FROM pg1.public.film
WHERE title LIKE 'A%'
LIMIT 5)
UNION ALL
(SELECT 'MySQL' as source, film_id, title, release_year
FROM my1.sakila.film
WHERE title LIKE 'A%'
LIMIT 5);Combines results from PostgreSQL and MySQL into one dataset.
Compare data between source and target before cutover. Verify row counts, checksums, and content match across migration runs.
Use SQL to inspect and filter source data before starting a migration. Identify schema mismatches or data quality issues upfront.
Combine live database records with archived Parquet or CSV exports in S3 for historical analysis without re-importing.
Investigate production vs staging mismatches. Run comparison queries directly without building replication streams first.
Combine operational data from MySQL and PostgreSQL into unified reports without a data warehouse.
Analyze Parquet or CSV exports together with live databases using full DuckDB SQL - aggregations, window functions, and transformations.
Load Mode
The SQL you write to explore is the same SQL that powers a stream. Point it at a target — another database, a file, S3 — and the data moves. No hand-off between tools. No rebuild.
Related workflows
Use the surrounding pages when ad-hoc query work turns into something bigger.
Use the explorer workspace when you want schema browsing, inline inspection, and SQL in the same UI.
Move from validation into snapshot migration when the query output is ready to become the transfer source.
Use the API when you want to script query-driven workflows, stream setup, or operational checks.
Over MCP, Claude or Cursor drafts the federated SQL, runs it read-only, and hands back the rows.
No. Sources are attached as virtual schemas, and the query reads from them in place. There is no persistent staging, no copy step, and no warehouse ingest.
PostgreSQL, MySQL, and file sources (Parquet, CSV, JSON), including files in S3. Each configured connection becomes a virtual schema you can reference in SQL.
DuckDB SQL. The embedded DuckDB engine plans and executes the query, so window functions, CTEs, aggregations, and file scans all work the same as in DuckDB itself.
Both, depending on what the query asks for. When you write WHERE country = 'DE' against a PostgreSQL table, the filter is pushed down to PostgreSQL, which uses its own indexes and returns only the matching rows over the network. The same goes for column selection — only the columns you reference are pulled. Cross-source joins are different: PostgreSQL and MySQL do not see each other, so DuckDB pulls the relevant rows from each side (already filtered by the pushdowns above) and performs the join itself.
No. The whole point is that you do not stage data into BigQuery, Snowflake, or Redshift before joining. If you already have a warehouse, you can still query it as one of the sources.
Queries are read-only against the attached sources and respect the credentials of the configured connection. Treat heavy joins the same way you would treat any analytical query against a live OLTP database.
Open the explorer to run queries against your live connections. Move into migration or API automation when the SQL is doing the right job.