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:
