When Lakehouse Federation "loses" your tables: the silent space-in-name trap

Rohansingh01 — Mon, 08 Jun 2026 07:21:50 GMT

Spent some time on a Snowflake → Databricks federation issue that didn’t throw a single error - which is exactly what made it tricky. Sharing it in case it saves someone a debugging session.

The setup

Connection to Snowflake: established. Foreign catalog: created. I could browse the schema and see both my views and tables. Everything looked healthy.

The problem

A handful of objects were quietly missing from the federated catalog. No failure, no warning in the logs - they just weren’t there. The common thread? Every missing object had a space in its name (e.g. My View Name).

The why

This isn’t a bug or a permissions gap. It’s by design at the Unity Catalog metadata layer.

Unity Catalog disallows certain characters in all object names — catalogs, schemas, tables, views. Specifically: spaces, periods (.), forward slashes (/), and ASCII control characters. When you create a foreign catalog, any source table or view whose name contains these characters is silently skipped — Unity Catalog simply ignores it rather than erroring out.

And before you try: quoting or escaping (backticks, double quotes) won’t help here. The restriction lives in the UC metadata layer, not in your query syntax, so there’s nothing to escape your way around.

The workaround

Renaming production views usually isn’t an option, so the clean fix is a thin pass-through wrapper view with a UC-compliant name:

sql

CREATE VIEW my_view_name AS
SELECT * FROM "My View Name";

Why this works well:

Original production objects stay untouched — zero blast radius.
The wrapper is a pure pass-through (SELECT *), so there's no parallel logic to maintain.
Federation picks up the new, compliant name automatically.
Schema changes to the source flow through instantly, since it’s just a SELECT *.

If even wrapper views aren’t viable (e.g. governance constraints), the fallback is to clone the object into the lakehouse - reasonable when the data isn’t updated frequently.

The takeaway

Federation surfacing “most” of your objects can lull you into trusting the catalog completely. Always reconcile the source object count against what lands in the foreign catalog - a silent skip is far more dangerous than a loud failure.

Official docs which are worth to check out:

UC naming rules (space, period, slash, control chars not allowed): https://docs.databricks.com/aws/en/data-governance/unity-catalog/requirements
Federation explicitly ignoring invalid-named objects - “Tables and schemas with names that are invalid in Unity Catalog are not supported and are ignored by Unity Catalog upon creation of a foreign catalog”: https://docs.databricks.com/aws/en/query-federation/database-federation
Enable Snowflake catalog federation: https://docs.databricks.com/aws/en/query-federation/snowflake-catalog-federation
Working with foreign tables: https://docs.databricks.com/aws/en/tables/foreign

topic When Lakehouse Federation "loses" your tables: the silent space-in-name trap in Data Governance

When Lakehouse Federation "loses" your tables: the silent space-in-name trap