How does iDBQuery handle large datasets and performance?

iDBQuery is built to query large data in place rather than pull it all into memory: - It pushes filtering, grouping and aggregation down to the source database or warehouse, so your engine's indexes and compute do the heavy lifting. - It returns aggregates, samples and top-N results rather than dumping raw rows, so a question over millions of records still comes back with a small, fast result. - It writes SQL that lets the source do what it is optimised for, instead of scanning everything client-side.

A worked example: asking 'total revenue by month for the last three years' over a 50-million-row orders table runs as a single grouped query on your database and returns a dozen numbers, quickly, because the database aggregates before anything is sent back.

The differentiator is query-in-place: iDBQuery does not force-copy your data into its own store, so performance rides on the engine you already have, and there is no nightly load to keep fresh. For very large or federated workloads, it leans on your warehouse's scale. If a question would be genuinely heavy, iDBQuery shows the SQL so you or a DBA can see exactly what will run and add an index if needed. In practice, most questions return in seconds.