Creating a connector that uses a native component / ADBC

[SQLGuy]

Hello,

I would like to create a connector that uses the Arrow FlightSQL ADBC driver, which seems to be already available with Power BI Desktop in libadbc_driver_flightsql.dll. However, I cannot find any examples or documentation on connectors that use native components or ADBC. Can someone point me to somewhere to find such information?

Thanks,

Paul

[SQLGuy]

Thanks. I'm working with Deephaven, which is a column-oriented DB that handles very large datasets. Preserving native driver performance is important for the final solution here. An ODBC wrapper for ADBC drivers would be handy for an interim solution and prototyping, but I am not aware of one that currently exists. I saw a link icon in your response, but it does not seem to go anywhere.

I had already looked through the examples in GitHub. I do not see any C# code there. I was hoping to see one of the Microsoft ADBC connectors, like the Snowflake one. Note that the  libadbc_driver_flightsql.dll is part of the current PowerBI distribution, though no connectors seem to yet use it.

Cheers,

Paul

[v-hjannapu]

Hi @SQLGuy,
Thanks for followup

Yes, you are right  the libadbc_driver_flightsql.dll file is present in Power BI Desktop, but currently there’s no official guide or example from Microsoft on how to use it in custom connectors. Since Power BI’s M language runs in a sandbox, it can’t directly use native DLLs like this. Microsoft’s own connectors like Snowflake are built using C#, and they can work with these DLLs, but those methods and code are not shared publicly on GitHub.

For Deephaven, where performance really matters, using an ADBC-to-ODBC bridge would be a good temporary idea  but as you said, right now, there’s no such bridge available. So if you want to get native performance, the  it's technically possible but not officially supported where your code loads the DLL using P/Invoke and connects it with M code. But yes, this is a bit complicated and not officially supported at this time.

The broken link you saw earlier was probably just a placeholder.

We also hope Microsoft brings proper support for ADBC in the future. If anything official comes, we will surely update it here.

Hope this helps if you have any queries we are  happy to assist you further.
Thank you.

[v-hjannapu]

Hi @SQLGuy,
I hope the information provided above assists you in resolving the issue. If you have any additional questions or concerns, please do not hesitate to contact us. We are here to support you and will be happy to help with any further assistance you may need.

Regards,
Harshitha.

[v-hjannapu]

Hi @SQLGuy,
I hope the above details help you fix the issue. If you still have any questions or need more help, feel free to reach out. We are always here to support you.


Regards,
Harshitha.

[v-hjannapu]

Hi @SQLGuy,

I wanted to follow up and see if you have had a chance to review the information that was shared. If you have any additional questions or need further clarification, please don’t hesitate to reach out. I am here to assist with any concerns you might have.

Regards,
Harshitha.

[SQLGuy2]

I have reviewed it, but I still do not see any ODBC/ADBC bridge actually existing. I have submitted an inquiry to the MS Fabric team to see what else I can find about the Connector creation process for new drivers.

[v-hjannapu]

Hi @SQLGuy2,

Thank you for the update, and great that you have contacted the MS Fabric team directly. Since there isn't much documentation on using native ADBC drivers like libadbc_driver_flightsql.dll in custom connectors, reaching out to them is good move.

As you mentioned, there doesn’t appear to be an ADBC-to-ODBC bridge available yet, and Microsoft hasn’t provided much public information about native connector development. Hopefully, with more interest from users, they will consider offering official guidance or more details soon.

If you receive any updates from the Fabric team, please share them here, as it could be helpful for others exploring similar connector setups.

Best Regards,
Harshitha.

[v-hjannapu]

Hi @SQLGuy2,
I hope the information provided above assists you in resolving the issue. If you have any additional questions or concerns, please do not hesitate to contact us. We are here to support you and will be happy to help with any further assistance you may need.

Regards,
Harshitha.

[DataNinja777]

Hi @SQLGuy ,

You've run into an advanced and sparsely documented part of Power BI development. There is no simple, official way for a standard M-based custom connector to directly use the libadbc_driver_flightsql.dll you've found. The M language is sandboxed and can't just call native DLLs. The dll exists because Microsoft's own internal connectors can be built with C# and have the ability to call native libraries for better performance, a feature not fully exposed in the public SDK.

One potential but highly complex path is to create a native connector. This involves building a C# assembly that Power BI's Mashup Engine can load. This C# code would then use Platform Invocation Services (P/Invoke) to load libadbc_driver_flightsql.dll and call its functions. The C# code then exposes its own functions that your M script can call, effectively creating a wrapper. Since this is undocumented, your best bet for learning is to explore the Microsoft DataConnectors GitHub repository. By analyzing the C# source code (.cs files) of official connectors like the Odbc one, you can see how they use [DllImport] attributes to bridge the gap between .NET and native code.

A much more practical and recommended approach is to use an ADBC-to-ODBC bridge 🔗. This is an ODBC driver that translates standard ODBC calls into ADBC calls behind the scenes. For your Power BI connector, this means you can ignore the ADBC driver completely and simply build your connector around the standard, well-documented Odbc.DataSource function. Your M code would look something like this, treating the ADBC source as just another ODBC connection:

[DataSource.Kind="MyFlightSQLConnector", Publish="MyFlightSQLConnector.Publish"]
shared MyFlightSQLConnector.Contents = (dsn as text) =>
    let
        Source = Odbc.DataSource("dsn=" & dsn, [HierarchicalNavigation=true])
    in
        Source;

While the native connector path offers the highest potential performance, it is incredibly complex and relies on unsupported, undocumented features. In contrast, using an ODBC bridge is vastly simpler, more stable, and uses standard Power BI functionality. I strongly recommend pursuing the ODBC bridge path. The development effort is significantly lower, and the result is far more maintainable.

Best regards,