Query Across Postgres, MySQL, SQL Server & MongoDB at Once
Your users are in Postgres. Your events are in MongoDB. This quarter's targets are in a spreadsheet someone emailed you. Answering one business question shouldn't mean three exports and a manual VLOOKUP. With dbclaw's Federate feature you can join across all of them in a single query — and ask for it in plain English.
This is the problem federated queries solve: data that logically belongs together but physically lives in different systems. Below is what "federated query" means, how dbclaw does it, and a worked example you can copy.
The multi-database problem
Most teams don't have one database. They have:
- A relational database (Postgres, MySQL, SQL Server) for the core app.
- A document store (MongoDB) for events, logs, or flexible data.
- Spreadsheets (Excel, CSV) for targets, budgets, and anything finance touches.
The usual answer is to build a warehouse and ETL pipelines. That's the right call at scale — but it's heavy when you just need to answer "which of our active Postgres users triggered the most events in MongoDB last week, versus the targets in this spreadsheet?" right now.
What "federated query" means
A federated query runs across multiple independent data sources as if they were one. Instead of moving all the data into a single database first, the query engine pulls what it needs from each source on the fly and joins the results together.
How dbclaw does it
dbclaw embeds a real query engine — Apache DataFusion — directly in the app. Each connected database is exposed to that engine as a table source. When you run a federated query:
- dbclaw pushes down the parts of the query each source can handle natively (filters, projections) so it only pulls the rows it needs.
- It streams those results into the embedded engine.
- The engine performs the cross-source joins and aggregations locally, on your machine.
And because dbclaw is an NL→SQL tool, you don't have to write that federated SQL by hand — you can describe the question in English and let it assemble the query.
What you'll need
- dbclaw installed (download).
- Two or more connections set up — any mix of PostgreSQL, MySQL, SQL Server, SQLite, MongoDB, CSV, JSON, or Excel.
- An AI model (cloud or a local Ollama model).
Step 1 — Connect two or more sources
Add each source from the connection switcher (top-left). For example: a PostgreSQL connection for users, a MongoDB connection for events, and an Excel file for targets. Test and save each one.
Step 2 — Open the Federate tab
The Federate tab is where cross-source queries live. Select the connections you want to include so the engine knows which sources are in play.
Step 3 — Ask across them in plain English
For each active user in Postgres, count their events from
MongoDB in the last 7 days, and compare it to that user's
target from the targets spreadsheet. Show the 20 users
furthest below target.dbclaw turns that into a federated query, pulls from each source, joins them in the embedded engine, and returns one unified table — no manual exports, no VLOOKUP.
A worked example
Say you want a single leaderboard combining three systems:
| Source | Holds |
|---|---|
| PostgreSQL | users (id, name, email, status) |
| MongoDB | events (user_id, type, created_at) |
| Excel | targets (email, monthly_target) |
Ask: "Join active Postgres users to their MongoDB event counts this month and their Excel target by email; show name, events, target, and the gap, sorted by largest gap." One question, one table, three systems.
Read-only and local, as always
- Read-only: federated queries never write to any of your sources.
- Local: the joins happen in the engine on your machine; only your question and the schemas go to the AI provider (and nothing at all with a local model).
- Credentials in the keychain: every connection's secrets stay in your OS keychain.
Limits & tips
- Filter early. The tighter your question (date ranges, status filters), the less data each source has to return — and the faster the join.
- Joins happen locally. Federation is ideal for combining moderate result sets across systems, not for grinding billions of rows from each source in one go — that's what a warehouse is for.
- Name things clearly. If your column names are cryptic, dbclaw's semantic layer lets you give the AI friendly names and business metrics so it maps your question correctly.
FAQ
Can I really join MongoDB to a SQL database?
Yes. Each source is exposed to the embedded engine as a table, so a document collection and a relational table can be joined in the same query.
Do I need a data warehouse?
Not for this. Federation answers cross-system questions on demand without building pipelines. At very large scale a warehouse still has its place.
Does my data get uploaded anywhere?
No. The join runs locally on your machine. Only your question and the schemas reach the AI provider — and with a local model, not even that.
Join your databases in one question
Free, local-first, read-only. Connect Postgres, MongoDB, Excel and more.
Download dbclaw for Windows