Multi-source analytics: one question, all your data

Multi-source analytics is asking one question in natural language and getting a single, unified answer pulled from every connected source — instead of exporting each source and joining the results together by hand.

The fragmented-data problem

Ask a straightforward question — how much of this quarter's pipeline has actually closed? — and the honest answer usually requires three tabs open at once: a sales pipeline tracked in a spreadsheet, a bookings or orders table in a production database, and maybe a usage log that shows whether the account is even still active. None of those systems talks to the others, and none of them was built with the other two in mind.

The traditional fix is manual, and it repeats every single time someone asks. Export the spreadsheet to CSV. Pull a report from the database, or file a ticket asking an engineer to run a query. Open both in a third tool, line up the columns, VLOOKUP or copy-paste until the numbers sit side by side — and only then start the actual analysis. By the time an answer exists, it already describes the past: the spreadsheet was exported an hour ago, the database has moved on since, and next week's version of the same question starts the whole process over from zero.

The deeper problem isn't that stitching data together is tedious, although it is. It's that fragmentation gates every cross-system question behind whoever knows how to do the stitching. A question that spans a spreadsheet and a database stops being something you can just ask — it becomes a request that sits in someone else's queue until they have time for it.

What multi-source analytics is

Natural language query already solves this for a single table: ask a plain-English question, the engine writes and runs the SQL, and you get an answer back. Multi-source analytics extends that same idea across everything you've connected. Instead of picking one sheet or one database to query, you ask the question once, and the platform works out which of your connected sources actually hold the relevant data, pulls from all of them, joins on the fields that relate them, and returns one answer — not several partial answers you still have to line up yourself.

This is what a multi-source Workbook is for. Add a Google Sheet, an Excel file, and a database like MySQL or PostgreSQL to the same Workbook, and tableArth.ai treats them as one connected surface instead of three separate uploads. Ask a question that only makes sense with information from two of them, and the engine reaches across both automatically. You never tell it which source to use — you just ask.

What changes is where the joining happens. It used to happen in a spreadsheet, by hand, before the question could even be asked. Now it happens inside the query itself, at the moment you ask — which means the question can be asked as often as anyone likes, by anyone, with no stitching step standing in between.

How a Workbook makes it possible

A Workbook is connected data that stays in sync. It's the container that holds every source behind an analysis — Google Sheets, Excel files, and databases such as MySQL and PostgreSQL, with more connectors on the way — and it keeps each one current on its own. As the underlying spreadsheet or database changes, the Workbook's picture of it changes too, with no re-upload and no re-export required.

Sources inside a Workbook don't have to be flattened into one table first. tableArth.ai reads multi-tab spreadsheets and multi-table databases as a set of related tables, the same way it would read a real schema, so you can ask a question that spans two tabs in one file — or two tables in one database — and get a joined answer with no manual VLOOKUP. Multi-source analytics is that same joining behavior applied one level up: instead of relating tabs inside a single file, the Workbook relates tables and tabs across entirely different files and databases at once.

In practice, the shape of it is simple. Every source you add syncs into the Workbook independently, and all of them stay live at the same time:

Sales pipelineGoogle Sheets

OrdersPostgreSQL

EventsMongoDB

Workbook Synced

Sales pipeline ✓ live

Orders ✓ live

Events ✓ live

A worked example

Here's what that looks like end to end. Say your sales pipeline lives in a Google Sheet — one tab per rep, with deal stage, expected close date, and deal size — and your actual bookings live in a PostgreSQL orders table, populated by your billing system the moment a deal is signed. The two have never been joined, because doing it by hand means exporting the sheet, exporting a query result, and matching rows on a customer name that's spelled two different ways in each system.

Add both to a Workbook and ask: "Blend the Sheets pipeline with Postgres orders — how much of Q3 pipeline actually converted, by rep?" tableArth.ai identifies the relevant tab in the spreadsheet and the relevant table in the database, works out how the two relate, joins them, and returns one answer with a chart — not a pipeline figure from the sheet and a bookings figure from Postgres that you'd still have to compare by hand.

app.tablearth.ai / workbook

Q3 Pipeline Workbook

Ask Sources

Sheets PostgreSQL

You Blend the Sheets pipeline with Postgres orders — how much of Q3 pipeline actually converted, by rep?

tableArth.ai · joined 2 sources · 2.8s

Priya converted the highest share of pipeline at 68%, followed by Marcus at 54% and Elena at 41%. Figures match each rep's Sheets pipeline against booked rows in the Postgres orders table.

Pipeline → booked, by rep Q3 · % converted

PriyaMarcusElena SamJordan

Illustrative product preview — sample data.

Because both sources are connected rather than uploaded, that same question gives you today's answer next week too. The Workbook re-syncs with the sheet and the database on its own, so the conversion number moves as deals actually close — no one has to remember to re-run the export.

What to look for

Not every tool that connects to a spreadsheet and a database is doing multi-source analytics — some just let you switch between them. A few things separate a real multi-source answer from a source picker with extra steps:

• One question, every source. You shouldn't have to specify which source holds the answer before you ask — that's still stitching, just done inside the tool.
• Joins across sources, not only within one. The same joining you'd expect across tabs in a spreadsheet or tables in a database should work across sources too, with shared keys resolved automatically.
• Sync, not snapshot. A source that was uploaded once will always answer as of that upload. A source connected inside a Workbook stays current.
• Databases stay where they are. tableArth.ai queries PostgreSQL, MySQL, MongoDB, and Druid inside your own private environment, so nothing has to move to be joined with a spreadsheet.
• Reliable at real size. Multi-source questions often touch the biggest sheet in the Workbook — large uploads should be as reliable as small ones, without timing out.
• Clarity when the question is ambiguous. Cross-source questions are more likely to be ambiguous than single-table ones. tableArth.ai asks a clarifying question instead of guessing which source or field you meant.

The common thread is that the source boundary should be invisible from where you're asking the question. If it isn't, you're still doing multi-source analytics by hand — just with nicer formatting.