Most organisations do not run one data platform, they run several. A finance team on an Oracle enterprise application, a product team on MySQL, and a BI team pushing everything toward a Microsoft Fabric lakehouse for reporting. The usual response to data quality across platforms like this is to buy or build a separate checking tool for each platform, which means three sets of rules, three owners lists, and three places an auditor has to look to understand what is actually being monitored. A data quality framework built around one check registry avoids that entirely, and this article explains how the same registry and runner model that governs a single SQL Server database extends across Oracle, MySQL, and every layer of a Fabric medallion architecture.

This is written for data engineering leads and BI teams who already have a working data quality setup on one platform and are being asked to extend the same governance to Oracle, MySQL, or a new Fabric lakehouse, without starting from zero on each one.

Why Managing Data Quality Across Platforms Separately Breaks Governance

Platform-specific data quality tools create a governance problem before they create a technical one. If the Oracle checks live in one tool, the MySQL checks live in a set of cron scripts, and the Fabric checks live inside Fabric's own pipeline notifications, there is no single place to answer a simple question, what are we checking across the business, and who owns each rule. Every audit becomes an exercise in tracking down three different answers instead of one.

A registry-based framework separates two concerns that platform-specific tools usually bundle together, what a check is, and where it runs. The definition of a check, its category, severity, threshold, and owner, does not need to know or care whether the underlying SQL executes against Oracle, MySQL, or a Fabric lakehouse table. Only the runner executing that check needs to know which connection to use.

One Registry for Data Quality Across All Your Sources

In practice this means the check registry gains one additional attribute beyond what a single-platform setup needs, a source identifier that tells the runner which connection to use for that particular check. Everything else, the category taxonomy of Completeness, Validity, Referential Integrity, Uniqueness, and Timeliness, the severity levels of Critical, High, Medium, and Low, the required output columns identifying a failing record, the field in error, and a human-readable description, stays identical regardless of source. A completeness check against an Oracle supplier table and a completeness check against a Fabric silver layer table are structurally the same kind of object, they just point at different connections.

Extending the Registry to Oracle Enterprise Applications

For an Oracle enterprise application, checks typically run against a replicated or extracted copy of the relevant tables rather than the live transactional schema, to avoid adding query load to a system that finance and operations depend on in real time. Common high-value checks at this layer include validating that a supplier tax jurisdiction code exists in a reference list, that a unit of measure on a purchase order matches what the item master expects, and that a warehouse location code referenced on a transaction actually exists in the location hierarchy. Each of these is registered exactly like a SQL Server check, with the same required output aliases and the same severity and threshold fields, the only difference is which connection the runner uses to execute the check SQL.

Extending the Registry Into a Microsoft Fabric Medallion Architecture

A Fabric medallion architecture needs checks at more than one layer, because a bad record that enters at bronze and is not caught there can propagate into silver and gold before anyone notices. At the bronze layer, checks focus on raw ingestion quality, missing required fields, malformed dates, or duplicate source keys. At the silver layer, checks shift toward referential integrity, confirming that foreign keys used in joins actually resolve, and that data types conform to what downstream transformations expect. At the gold layer, checks validate the business-facing aggregates themselves, confirming that a revenue total, a customer count, or a KPI falls within an expected range given the volume of source data that fed it.

Registering these as three separate check families inside the same registry, tagged by layer, means a single dashboard can show whether an issue originated at ingestion or emerged only after a transformation, which is exactly the kind of detail that is otherwise lost once bad data reaches a semantic model.

Bringing MySQL Into the Same Framework

MySQL environments, often supporting a product or application team rather than finance, tend to need simpler but higher-frequency checks, orphaned foreign keys after a deletion, duplicate records from a retry in an application flow, or a status field that has drifted outside its expected set of values. Registering MySQL checks in the same central registry means a product engineering team and a BI team are working from the same governed source of truth, rather than the product team running ad hoc scripts that nobody outside their team ever sees.

How data quality across platforms stays consistent

What Changes When You Scale Data Quality Across Platforms

What changes across platforms is entirely mechanical, the connection string the runner uses, and occasionally the SQL dialect a check is written in. What stays identical is everything that matters for governance, ownership, severity, audit history, and how a failure gets surfaced to the person responsible for it. That consistency is what lets a single Power BI dashboard show data quality across the entire environment, filterable by source, category, or severity, rather than requiring a different dashboard for every platform in use.

Getting Started

Organisations already running a registry-based framework on one platform do not need to rebuild anything to extend it, they need to add a source identifier to the registry, point the runner at the additional connection, and register the first handful of checks that matter most on that new platform. From there, coverage grows the same way it did on the original platform, one check at a time, without ever needing a second tool or a second audit trail.

If your data quality checks are currently split across separate tools for Oracle, MySQL, and Microsoft Fabric, speak with a Numlytics data quality consultant. We help teams extend a single governed check registry across every platform in their environment, so one dashboard and one audit trail cover the whole picture.