Is it possible to set up SQL Server cross database queries from Azure SQL dbaas to Azure SQL Managed Instance

Question

Is it possible to set up SQL Server cross database queries from Azure SQL dbaas to Azure SQL Managed Instance

Cooling, Steve 45

I have successfully created cross database queries between databases on the same Azure dbaas instance but is it possible to create cross database queries from a database hosted in our Azure SQL dbaas instance to a database in our Azure SQL Managed Instance?

Swapnesh Panchal 1,460 Reputation points Microsoft External Staff Moderator

2025-11-18T15:49:32.75+00:00

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Answer accepted by question author

3 additional answers

Your answer

Swapnesh Panchal 1,460 Reputation points Microsoft External Staff Moderator

2025-11-18T15:49:32.75+00:00

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Answer 1

can kucukgultekin 330

Hi @Cooling, Steve , you cant do it the same way you do cross-db queries on full SQL server or MI (no simple OtherDb.dbo.Table 3/4-part name from Azure SQL Database), but yeah you can query data in Azure SQL Managed Instance from SQL Database using external tables/elastic query.

Azure SQL Database doesnt support classic cross-database or cross-instance queries with 3- or 4-part names. For this kind of scenario Microsofts guidance is using data virtualization with external data sources and external tables, basically elastic query. For your specific direction where source is database on Azure SQL Managed Instance and destination is database on Azure SQL Database (where the query runs), you set it up on the Azure SQL DB side like this: first you create a database scoped credential that can log into the Managed Instance (SQL auth user with permissions on source DB), then you create an external data source that points to MI fqdn, port, and source database using that credential. Finally you create an external table whose schema matches the table on the managed instance. Once thats done you can just select from that external table from within azure sql db and even join it with your local tables, basically giving you cross-database behavior between azure sql db and MI, just not via the old 3-part name syntax. Important thing tho: this isnt a full distributed transaction, theres no 2PC between sql db and MI, and youre going over the network so treat it as data-virtualization / read scenario and be careful with huge scans or heavy joins across the boundary.

For the opposite direction where query runs on Managed Instance and reads from Azure SQL Database, current recommendation is using linked servers on the MI side rather than this external table pattern, but in your case where Azure SQL DB is querying MI the external table approach is the supported way.

So the answer is; no native cross-database query from Azure SQL Database to MI with three-part names, but yes you can achieve what you want by defining an external data source and external tables in Azure SQL Database that point to your Managed Instance.

Cooling, Steve 45 Reputation points

2025-11-18T08:04:39.14+00:00

Hi @can kucukgultekin thanks for your response, it's much appreciated. I've tried as you've suggested but when I select the top 1000 rows of the external table I'm getting the error message below reported -

Msg 46832, Level 16, State 3, Line 1

An error occurred while establishing connection to remote data source: [Microsoft][ODBC Driver 17 for SQL Server]TCP Provider: The wait operation timed out.

[Microsoft][ODBC Driver 17 for SQL Server]Login timeout expired[Microsoft][ODBC Driver 17 for SQL Server]A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections.

I've tried creating the external data source using the FQDN of the MI and also the ip address of the MI but I get the same error reported with both. Below is the command I've used to create the external data source. Can you see anything I've done wrong or do I need to add any parameters etc?

CREATE EXTERNAL DATA SOURCE CrossDBQueryDBNAME WITH

(TYPE = RDBMS,

LOCATION = '######l.######.database.windows.net,1433',

DATABASE_NAME = 'DBNAME',

CREDENTIAL = CrossDBQuery,

);
can kucukgultekin 330 Reputation points

2025-11-19T18:47:17.46+00:00
Hey @Cooling, Steve sorry for the late reply.

That error message isn't a T-SQL syntax problem, it's clearly a connectivity issue:

TCP Provider: The wait operation timed out... Server is not found or not accessible.

So Azure sql db cant reach the MI at all the external table query never even gets to the login stage.

In your script you have:

LOCATION = '######l.######.database.windows.net,1433'

but when connecting from Azure SQL Database to a Managed Instance you need to use the MI's public endpoint with port 3342. Not the standard 1433 port. It should look like:

