Hi all — has anyone connected GoodData to Cosmos DB mirrored in Fabric? I’m aware of the Synapse SQL connector, but with Synapse Link deprecated for new Cosmos DB, I’m not sure what the current best approach is.

The knowledge sources don't contain specific information about connecting GoodData to Cosmos DB mirrored in Microsoft Fabric, so I can't give you a definitive answer on that exact setup. That said, here's what the knowledge sources do tell us that's relevant: Native Connectors GoodData supports Synapse SQL as a native connector, which you're already aware of. [Synapse SQL docs] Given the Synapse Link deprecation concern you've raised, this path may indeed be problematic for new Cosmos DB setups. FlexConnect as an Alternative The most likely viable path for your scenario would be FlexConnect, GoodData's custom data connector framework. It is designed to connect to virtually any data source — including APIs, NoSQL databases, and non-standard systems — without requiring a native connector. [FlexConnect docs] It works by allowing you to write custom Python code that returns data via the Apache Arrow Flight RPC protocol, acting as "just another data source" in GoodData. [FlexConnect blog] Recommended Next Steps 1. Contact GoodData support or your Account Manager — since this is a fairly specific integration scenario (Cosmos DB mirrored in Fabric), they would be best placed to advise on the current recommended approach or any roadmap items. 2. Explore FlexConnect as a self-service option in the meantime, particularly if you can query the Fabric-mirrored data via an API or JDBC-compatible endpoint. I'd recommend reaching out directly to GoodData for guidance tailored to your specific architecture. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups. 👀 Our Support team monitors all messages and will jump in if needed.

Hi Aleksander , our AI assistant already pointed you toward FlexConnect as a potential option, and that's likely the right direction. Let us add some more context. Before giving you a precise answer, could you confirm: are you using Microsoft Fabric's native Mirroring feature (the built-in Fabric item that replicates Cosmos DB data into OneLake), or a different setup? If it is Fabric Mirroring, here's what we found: the feature creates a T-SQL compatible SQL analytics endpoint on top of the replicated data. While this endpoint is reachable via JDBC, Microsoft's documentation states it only supports Microsoft Entra ID (Azure AD) authentication, SQL auth is not supported. GoodData's native Synapse SQL connector uses SQL auth, so a direct connection won't work at this point. In that case, FlexConnect would be the recommended path — as our Agent mentioned, it allows you to write custom Python code to connect to virtually any source, including Fabric endpoints that require Entra ID auth. You can find the docs here. Let us know your setup and we can help further!

We're using the built-in Fabric item

Hi Aleksander, thank you for this. Let us review this and we will come back with an update.

We were using Azure Synapse, but it has been deprecated for new Cosmos DB instances, and it's recommended by Azure to use mirroring in fabric instead.

Hi Aleksander, Thank you for digging into the connector properties and sharing what you have tried so far. It is the right direction. Here's where I landed after some testing on our side. 1) The MSSQL / Azure SQL connector does accept the

authentication

,

AADSecurePrincipalId

and

AADSecurePrincipalSecret

properties, and in my testing environment I was able to get a successful "Test connection" against an Azure SQL database using

authentication=ActiveDirectoryServicePrincipal

with a service principal. To be transparent: this is not an officially documented or guaranteed authentication method for the connector — it isn't exposed in the UI, so please treat it as best-effort rather than it being "supported" and something we can promise will behave the same in every setup. 2) Those properties are passed through to the underlying JDBC driver, but only when they are part of the connection URL — not when supplied as a separate

parameters

block. The

parameters

block is rejected for SQL data sources, which is almost certainly the

400 Bad Request

you saw. The

authentication=ActiveDirectoryServicePrincipal

needs to go into the

url

. What worked for me via the API:

type: AZURESQL
url: jdbc:sqlserver://<host>:1433;databaseName=<db>;encrypt=true;authentication=ActiveDirectoryServicePrincipal
username: <service-principal client ID>
password: <service-principal secret>

(Passing the service principal as username/password is Microsoft's current form; the

AADSecurePrincipal*

properties are the deprecated equivalents.) A couple of prerequisites that showed up and will likely apply to you too: • The service principal has to be granted access inside the target database/endpoint (at least read access) — it existing in Entra ID alone isn't enough. • The service principal must live in the same Entra tenant the endpoint authenticates against. Important caveats for your Fabric / Cosmos DB scenario: • My test was against a plain Azure SQL database — not a Fabric SQL analytics endpoint backed by Cosmos DB mirroring. A green "Test connection" only confirms authentication + reachability; it does not guarantee that all functionality, e.g. model scanning, data loading, and querying the mirrored Cosmos DB data will all behave the same way through that endpoint. I haven't validated that end-to-end. • On Fabric you'd typically grant the service principal access via the Fabric workspace / item permissions, rather than the

CREATE USER ... FROM EXTERNAL PROVIDER

route used for a standalone Azure SQL database. • If you hit limitations with the Fabric endpoint, FlexConnect remains the more flexible fallback — it lets you implement the connection (including Entra ID auth) in custom Python. If you try this against your Fabric endpoint, please let us how it goes —both whether the connection succeeds and whether data loading works against the mirrored data. In addition, I would gladly help you if you get to any other, unexpected issues.

Hi, thanks for that in-depth explanation. I was able to create datasource with your instructions, but it was unable to fetch data from DB with following error:

com.microsoft.sqlserver.jdbc.SQLServerException:
'FOR' clause is not supported in this version of Synapse SQL.

But changing that connector to

SYNAPSE SQL

solved that issue and I'm able to fetch tables from mirrored CosmosDB instance:

I am glad that my explanation and notes helped you to be able to fetch the tables and data after changing the connector / driver. However, as I already mentioned, please keep in mind that: • ... this is NOT an officially documented or guaranteed authentication method for the connector — it isn't exposed in the UI, so please treat it as best-effort rather than it being "supported" and something we can promise will behave the same in every setup. In addition, we do not guarantee that all functionality, e.g. model scanning, data loading, and querying the mirrored Cosmos DB data will all behave correctly everywhere. However, we are always ready to assist and do our best to help you achieve your goals. With that in mind, is there anything else regarding the matter I could help you with?

I fully understand this. At the moment I don't have additional questions. If anything, I'll create a new topic

Perfect, thank you very much for letting us know.