Power BI Connection Management Issues on Trino

[padiga-isw]

Hi Team,

We've identified some connection management issues when using Power BI with Trino via ODBC drivers, and we'd like to understand if these are known limitations or if there are recommended workarounds.

Issue 1: Cross-Thread Connection Cleanup
Power BI appears to use different threading strategies depending on the ODBC driver. With some drivers (like Simba Trino ODBC), we observe:

Query execution thread (e.g., thread A): Allocates connection, executes query, fetches data, frees statement handle, then terminates
Cleanup thread (e.g., thread B): Later calls SQLDisconnect and SQLFreeHandle(DBC) on the connection created by thread A
This cross-thread cleanup pattern causes queries to remain in RUNNING state on the Trino server until client timeout, as the proper termination signals aren't sent before the connection is closed from a different thread.

With other drivers (CData, ZappySys): Power BI uses same-thread cleanup, and queries terminate properly.

Questions:

1. How does Power BI determine which threading strategy to use for different ODBC drivers?
2. Are there specific driver capabilities or flags that influence this behavior?
3. Is there a way to configure Power BI to use same-thread cleanup for all drivers?

Issue 2: Multiple Query Executions for Metadata
Power BI runs the same query multiple times for metadata discovery, type validation, preview, and data loading. Since Power BI cannot modify native queries (e.g., adding LIMIT clauses for Top N sampling), large queries execute fully multiple times.

Questions:

1. Is there a way to optimize this for Trino queries, especially when working with large datasets?
2. Can Power BI leverage Trino-specific metadata endpoints to avoid running full queries for schema discovery?

Any guidance or documentation on these behaviors would be greatly appreciated. We're trying to improve the experience for users connecting Power BI to Trino.

Thank you

[padiga-isw]

Hi @v-hashadapu, Sorry for the late reply.
The Simba driver follows ODBC standards - the cross-thread cleanup isn't irregular behavior per se. The issue is that Power BI delays calling SQLDisconnect and SQLFreeHandle from a different thread, during which time queries remain in RUNNING state on the Trino server especially noticeable if the client timeout is less and server abandons the query before SQLDisconnect is called.

Regarding the workaround for multiple executions, our issue is with simple tables containing lot of data rather than complex queries. When Power BI tries discovering metadata, it executes the query multiple times, each operation transfers significant data over the network that Power BI immediately discards as it just needed metadata of the result and not the result itself. Is there anything we can configure on Trino driver's end that can fix this?

Thanks

[v-hashadapu · Accepted solution]

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.

[lbendlin]

Please follow the article link that I posted. It gives advice on how to reduce the meta query impact.

[v-hashadapu]

Hi @padiga-isw , Hope you're doing okay! May we know if it worked for you, or are you still experiencing difficulties? Let us know — your feedback can really help others in the same situation.

[v-hashadapu]

Hi @padiga-isw , hope you are doing great. May we know if your issue is solved or if you are still experiencing difficulties. Please share the details as it will help the community, especially others with similar issues.

[v-hashadapu]

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

Power BI doesn’t expose or document any way to control how it manages ODBC connections at a threading level. The cross thread cleanup you’re seeing with the Simba Trino ODBC driver isn’t something Power BI lets you configure. Since other ODBC drivers behave correctly and only the Simba driver shows this cross thread teardown, the only place that can confirm or resolve it is the Simba/Trino driver team as said by @lbendlin .

On the multiple execution issue, this is expected behaviour whenever Power BI is working with a native SQL statement that it cannot rewrite or fold. It has to execute the full query several times for schema discovery, validation, preview and finally for the actual load. Power BI doesn’t use Trino’s metadata endpoints and there’s no supported way to make it do so. The practical workaround is to expose a view, table or a lighter wrapper on the Trino side, so Power BI isn’t forced to re-run expensive logic just to understand the shape of the data.

[lbendlin]

Don't have answer for issue 1 (that is more of a question for SIMBA ?)  but here's some guidance for issue 2

Chris Webb's BI Blog: Why Is Power BI Running My SQL Query Twice?

Chris discusses some strategies to reign in the incessant metadata queries, and to make them at least less annoying.