Unity Catalog Native Examples

Real scenarios showing what Unity Catalog Native does with a catalog arranged in different ways. Pick a tab to see what to expect from the Sync, the Profile, and the Scan in each situation.

Databricks WorkspaceSeveral SchemasOpen-Source ServerMixed TablesCredential Rotation

Monitoring a Delta schema without starting a cluster

Context. A team keeps its curated tables in the sales schema of the prod catalog on Databricks, all of them managed Delta tables partitioned by day. Until now they monitored them through the Databricks connector, which meant keeping a SQL warehouse running for every nightly scan. They add a Unity Catalog Native datastore with the workspace URL, a service principal under OAuth (Service Principal), prod as the catalog, and sales as the schema.

What happens. The Sync lists every table in prod.sales and records each schema from the catalog. No storage is read at this point, so it finishes in seconds. The first Profile is where storage is touched: for each table, Unity Catalog hands Qualytics a short-lived credential for that table's files, and Qualytics reads the Delta files directly from cloud storage. When a Scan filters to a single day, only the partitions for that day are read.

Why it works. Table definitions and data live behind different services, and the native path pays for each one only when it needs it. The warehouse the team used to keep running is no longer part of the picture: the only Databricks resource involved is the catalog, which answers in milliseconds.

One catalog, five schemas, one connection

Context. The same prod catalog holds bronze, silver, gold, finance, and marketing, and the team wants all five monitored with the same credential.

What happens. They create the connection once, with prod as the catalog, and pick all five schemas in Location. Name turns into Name Template, and prod_{{schema}} names the five datastores prod_bronze, prod_silver, and so on. Each datastore syncs its own schema. Six months later, when partners is added to the catalog, they add it with Add with an Existing Connection, reusing the saved connection.

Why it works. The catalog belongs to the connection and the schema belongs to the datastore. One credential, granted on the five schemas, serves five datastores, and changing it later is a single edit on the connection rather than five.

A Unity Catalog server that is not Databricks

Context. A platform team runs the open-source Unity Catalog server in their own cloud account, in front of Delta tables in object storage, and no Databricks workspace is involved. They expect the connector to refuse a URL that is not a Databricks address.

What happens. Nothing in the form changes. URL takes the server's address, the credential is the token the server issues for Qualytics, and the Catalog and Schema dropdowns fill in from the server's own listing. The server hands out storage credentials the same way a workspace does, so the Sync, the Profile, and the Scan behave exactly as they do against Databricks.

Why it works. The connector speaks to Unity Catalog, not to Databricks. Anything that serves the Unity Catalog interface and can vend a storage credential for its tables looks the same to Qualytics.

A schema where not everything can be read natively

Context. A realistic schema rarely holds plain Delta tables alone. This one has five objects, and the team wants to know what they will get before they connect it.

Object	What it is	Result
`orders`	Managed Delta table, partitioned	Read
`customers`	External Delta table	Read
`v_active_customers`	View	Not a container
`events_iceberg`	Table reachable only through the Iceberg endpoint	Not a container
`legacy_contacts`	Foreign table from a federated connection	Not a container

What happens. The Sync succeeds. orders and customers become containers to profile and scan. The other three do not become containers. The Sync's warning reports them: as a count of skipped objects when the catalog refuses them outright, and by name when the catalog lists them but Qualytics cannot read them. None of them holds up the rest of the schema. The team then connects the same workspace with the Databricks connector and points a second datastore at the same schema, monitoring the two Delta tables through Unity Catalog Native and the remaining three through a SQL warehouse.

Why it works. orders and customers are files in cloud storage with a Delta log that says which files are current, which is exactly what the native path reads. The other three are not: a view is a query that only Databricks can run, and the Iceberg and foreign tables are served by other engines. Running both connectors against one workspace is a supported arrangement, not a workaround.

Changing the credential without touching the datastores

Context. Security policy requires the personal access token on a connection to be replaced every ninety days. The connection serves four datastores.

What happens. An administrator generates the new token in Databricks, opens the connection in Manage Connections, pastes the new value into Access Token, and saves. The four datastores pick it up on their next operation. Nothing on the datastores themselves changes.

Why it works. The credential lives on the connection, and every datastore reads through it. Had the team used OAuth (Service Principal) instead, there would be no token to replace at all, since Qualytics requests short-lived tokens on its own. The secret still has to be replaced when the service principal's secret itself expires, which Databricks lets you set to a longer interval.