Power BI Connection Management Issues on Trino

Hi padiga-isw , Thank you for reaching out to the Microsoft Community Forum.

Even if the Simba driver is behaving within the ODBC spec, Power BI doesn’t signal session end or query end semantics in a way that Trino expects. Power BI treats the connection handle as something it can close asynchronously and unfortunately the driver can’t influence that lifecycle. The reason other drivers behave cleanly isn’t because Power BI switches strategies for them, but because those drivers internally implement additional coordination or cleanup logic that absorbs Power BI’s threading pattern. That’s why this really does sit with the Simba/Trino ODBC team, the only workable fix is inside the driver, not in Power BI.

On the repeated metadata executions, the difficulty isn’t that your queries are complex, it’s simply that Power BI treats any native SQL (even a plain SELECT * FROM table) as opaque. Since it can’t fold or reshape it, it must fully execute it several times. Power BI doesn’t provide any metadata intent flags, so from the driver’s perspective each execution looks like a normal fetch. That means the driver cannot short circuit the execution or automatically turn it into a schema only query. The only lever a driver has is lowering the cost of the fetch phase (rowset size, streaming mode, partial buffering), which can reduce data transfer but cannot stop Power BI from executing the full scan.

So unfortunately, there isn’t a Trino side configuration that prevents Power BI from pulling large amounts of data during metadata discovery. The limitation is in how Power BI handles native SQL and the only real solutions today are either reducing the scan cost on the engine/driver side or exposing a lighter object for Power BI to read.