Possible to create a Failover group cross subscription for SQL Paas?

Question

Does anyone know if it's is/should be possible to setup a fail-over group for SQL PaaS databases/servers with the secondary server running in a different subscription (but same tenant)?
I've come across an article that describes this setup for a managed instance, but I haven't been able to find anything on SQL PaaS..

The method of setup doesn't matter that much to me, but before I dive in it would be nice to at least know if it's possible or not :)

Answer 1

Hi @Paul Vermij ,

Thanks for your patience.

This feature has been enabled last month and is documented here.
It's possible to deploy auto-failover group across subscriptions for single databases by using the -PartnerSubscriptionId parameter in Azure Powershell starting with Az.SQL 3.11.0.
To learn more, review the following Example.

Hope this will help. Please let us know if any further queries.

------------------------------

• Please don't forget to click on or upvote button whenever the information provided helps you.
  Original posters help the community find answers faster by identifying the correct answer. Here is how
• Want a reminder to come back and check responses? Here is how to subscribe to a notification

Answer 2

Just a followup question, is it to be expected that the portal will have some issues with a setup like this for the moment?
I noticed that although the portal shows the FG just fine, but adding DBs through the portal isn't possible as it keeps trying to connect to the secondary server through the subscription ID of the primary server.
That's easily solved by adding them through powershell, but after adding the DBs the portal isn't showing any info on the secondary DBs.
For instance, the 'overview' tab just keeps loading endlessly and when checking the replication status from the secondary DB the primary DB is marked as 'offline' , viewed from the primary it shows primary as online and the secondary as 'readable' but isn't able to show the pricing tier.

Al this isn't a very big deal as we should be able to check the sec. DB in other ways, but we (myself and our customer) would like to double check if this is expected behavior at least for the moment.