tcp:mi-name.public.<dns-zone>.database.windows.net,3342

A couple of things to check:

The MI public endpoint must be enabled (Portal → your MI → Networking → Public endpoint = Enable).

Make sure you're using a *.public.*.database.windows.net,3342 FQDN in LOCATION, not the usual SQL DB-style server name.

Using the MI IP won't help, because if that IP is private then Azure SQL DB can't reach your VNet directly - it has to go through a supported endpoint (public endpoint, or a properly configured private link scenario).

The CrossDBQuery credential must be a login that exists on the MI and can connect to that database; once connectivity works, a bad login will turn into a “login failed” error instead of a TCP timeout.

Right now, since you're getting a pure connection timeout / “server not found”, the first thing to fix is LOCATION: point it to the MI public endpoint with the public DNS name + port 3342, and confirm the public endpoint is actually enabled. Once the network path is correct, if there's a credential issue you'll start seeing a login error instead of the TCP timeout.

A full working setup usually looks like this:

-- 1. Create database scoped credential (valid SQL auth user on MI) CREATE DATABASE SCOPED CREDENTIAL CrossDBQuery WITH IDENTITY = 'mi_username', SECRET = 'mi_password'; -- 2. Create external data source (public endpoint + port 3342) CREATE EXTERNAL DATA SOURCE CrossDBQueryDBNAME WITH ( TYPE = RDBMS, LOCATION = 'tcp:your-mi-name.public.a1b2c3d4e5f6.database.windows.net,3342', DATABASE_NAME = 'DBNAME', CREDENTIAL = CrossDBQuery ); -- 3. Create external table CREATE EXTERNAL TABLE dbo.RemoteTable ( Id INT, Name NVARCHAR(100) ) WITH ( DATA_SOURCE = CrossDBQueryDBNAME, SCHEMA_NAME = 'dbo', OBJECT_NAME = 'YourTableName' ); -- 4. Query it SELECT * FROM dbo.RemoteTable;

The a1b2c3d4e5f6 part is just the DNS zone from your MI public endpoint - in your case you can reuse the same zone you already have in your current LOCATION value, just make sure you're using the *.public.* FQDN and port 3342.
Cooling, Steve 45 Reputation points

2025-11-21T08:03:31.0666667+00:00

Thanks very much for this info @can kucukgultekin , we're currently trying to work out the best way forward with this. We don't have the public endpoint enabled currently so we may look to the private link solution.
Cooling, Steve 45 Reputation points

2025-11-27T16:32:59.3866667+00:00

Hi @can kucukgultekin , we've decided to use the private link method due to it being more secure. I've managed to connect to the MI from SSMS on-prem by entering the name of the private link as the server name and entering Server=####.####.database.windows.net in the Additional Connection Parameters tab. The connection failed without entering the additional parameter. Do you know if anything would change with the creation of the external datasource command you've provided above, other than the port number to 1433 of course. I'm still getting the same error as previously reported from the dbaas instance when running a 'select' from the external table.
can kucukgultekin 330 Reputation points

2025-11-28T12:42:24.5766667+00:00
Hey @Cooling, Steve ,

choosing private link makes sense from a security perspective, but there’s an architectural/product limitation here unfortunately.

You being able to connect from on-prem SSMS to MI via private link is totally expected: your on-prem network is integrated with the Azure VNet (VPN/ExpressRoute), and the private endpoint name resolves inside that VNet to the MI’s private IP, so the client can actually reach it.

Azure SQL Database (DBaaS) is a different story. Azure SQL DB runs on Microsoft’s shared managed infrastructure and doesn’t sit in your VNet. Its outbound traffic doesn’t go through your VNet; it goes out over a public path that the platform controls. That means Azure SQL DB has no route to the subnet where your MI private endpoint lives.

So the situation looks like this:

on-prem client → VNet → private link → MI (True works)

Azure SQL DB → private link → MI (Wrong! no route / not supported)

