cancel
Showing results for 
Search instead for 
Did you mean: 
Administration & Architecture
Explore discussions on Databricks administration, deployment strategies, and architectural best practices. Connect with administrators and architects to optimize your Databricks environment for performance, scalability, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 

Naming covention guidelines

miraijaz
New Contributor

Dear all,

Appreciate if anyone  can provide the document/source related to Naming convention that can be followed within Databricks. 

 

Regards,

Aijaz

1 ACCEPTED SOLUTION

Accepted Solutions

Ashwin_DSA
Databricks Employee
Databricks Employee

Hi @miraijaz ,

Databricks doesn’t enforce a single enterprise-wide naming standard, but there are a few official/public guidelines you can lean on.

See the "Names" section of the SQL language reference.This covers allowed characters, length limits, and rules for catalogs, schemas, tables, views, and columns

For workspace naming conventions, the deployment guide recommends a pattern like {organization}-{environment}-{region}-{purpose} (for example, acme-prod-us-west-analytics, acme-dev-shared) and suggests using lowercase and hyphens, always including the environment, and keeping names short and documented. See the Define workspace naming conventions on this page.

For notebook naming best practices, the Databricks Community thread below suggests descriptive, concise names (often with a project/pipeline prefix), using dashes/underscores instead of spaces, and avoiding special characters:
https://community.databricks.com/t5/data-engineering/notebooks-naming-convention/td-p/54713

A common pattern many customers adopt is to standardise on lower_snake_case (or lower-hyphen-case) with clear environment indicators (for example, prod_finance, stg_marketing, acme-prod-us-west-analytics) and then document these rules in their internal runbook so teams apply them consistently across catalogs, schemas, tables, workspaces, and notebooks.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.

Regards,
Ashwin | Delivery Solution Architect @ Databricks
Helping you build and scale the Data Intelligence Platform.
***Opinions are my own***

View solution in original post

1 REPLY 1

Ashwin_DSA
Databricks Employee
Databricks Employee

Hi @miraijaz ,

Databricks doesn’t enforce a single enterprise-wide naming standard, but there are a few official/public guidelines you can lean on.

See the "Names" section of the SQL language reference.This covers allowed characters, length limits, and rules for catalogs, schemas, tables, views, and columns

For workspace naming conventions, the deployment guide recommends a pattern like {organization}-{environment}-{region}-{purpose} (for example, acme-prod-us-west-analytics, acme-dev-shared) and suggests using lowercase and hyphens, always including the environment, and keeping names short and documented. See the Define workspace naming conventions on this page.

For notebook naming best practices, the Databricks Community thread below suggests descriptive, concise names (often with a project/pipeline prefix), using dashes/underscores instead of spaces, and avoiding special characters:
https://community.databricks.com/t5/data-engineering/notebooks-naming-convention/td-p/54713

A common pattern many customers adopt is to standardise on lower_snake_case (or lower-hyphen-case) with clear environment indicators (for example, prod_finance, stg_marketing, acme-prod-us-west-analytics) and then document these rules in their internal runbook so teams apply them consistently across catalogs, schemas, tables, workspaces, and notebooks.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.

Regards,
Ashwin | Delivery Solution Architect @ Databricks
Helping you build and scale the Data Intelligence Platform.
***Opinions are my own***