Purview is in a different location to all other data platform components such as ADLS , ADF and databricks

Ranjith Edwards-Data Engineer 20 Reputation points
2025-11-10T17:02:09.8166667+00:00

Purview is in a different location to all other data platform components such as ADLS , ADF and databricks. Is that something to proceed with ? or can there be many issues due to it ?

Azure Data Catalog
Azure Data Catalog
An Azure service that serves as a system of registration and system of discovery for enterprise data assets.
0 comments No comments
{count} votes

Answer accepted by question author
  1. Marcin Policht 68,300 Reputation points MVP Volunteer Moderator
    2025-11-10T19:41:12.3033333+00:00

    Purview does not require co-location to function; it will still be able to scan, classify, and catalog assets across regions. The product was designed with cross-region discovery in mind. However, there is potential for operational impact, including performance, latency, data movement rules, and compliance constraints.

    When Purview scans your storage or processing systems, it reads metadata rather than full data content. This means the performance impact is usually modest, but latency can increase the end-to-end scanning time if the region difference is large. For interactive browsing and lineage rendering, users may also notice slower response times, particularly when looking at large or deeply linked lineage graphs. If your platform processes high volumes of metadata change, lineage refresh latency could be more pronounced.

    From a governance and security standpoint, you must confirm that cross-region metadata movement aligns with your regulatory posture. Purview stores metadata, classification results, and lineage details in its own managed storage. If your regulatory environment expects metadata to remain within a specific geography or legal boundary, deploying Purview outside of that region could create a compliance gap. In many regulated sectors (finance, public sector, healthcare) the Purview instance is deliberately deployed in the same region as the primary data estate to avoid this.

    There is no functional blocker to operating Purview remotely, and many organizations do run a central Purview instance governing multiple regions. The key difference is whether you are centralizing governance or simply deploying Purview in an arbitrary region out of convenience. If the intent is a multi-region enterprise catalog, a single Purview instance in one region is standard. If not, and the data platform is region-specific for compliance or performance reasons, then Purview should generally be co-located with the rest of the stack.


    If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

    hth

    Marcin


0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.