Your Warehouse Is a Junction, Not a Destination

Draw your data estate on a whiteboard and the warehouse always ends up in the middle of the picture. That placement is accurate about traffic and misleading about authority. A Fabric Warehouse is where things pass through: transformations land tables in it, ingestion tools feed it, semantic layers and reports and notebooks and agents read out of it, and downstream systems copy from it. Very little of what a warehouse table means actually originated in the warehouse.

Which raises the question this article is about. If meaning arrives from several directions and leaves in several more, where should the agreed version of it live — and who should own the place it lives?

The T-SQL family, joined by their oldest interface

Start with the immediate neighborhood. Microsoft Fabric's Warehouse and SQL analytics endpoints speak T-SQL, and so does every SQL Server estate your organization has accumulated. Our connector for this family (vendor key fabric) asks for exactly two things, both through documented queries you run yourself: the INFORMATION_SCHEMA view of columns joined to tables, and — optionally — the flattened primary- and foreign-key constraint rows.

That extract shape is ANSI rather than Fabric-specific, which is why the same connector governs a plain SQL Server estate without modification. One connector spans the newest and the oldest members of the family, not through compatibility engineering but by refusing to depend on anything newer than the interface they both already expose.

The refusal is deliberate in a second way worth naming. The connector takes no dependency on any vendor's proprietary semantic or catalog layer. Those layers are genuinely useful inside the platform that ships them — and a governance layer built on top of one inherits its boundaries, its lifecycle, and its commercial incentives. INFORMATION_SCHEMA has quietly outlived a long series of proprietary metadata APIs. It is stable, universal, and owned by nobody. For the foundation of a model you intend to keep for a decade, those are the properties that matter.

One estate model under thirteen connectors

The Fabric connector is not a point-to-point integration. It is one of thirteen connectors that all parse into the same neutral estate model: dbt, Snowflake, Databricks Unity Catalog, Google BigQuery, AWS Glue Data Catalog, Confluent Schema Registry, Salesforce, Neo4j, Airbyte, Apache Airflow, REDCap, and cBioPortal alongside Microsoft Fabric.

"Same model" is the load-bearing part. A Fabric table, a Snowflake table, and a dbt model all become the same kind of governed object — a Type with Elements, checks, references, and vendor metadata riding alongside — and every connector exposes the same verbs at the same roles: import, audit, re-audit, generate, status, history, badge. Learn the shape once and the fourteenth vendor is a new key in a URL, not a new mental model. Architecturally, adding a connector touches no shared routes, services, registry code, or agent tools, which is the structural reason no single vendor's peculiarities can bend the neutral model in their own direction.

Plurality is the normal case. Real organizations do not have "a warehouse"; they have a warehouse, a transformation layer, a streaming registry, and several inherited systems that predate the current architecture. When the same physical table is governed from two sides — the warehouse's own schema and the dbt project that builds it, for instance — CoreModels can reconcile the two estates, matching datasets by database.schema.table and linking them with reciprocal same-as assertions, idempotently. Two views of one table become one governed entity with two provenances, rather than two disconnected copies of the truth that slowly disagree.

That is what makes cross-estate questions answerable at all: which pipeline produces this table, whether the contract holds on both sides, what breaks downstream if a column changes. None of those questions stay inside a single vendor's boundary.

Standards on the way out, too

Neutrality that only works on the import side is a trap with better manners. Once a Fabric estate is governed, its meaning is not locked inside CoreModels any more than it was locked inside Fabric.

The governed model exports through coders we implement against published specifications: JSON Schema, JSON-LD, ShEx, Avro, LinkML, OWL, Protocol Buffers, the Bitol Open Data Contract Standard, Apache Ossie semantic models, and SQL DDL. The SQL exporter takes a dialect, so the same governed warehouse can come back out as sqlserver DDL for the estate it came from, or as Postgres or MySQL for somewhere else entirely. A schema that entered as INFORMATION_SCHEMA rows can leave as a validation contract, a semantic-web ontology, a scientific data model, or a streaming record schema — without being re-modeled by hand.

Every one of those conversions reports its lossiness honestly: what a target format could not express is declared rather than silently dropped. Format conversion without that ledger is just reformatting. Format conversion with it is interoperability you can audit.

And the Fabric connector closes its own native loop: generation emits T-SQL CREATE TABLE DDL — bracketed identifiers, nullability from governed checks, one primary key per table, foreign keys from governed references — for the platforms that speak the estate's own language.

Why neutrality is structural, not stylistic

There is an incentives argument underneath the architecture, and it is worth stating without euphemism. A schema governance layer occupies a position of trust: it holds the agreed meaning of your data. When that layer is owned by the same vendor that owns your storage, your compute, or your reporting tools, the layer eventually acquires a second job — keeping you where you are. Meaning that is expensive to move is a retention feature whether or not anyone designed it as one.

CoreModels sits deliberately outside every platform it connects to. It holds no credentials for your Fabric Warehouse or SQL Server. It never writes to them; generated DDL is an artifact you review and deploy yourself. It reads only the standard schema surface, and it exports to formats maintained by other people.

Your platform choices should be free to change. Your warehouse might be Fabric today and something else in five years, and that decision should be made on the merits of the platform — not on how much accumulated meaning is trapped inside it. The part your organization spent years building is not the tables. It is the agreement about what the tables mean. That part should travel.

If you want to see the whole surface — the extract queries, the shared verbs, and what the Fabric connector emits — the Microsoft Fabric quickstart in our docs is the place to start.