Snowflake can attach a tag to a database object: named metadata, with an optional set of allowed values, defined once and queried back like any other object. Bind a masking policy to that tag and the classification enforces itself:
-- A tag: named, with controlled values.
CREATE TAG data_sensitivity ALLOWED_VALUES 'high', 'medium', 'low';
-- Bind a masking policy to the tag (Enterprise edition).
CREATE MASKING POLICY mask_string AS (val string) RETURNS string ->
CASE WHEN CURRENT_ROLE() = 'PII_READER' THEN val ELSE '***' END;
ALTER TAG data_sensitivity SET MASKING POLICY mask_string;
-- Tag a column. It is now classified and masked by that one rule.
ALTER TABLE customer_features MODIFY COLUMN email SET TAG data_sensitivity = 'high';
-- Read every assignment back.
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.TAG_REFERENCES;Set the tag on a table, schema, or database and it flows down to the columns underneath through tag lineage. Tag once, and classification carries access control with it.
From classification to context
Snowflake built this for data classification, the warehouse's day job: mark which columns are PII, which are restricted, and let masking and access rules key off the tag. For an operational database it always read as a nice-to-have.
The LLM era makes it universal. A tag is EXIF for a table. Just as a photo file carries its own capture metadata inside it (camera, lens, GPS, timestamp), a tagged object carries its meaning inside the database, self-contained, so whatever opens it already knows what it is. An agent reading your schema has no external catalog and no tribal knowledge; it sees only what the database tells it. Inline metadata is context the model can use. Metadata in a separate system it has never heard of is not.
The big four fall short
So how do the databases most of the world runs on measure up? Walk down the top of the DB-Engines ranking.
| Database | Native metadata attachment |
|---|---|
| Oracle | No general tagging. Just COMMENT and the system data dictionary. |
| MySQL | Nothing beyond COMMENT. |
| SQL Server | Extended properties (sp_addextendedproperty), plus ADD SENSITIVITY CLASSIFICATION for column labels. Untyped, and nothing keys off them. |
| PostgreSQL | SECURITY LABEL and COMMENT, neither built for this. More below. |
The SQL standard never defined object tagging, so every vendor was free to skip it. SQL Server came closest: it can label a column, it just cannot act on the label. In Snowflake the tag drives the masking policy; nowhere in the big four does the metadata enforce anything. Postgres is the most telling case, so start there.
Postgres: a decade of asking
Postgres has circled this for more than a decade. SECURITY LABEL (2011) looks like the generic mechanism, but it was built for SELinux: a label only counts if a C-registered provider validates it, so it is unusable as a general-purpose tag without shipping an extension. That leaves COMMENT, a single unstructured string.
Requests for real user-defined properties keep recurring on the mailing lists; here is one from 2014. Postgres even ships a generic key-value OPTIONS bag, but fences it off to foreign-data-wrapper objects. For an ordinary table, it has never landed in core.
The timing is what gets me. Every database has spent the last two years racing to ship vector search, and the plainer feature next to it, the one that gives a model the context to use those vectors, went almost nowhere.