Unity Catalog Naming Conventions

Names are stored in lowercase

Unity Catalog addresses every data asset with a three-part pattern: catalog.schema.object. Those three levels are the natural place to encode meaning, and they also impose rules you cannot negotiate with.

Object names are limited to 255 characters and are stored in lowercase, whatever case you typed when creating them. Matching is case-insensitive too, so SalesData, salesdata, and SALESDATA all resolve to the same object. Nothing is preserved as a separate capitalized twin, nothing is rejected for being lowercase, and no letter is rewritten into anything else.

The practical consequence is that letter case can never distinguish two objects. Two teams that believe they created different tables because one used capitals have created one table and are overwriting each other.

Column names are the exception: Unity Catalog preserves the casing you declare for them, although queries still match them case-insensitively.

Characters the namespace forbids

Some characters cannot appear in a Unity Catalog object name at all: periods, spaces, forward slashes, and control characters. The period is the most instructive of them, because it is the separator between the three levels of the namespace: sales.data is not a name, it is a reference to data inside sales.

A hyphen or another supported special character is allowed only when the identifier is enclosed in backticks. That is an escape hatch, not a convention: a name that needs quoting to survive is a name that will be mistyped.

A readable pattern: lowercase with underscores

The convention that fits those rules is lowercase words separated by underscores: customer_data, sales_summary, product_inventory. It reads cleanly and matches what the platform stores anyway.

Avoid camelCase and PascalCase for that same reason. Since every name is lowercased on storage, capitalization creates a gap between what you wrote and what exists, and the difference shows up later as confusion rather than as an error message.

Keep names descriptive but concise. sales_summary_gold communicates the domain and the data's maturity in three words. sales_final_report_v1_updated communicates a history: version details belong in metadata or object properties, not in an identifier that queries and pipelines must repeat forever.

Consistent prefixes make an object's purpose visible while browsing, before anyone opens it.

A prefix says what kind of object this is; it says nothing about who may read it. That distinction runs through this whole topic: names inform people, permissions decide what actually happens.

Catalogs by domain, by environment, or by both

A catalog name is the widest label you have, so it should carry the dimension that matters most for ownership and risk.

The combined pattern scales across business domains while keeping environments apart, and its cost is arithmetic: every domain multiplies by every environment, so the number of catalogs grows and needs managing.

Consider a company with sales and finance domains, each in development and production, that wants permissions granted for every domain-environment pair. The pattern produces exactly four catalogs — sales_dev, sales_prod, finance_dev, finance_prod — and each of them is a permission boundary.

The alternatives fall short in visible ways:

• One company_data catalog holding everything leaves no boundary to grant permissions on.
• Four unrelated catalogs named dev, prod, sales, and finance lose one dimension whichever way you read them.
• Anything built with periods is not a name at all, since the period is a namespace separator.

Separate catalogs for environment isolation

When development must not reach production data, put the boundary at the catalog level. Catalogs such as sales_dev, sales_test, and sales_prod separate the environments at the highest level of the namespace, and permissions can then be granted exactly there: developers work in the development catalog, production queries reference the production catalog, and cross-contamination has no path.

Weaker arrangements only look similar:

That is also the answer to the two-sided requirement: auditors want the environment obvious while browsing, and developers must never modify production data.

Names satisfy the first half. Permissions satisfy the second. Separate dev and prod catalogs make the lifecycle boundary visible in every reference, and catalog permissions granted by role make it real.

Naming is a communication control, never an access-control substitute. A name can mislead, be copied, or be ignored; only a grant decides who reads or writes. And since letter case is not preserved, a scheme that tries to distinguish Dev from DEV does not even produce two catalogs.

Layers inside an environment

Within an environment catalog, schemas are the natural place to express how far the data has been processed. The medallion pattern names three layers:

Read a full path and the pipeline stage is immediately legible: sales_data.bronze.raw_orders is raw order data, while sales_data.gold.monthly_revenue is a refined business metric.

Keep the dimensions apart. Layer names describe processing maturity, not lifecycle environment, not who may see the data, and certainly not the hardware underneath. Environment separation and sharing intent are named elsewhere and enforced by permissions.

Names that communicate sharing intent

When an external partner browses a catalog, its name is often the first thing they read about your organization. A good name states the business purpose and the sharing status without exposing internal structure.

• customer_analytics_shared says what the data is about and that it is meant to be shared.
• internal_sales_raw_data says the opposite just as clearly: this asset is not intended for an external audience.

Internal codes do not belong in a shared name. A catalog called d47_customer_analytics_external leaks a department code that means nothing to the partner and something to anyone probing your organization. And a name written as Customer Analytics Shared is not usable at all, because spaces are prohibited.

Once more, the boundary is enforced elsewhere: a name ending in _shared announces intent, while permissions decide who actually reads the data.

Make the convention stick

A convention that lives in one person's memory is not a convention. Four mechanisms turn it into something the organization actually follows.

1. Document the patterns centrally, with the reasoning and with examples of both valid and invalid names. "Use {domain}_{layer} for schema names" plus a wrong example removes far more ambiguity than a rule alone.
2. Validate names when deployments run. Automated deployment can check identifiers against the standard and reject the ones that violate it before the objects are created, which is the only moment a naming error is still cheap to fix.
3. Restrict who can create objects. Permissions cannot enforce a pattern, but granting object creation only to the team responsible for a catalog keeps assets from appearing in the wrong place.
4. Review what already exists. Query the information schema regularly to find identifiers that diverge from the standard, then rename them or record them as documented exceptions.

Note what does not work: renaming everything to PascalCase (the platform lowercases it anyway), granting broad read access (an access decision, not a naming check), or adding version history to identifiers (metadata, misplaced).

Key takeaways

• Unity Catalog names are limited to 255 characters, stored in lowercase, and matched case-insensitively; periods, spaces, forward slashes, and control characters are prohibited, and a hyphen requires backticks.
• Use lowercase with underscores, keep names descriptive but concise, leave version details to metadata, and use prefixes such as vw_ and tmp_ to signal object purpose.
• Use catalog names to express domain, environment, or both, with {domain}_{environment} when both dimensions matter and the extra catalogs can be managed.
• Use separate catalogs when development and production need real isolation, and let schema layers such as bronze, silver, and gold describe processing maturity within an environment.
• Make sharing intent visible without exposing internal structure, and remember that names communicate while permissions enforce.