Thirteen Connectors, One Model: Where BigQuery Fits

Ask a CoreModels deployment which vendors it knows and it will tell you at runtime. The vendors endpoint returns every registered connector with its key, display name, capabilities and the artifacts it expects: bigquery, snowflake, databricks, fabric, glue, dbt, confluent, airbyte, airflow, neo4j, salesforce, redcap, cbioportal.

Google BigQuery is one row in that table. Not the center, not a special case — one row, with the same verbs, the same report shape and the same finding vocabulary as the other twelve. That fact does more work than it appears to, and it is the whole subject of this piece.

BigQuery's own neighbourhood

Inside Google Cloud, BigQuery sits under a familiar stack: datasets provisioned by infrastructure-as-code, transformations managed in a modeling tool, dashboards and notebooks downstream, and everything ultimately describing itself through one surface — INFORMATION_SCHEMA.

That surface is the natural place to meet BigQuery. It is complete enough to matter, standard enough to query from the console or the bq CLI, and safe enough to export without handing anyone credentials. So the BigQuery connector asks for exactly one artifact, information_schema: the JSON result of a documented query that joins COLUMNS and TABLES and stitches in column descriptions from COLUMN_FIELD_PATHS and table descriptions from TABLE_OPTIONS.

That is not a BigQuery-specific invention. It is the same catalog-view playbook our Snowflake, Databricks Unity Catalog and Microsoft Fabric connectors follow, because ANSI-style information schemas are the closest thing the warehouse world has to a shared language. Learn the extraction pattern once and you can govern four warehouse families with it — each connector differing only in the query, the native type map, and the best-practice rules that make sense for that platform.

The neutral model underneath

Here is the architectural point. The BigQuery connector does not import BigQuery tables into a BigQuery-shaped model. It parses them into a vendor-neutral estate model — datasets with fields, checks and descriptions — which is the same shape a dbt manifest, a Kafka schema-registry subject, a Salesforce describe or a Neo4j meta-schema produces.

Vendor detail is not discarded in the process; it is carried, not centered. The exact native type string, the materialization (table, view, materialized view, external table), the physical project.dataset.table name all ride along on a per-vendor metadata mixin — for this connector, the one labeled Google BigQuery Metadata. The vendor identity itself is recorded as a mapping from the governed node to project.dataset.table, so the estate's own vocabulary is always one hop away. But the meaning — what a customer is, which values a status may take, what refers to what — lives in a model that belongs to no vendor.

Composition, concretely

Neutrality is not an aesthetic preference. It is what makes three specific things possible.

Two estates, one entity. A dbt model and the BigQuery table it materializes are the same physical relation described twice. A reconciliation pass finds those pairs by normalized physical name and links them with reciprocal same-as assertions on both nodes, then does the same for label-identical columns. The writes are idempotent — run it again and it refreshes rather than duplicates — and the links count toward the audit's canonical-mapping coverage metric, so "how much of our estate is cross-referenced" becomes a number instead of a hunch. Neither vendor's identity index is polluted, because the equivalence assertion is deliberately not a vendor key.

One governance loop, many tools. Import, audit, drift history, badges, the CI gate and the MCP tools an agent calls are shared machinery that treats every vendor identically. A connector's job is narrow: parse artifacts, map native types, contribute audit rules, generate artifacts back. BigQuery gets the full loop not because it received bespoke treatment, but because the loop is vendor-neutral by construction — and the same holds for whichever connector is added next.

One meaning, many formats. The governed project that audits your BigQuery estate can be exported into the open formats CoreModels implements — JSON Schema, Avro, LinkML, ShEx, JSON-LD, OWL, Protobuf, SQL DDL, Bitol's Open Data Contract Standard, and Apache Ossie (formerly OSI) semantic models. The definitions your stewards agreed once travel to validation pipelines, event platforms and scientific tooling without being re-authored, and each conversion declares what it could not carry rather than silently dropping it.

Why neutrality earns its keep

Because estates outlive platform decisions. Warehouse choices change through mergers, cost reviews and cloud strategy. If your semantic layer is expressed in one vendor's terms, every platform change is also a governance rewrite. A neutral model makes meaning the constant and the warehouse the variable — which is why our model treats a governed node as something that can outlive the estate object it was imported from.

Because a single-vendor "standard" is quiet lock-in. Catalogs that speak only one platform's dialect gradually bend your definitions toward that platform's type system. CoreModels maps into neutral primitives and declares every approximation instead: NUMERIC becomes a double with the approximation on record, STRUCT and JSON become honest string approximations, and BigQuery's absence of enforced keys is respected rather than papered over.

Because honest refusals keep the map trustworthy. Two of the thirteen connectors — Airbyte and Airflow — have no Generate capability at all. Orchestration code and source catalogs are not derivable from a governed schema, so those connectors decline instead of emitting something plausible and wrong. A landscape map you can trust is one that marks its own edges.

What this asks of BigQuery: nothing

BigQuery stays the query engine. Your transformation tool stays the transformer. Your scheduler stays the scheduler. CoreModels takes the one job every island delegates and none performs — holding the shared map, keeping it honest, and checking each island against it — and it hands the result back in each platform's own idiom: for BigQuery, a DDL script whose descriptions carry the governed meaning, because descriptions are where BigQuery users actually read.

Govern the meaning once, neutrally, and let every tool including BigQuery be what it is best at.

For the BigQuery-specific walkthrough, see the CoreModels Google BigQuery quickstart.