The standard advice for “we have data in too many places” is to build a warehouse: stand up a central store, write pipelines to copy everything into it, model the schema, and keep the copies in sync forever. It works — eventually — but it is months of engineering, a permanent maintenance burden, and a second copy of your data that is already stale the moment it lands.
Federation instead of copying
iDBQuery takes the opposite path. Instead of moving your data, it connects to your sources where they already live — databases, spreadsheets, documents and APIs — and presents them as one live, queryable model. A question becomes a query that runs against the real systems, so the answer reflects the state of your business right now, not the state of last night’s load.
There are no pipelines to author, no transformation jobs to babysit, and no warehouse bill that grows with every table you forget to prune. You connect a source in minutes and it is part of the model.
When a warehouse still makes sense
Heavy historical analytics at petabyte scale still belongs in a dedicated store, and we are happy to sit on top of one when you have it. But for the everyday question — “how does this quarter compare, and where exactly did that figure come from?” — a live federated model answers faster and stays honest, because it never drifts away from the systems of record.
The deeper win is time-to-answer. A warehouse pays off in quarters. A live model pays off the afternoon you connect your first two sources and ask them a question together.
Keep reading
Why cited answers beat a black-box chatbot
A confident number you cannot verify is worse than no number at all. We made “show your working” a hard guarantee — every figure traces to the exact source row it came from.
FINANCEPlain-language querying for finance teams
Variance, runway, cohort margins — answered from the actual ledger, in seconds, by someone who has never written a line of SQL. And every number is one click from its source.
PLATFORMThe semantic layer: understanding a database it has never seen
Real schemas are cryptic — tables called tbl_acct_2, columns named flg and amt3. The semantic layer learns what they mean, so plain-language questions hit the right rows the first time.