Database links
Survived, partially.
✓ certified by the mortician
In life
A database link is a one-way pointer from one database to another that lets SQL reference remote objects with the @link suffix. Links are private, public or global; they authenticate as a fixed user, the connected user or the current user; and through Heterogeneous Services and gateways they can reach non-Oracle systems. Statements spanning several databases become distributed transactions coordinated by two-phase commit, subject to restrictions on DDL, privilege grants and referential integrity across links.
Migrations care because links weave separate databases into one application, and Azure targets offer weaker equivalents: linked servers on SQL Managed Instance, external tables for cross-database queries on Azure SQL Database, and foreign data wrappers on PostgreSQL. Cross-database DML with atomic commit is generally unavailable, so each link must be classified as read-only lookup, data movement or transactional coupling before a design is chosen.
Links are supported and not deprecated. The 26ai Upgrade Guide desupports one variant, current-user links that rely on Enterprise User Security, recommending fixed-user or connected-user links instead.
Cause of departure
Not deprecated by Oracle. Listed here because Azure offers no clean equivalent.
Obituary
Database links, born before Oracle 11.2, connected databases so remote objects could be reached across systems. They served integration faithfully, making distance seem like a minor administrative detail.
Their Azure passage was blocked because Azure SQL Database supports neither linked servers nor cross-database three-part names or transactions. Elastic query offers only a preview, read-only approximation, while Managed Instance cannot link to Oracle or other non-SQL databases.
It is survived by Azure Database for PostgreSQL Flexible Server, where it lives on partly; Azure SQL Database, only by workaround; and Azure SQL Managed Instance, partly. The family notes that coexistence remains possible through oracle_fdw on supported PostgreSQL versions.
Survived by
Azure Database for PostgreSQL Flexible Server partial effort M
Foreign data wrappers replace database links: postgres_fdw and dblink connect to other PostgreSQL servers or databases, and oracle_fdw (available on Flexible Server for PostgreSQL 12 and later) connects to Oracle with WHERE pushdown and IMPORT FOREIGN SCHEMA, which is useful during coexistence. Both servers must allow the network path (Microsoft recommends VNet integration), and there is no two-phase commit across foreign servers.
- Allowlist postgres_fdw or oracle_fdw and create the foreign server and user mappings.
- Use IMPORT FOREIGN SCHEMA to expose remote tables, then repoint schema.table@link references.
- Deploy servers with VNet integration or network rules permitting the connection.
- Keep cross-server writes idempotent, since distributed transactions are not atomic.
Complications
Azure SQL Managed Instance partial effort M
Managed Instance supports linked servers and cross-database queries within the instance, so links between Oracle schemas that land in the same instance become plain three-part names, and links to other SQL Server, Managed Instance, Azure SQL Database or Synapse endpoints become linked servers with SQL or Entra authentication. Linked servers to Oracle or other non-SQL databases are not supported, and distributed transactions over linked servers are limited to the DTC preview scenarios.
- Co-locate linked schemas in one instance and replace link syntax with database.schema.object names.
- Create linked servers for remaining SQL-family targets; test with OPENQUERY for pushdown.
- Route remaining Oracle-side dependencies through Data Factory or the application.
- Avoid distributed transactions across linked servers unless the DTC preview is acceptable.
Complications
Azure SQL Database workaround effort L
Azure SQL Database supports neither linked servers nor cross-database three-part-name queries. Elastic query (still in preview) exposes remote Azure SQL tables as read-only external tables and can execute remote procedures with sp_execute_remote, which covers reporting-style database links but not DML through the link or links to non-SQL targets. Many teams instead consolidate schemas into one database or move to Managed Instance.
- Inventory DBA_DB_LINKS and classify link usage (read-only lookup, DML, distributed transaction, non-Oracle target).
- Consolidate tightly coupled schemas into one database where possible.
- For read-only access across Azure SQL databases, create external data sources and external tables (elastic query).
- Replace DML over links with application-level orchestration or Data Factory.
Complications
Notices of correction
- oracle Distributed Database Concepts (Administrator's Guide 19c) · Database Administrator's Guide 19c · read 2026-09-26
- oracle Oracle Database Changes, Desupports, and Deprecations (Upgrade Guide 26ai) · Upgrade Guide 26ai, G43570-12, updated Jul 2026 · read 2026-09-26
- microsoft Considerations when using extensions in Azure Database for PostgreSQL flexible server · page updated 2026-08-12 · read 2026-09-26
- microsoft Extensions and modules by name in Azure Database for PostgreSQL flexible server · page updated 2026-07-13 · read 2026-09-26
- community oracle_fdw README (Oracle foreign data wrapper for PostgreSQL) · oracle_fdw 2.x (Azure PG Flex ships 1.2 extension version for PostgreSQL 12-18) · read 2026-09-26
- microsoft T-SQL differences between SQL Server and Azure SQL Managed Instance · page updated 2026-09-09 · read 2026-09-26
- microsoft Compare SQL Database Engine features: Azure SQL Database vs Azure SQL Managed Instance · page updated 2026-09-09 · read 2026-09-26
- microsoft Elastic query overview (Azure SQL Database) · page updated 2026-09-01 · read 2026-09-26