Glue Is the Metastore. It Shouldn't Have to Be the Meaning.

Few pieces of infrastructure are load-bearing for as many systems as the AWS Glue Data Catalog. It began as a managed, Hive-compatible metastore and became the connective tissue of the AWS analytics stack: crawlers and Glue ETL jobs populate it, Athena resolves every query through it, EMR and Redshift Spectrum read it, Lake Formation layers permissions over it. If your data lives in S3 and you query it with SQL, the catalog is almost certainly in the path.

That centrality is exactly why it is worth being precise about what the catalog is — and what it should never be asked to become.

What the catalog is for

The Glue Data Catalog answers physical questions superbly: where a table's files live, how they are formatted, which columns exist with which Hive types, how the data is partitioned. It is the lake's address book, and the AWS stack is built on the assumption that this address book is current — which crawlers keep true by re-inferring schemas from the files themselves.

What it does not carry is semantics. There is no place in a Glue table for a primary key, for nullability, for an allowed-value list, for the sentence that explains what a column means to the business. This is not a gap AWS forgot to fill; a metastore that mutates automatically as files change would be a dangerous place to store contractual meaning anyway. The catalog is a fast-moving mirror of physical reality. Meaning needs somewhere slower, deliberate, and reviewed.

The wrong fix: crowning one vendor's catalog

The industry's reflex has been to promote some vendor's catalog into the governance seat. Every major platform now offers one, and each works best when you commit your estate to that platform. But almost no real estate is single-platform. A typical stack runs Glue beside Snowflake or Databricks, with dbt transforming in the middle and a schema registry guarding the streams. Choose any one vendor's catalog as the seat of meaning and every other system becomes a second-class citizen — and your semantics acquire the same lock-in as your storage.

There is a subtler cost, too. A platform's own catalog describes your data in that platform's vocabulary, which makes even asking cross-platform questions awkward: is the orders table in the lake the same thing as ORDERS in the warehouse? Whose column types win? A governance layer that belongs to one of the contestants cannot referee that match.

Where CoreModels sits

CoreModels takes the other position: the meaning layer should be a neutral third party, beside every platform and inside none. The Glue integration is one of thirteen vendor connectors — dbt, Snowflake, Databricks, BigQuery, Microsoft Fabric, Confluent Schema Registry, and others — and every one of them speaks the same small vocabulary: import an estate into the governed model, audit the estate against it, and, for Glue as for most of its peers, generate vendor artifacts back out of it. Adding a vendor never changes the model's shape, because every connector maps into one neutral representation: datasets with fields, checks, and lineage, whatever the source calls them.

Neutrality here is concrete, not rhetorical, and it shows up in three design choices.

Native truth is preserved, not translated away. When a Glue table is imported, its Hive types travel verbatim — bigint, decimal(38,9), struct<...> — alongside the neutral primitives the governed model reasons over. Its S3 location, classification, and partition-key flags ride as vendor metadata. Nothing AWS-specific is flattened out of existence, so the governed model can always answer both "what does this mean?" and "what exactly does Glue say?"

Cross-estate identity is explicit. Two platforms constantly describe the same physical relation under different names, and a single-vendor catalog cannot even pose the question. CoreModels makes it a first-class, idempotent operation: reconciliation pairs the datasets that two governed estates record under the same physical relation and links each pair with reciprocal sameAs assertions, at dataset and at field level, so both nodes become queryable as one identity from either vocabulary. Whether a given pair matches is computed from the physical names your estates actually record — it is evidence, not an assertion we make on your behalf.

Meaning exits in open formats. A governed model built from a Glue import is not trapped in CoreModels any more than it was trapped in Glue. The same project exports to open, implementable specifications — JSON Schema, Avro, LinkML, JSON-LD, ShEx, OWL among them — because we implement published standards rather than minting a proprietary interchange format. The test of a neutral layer is how easily you could leave it; we build for that test on purpose.

Composition, not competition

Notice what this arrangement does not ask of you. Athena keeps resolving queries through the Glue catalog. Crawlers keep crawling. Lake Formation keeps enforcing access. CoreModels holds no AWS credentials and sits in none of those hot paths — it consumes a JSON export you produce yourself and gives back audits, history, badges, and reviewed DDL. The catalog remains the authority on physical reality; the governed model becomes the authority on intended meaning; and the audit is the hinge between them, measuring their distance in both directions.

That division of labor is the whole argument. Every system in your stack is better at its own job than a general-purpose meaning layer would be, and the meaning layer is only trustworthy if it has no side to take. Glue should absolutely be your metastore. It should not have to be your semantics — and nothing else in your stack should be either.

For the concrete mechanics on the AWS side — what to export and which calls to make — see the AWS Glue quickstart in the CoreModels docs.