BigQuery schema diagram: per-dataset INFORMATION_SCHEMA, authorized views as edges

The quirk to learn first: myproject.analytics.INFORMATION_SCHEMA.TABLES lists tables in the analytics dataset and nothing else. There is no unqualified project-wide TABLES view. The escape hatch is the region qualifier: querying INFORMATION_SCHEMA through a region prefix such as region-eu covers every dataset in that region at once, at the price that the region must be named and a single query can never span two regions. A project with US and EU datasets needs one inventory query per region, and the results stitched together.

-- One dataset at a time: the default scope
SELECT table_name, table_type
FROM `myproject.analytics`.INFORMATION_SCHEMA.TABLES;

-- Every dataset in a region, one query (note the qualifier)
SELECT schema_name
FROM `myproject`.`region-eu`.INFORMATION_SCHEMA.SCHEMATA;

For a script that walks the project, the bq CLI is often simpler than SQL: list datasets, then loop, with JSON output that feeds a generator or an agent without parsing acrobatics. The same CLI is also the practical way to enumerate scheduled queries, which live in the Data Transfer Service rather than in any dataset, and so never appear in INFORMATION_SCHEMA.TABLES no matter how you qualify it.

# Datasets, then tables, as JSON
bq ls --project_id=myproject --format=json
bq ls --format=json myproject:analytics

# Scheduled queries live in the Data Transfer Service
bq ls --transfer_config --transfer_location=eu --project_id=myproject

An authorized view is BigQuery's way of letting readers of one dataset query results computed from another they cannot touch. That grant is an architectural fact: a deliberate, access-controlled edge across a dataset boundary, and exactly the kind of edge a diagram should promote. The grants live in the dataset's access configuration, which bq show --format=prettyjson exposes as access entries referencing views.

Scheduled queries are the other invisible layer. Each one is a recurring job with source SQL and a destination table: in diagram terms, a pipeline node with an input edge you recover by reading its query text and an output edge to its destination. A BigQuery project drawn without its scheduled queries shows shelves of tables and none of the machinery that fills them.

Datasets map cleanly to zones, and most projects already layer them: raw, staging, marts, plus a sharing dataset where the authorized views live. For the first diagram, the BigQuery diagram generator turns a described or scripted inventory into an editable canvas; the wider platform picture around it has its own guide in GCP data platform diagrams.

For every diagram after the first: an agent connected to Datadef's MCP server, registry name io.datadef/mcp, reruns the inventory queries and updates the diagram in place. BigQuery's own scheduler cannot invoke it, and Datadef does not poll your project; the regeneration runs where your automation lives, a CI cron, a Cloud Scheduler target, or the tail of the pipeline that changed the datasets. One command, with an API key from settings, on paid plans.

Edges between plain views and their source tables are not handed to you as rows: INFORMATION_SCHEMA.VIEWS returns the SQL text of each view, and extracting referenced tables means parsing it, which an agent does tolerably and a regex does not. When the transformations are managed by dbt or Dataform, their manifests are a cleaner edge source than parsed SQL, and the agent should prefer them.

The live-embed caveat applies here as everywhere: an embedded diagram URL exists only for projects shared public, and a private project's embed 404s. For a confidential warehouse layout, export a static image and accept the staleness trade.

• BigQuery diagram generator
• GCP data platform diagrams
• Keep a data dictionary in sync with the schema
• The Datadef MCP diagram server