Even if you change "LOCATION" in the external data source to the private endpoint FQDN on port 1433, Azure SQL Database still can’t actually reach that address, so you’ll see the same timeout. And this isn’t just “your setup”: right now elastic query from Azure sql database does not support connecting over private endpoints-it only works when public network access is enabled on the target.

In practice you’ve got a few options:

Enable the MI public endpoint and lock it down. I know “public” sounds scary, but here it doesn’t mean “wide open to the internet by default”. For elastic query you’d typically do something like:

CREATE EXTERNAL DATA SOURCE CrossDBQueryDBNAME WITH ( TYPE = RDBMS, LOCATION = 'tcp:your-mi-name.public.xxxxx.database.windows.net,3342', DATABASE_NAME = 'DBNAME', CREDENTIAL = CrossDBQuery );

Then on the network side, restrict access as much as you can (NSG/firewall rules, maybe limiting to known Azure ranges/regions or a private jump host), and rely on SQL auth / AAD auth on top. This is the only path that elastic query supports today.

Change the direction of the query. If enabling the MI public endpoint is absolutely off the table, you can flip things around and run the cross-database query on the MI side instead. MI sits in your VNet and can reach Azure SQL Database via supported connectivity (public endpoint, or private link if you configure that). From the MI side you can use a linked server / external table to Azure SQL DB, then query from MI and expose the results to the app from there. It’s the opposite direction of your original requirement, but it keeps everything on private connectivity if that’s a hard requirement.

Use data sync / ETL and query a local copy. Another option is to sync or copy the data you need from MI into Azure SQL DB (or the other way around) using Azure SQL Data Sync, replication where appropriate, or an Azure data factory or synapse pipeline. Then Azure SQL DB just queries its local copy and you don’t need an elastic query across the boundary. The trade-off is sync overhead and data freshness.

Regarding the SSMS behavior: having to put the private endpoint name as the server and then also specify "Server=..." again in Additional Connection Parameters is indeed a bit funky, and usually points at how DNS resolution for the private link is set up. But that tweak only applies to clients inside your own network – it doesn’t change the fact that Azure SQL DB itself can’t see that private endpoint at all.

So you can’t use elastic query from Azure SQL Database to reach MI over private link today, because Azure SQL DB’s outbound path doesn’t go through your VNet and elastic query doesn’t support private endpoints. The realistic choices are: enable MI’s public endpoint and restrict it as tightly as possible, flip the query direction and run it on MI, or move/sync the data and query a local copy.

Answer 2

Hi @Cooling, Steve ,
Welcome to the Microsoft Q&A and thank you for posting your questions here.

Not possible**:** You cannot use classic three‑ or four‑part names (OtherDb.dbo.Table) from Azure SQL Database to reach a Managed Instance. That syntax only works within the same logical server or on Managed Instance/full SQL Server.

Supported approach (Possible):

Use Elastic Query on the Azure SQL Database side:
Create a database‑scoped credential for a SQL login on the Managed Instance.
Define an external data source pointing to the MI endpoint and database.
Create external tables that map to the MI tables.
Query those external tables and join with local tables as needed.

Answer 3

Cross-database queries between Azure SQL Database and Azure SQL Managed Instance are not directly supported. While you can create cross-database queries within the same Azure SQL Database instance, querying across different types of instances (like Azure SQL Database to Azure SQL Managed Instance) typically requires a different approach, such as using linked servers or other data integration methods.

For scenarios involving Azure SQL Managed Instance, you might consider using the Managed Instance link feature, which allows you to offload workloads and replicate data between SQL Server and Azure SQL Managed Instance. However, this setup does not facilitate direct cross-database queries as you would have within a single instance.

If you need to access data from an Azure SQL Database in your Managed Instance, you would likely need to implement a solution that involves data replication or data movement strategies.

Answer 4

Cooling, Steve 45

Hi @can kucukgultekin , thanks very much for your detailed explanation above, it has been very helpful. It looks like we'll be moving forward by syncing the data with a local copy of the database on the dbaas instance. Thanks for all your help with this.

Share via

Is it possible to set up SQL Server cross database queries from Azure SQL dbaas to Azure SQL Managed Instance

3 additional answers

Your answer