Databricks automatically create a catalog when a new worksapce

aiops

Here is a refined version you can post in a forum.

Title

Why does Databricks automatically create a catalog when a new workspace is created?

Description

Hi Team,

I have a question regarding Databricks workspace creation and Unity Catalog behavior.

When I create a new workspace from the Databricks Account Console, I notice that a catalog is automatically created and visible under the Data section in the Account Console.

I would like to understand the following:

Why does Databricks automatically create a catalog during workspace creation?
Is this catalog created as part of Unity Catalog enablement?
Is the auto-created catalog tied only to that specific workspace, or can it be accessed from other workspaces as well?
Should this default workspace catalog be used for real project data, or should we create separate catalogs such as dev, uat, prod, or project-specific catalogs?
Is it safe or recommended to delete/ignore this auto-created catalog if we plan to manage catalogs manually?

My understanding is that new Databricks workspaces are automatically enabled for Unity Catalog, and Databricks creates a default workspace catalog so users can immediately start creating schemas, tables, volumes, and other governed objects.

Could someone please confirm if this understanding is correct and share the recommended best practice for enterprise workspace and catalog design?

Thanks.

aiopsschool

This is normal Databricks behavior now.

When you create a new Databricks workspace, Databricks automatically enables Unity Catalog for modern workspaces. Unity Catalog is the governance layer for tables, volumes, models, permissions, lineage, auditing, and data discovery. Databricks says Unity Catalog is automatically enabled for workspaces created after November 8, 2023. ([docs.databricks.com][1])

So the flow is basically:

New Databricks Workspace
        ↓
Workspace is attached to Unity Catalog metastore
        ↓
Databricks creates default workspace catalog
        ↓
You see it under Account Console > Data / Catalog

Why catalog is created automatically?

Because Databricks wants every new workspace to be immediately ready for the modern 3-level namespace:

catalog.schema.table

Example:

SELECT * FROM my_workspace_catalog.default.my_table;

Without a catalog, users cannot properly create governed tables, schemas, volumes, lineage, permissions, etc.

What exactly gets created?

Usually you may see these automatically:

| Object | Why it exists |
| ---------------------------------- | ------------------------------------------------------------- |
| Workspace catalog | Default catalog created for the new workspace |
| hive_metastore | Legacy Hive metastore compatibility catalog |
| default schema | Default schema/database inside the catalog |
| __databricks_internal... objects | Internal Databricks-managed objects used by platform features |

Databricks officially says that in all new workspaces, a workspace catalog is created by default, usually with the same name as the workspace. It is meant as a convenient place for users to create and test Unity Catalog objects. (docs.databricks.com)

Why do you see it in this page?

The second page you opened is the Databricks Account Console > Data area. That page shows Unity Catalog / metastore / catalog-level objects for your account.

So when you create a workspace from:

Account Console > Workspaces

Databricks may automatically show the related catalog in:

Account Console > Data

That does not mean you manually created a production database. It means Databricks provisioned the default governance container for that workspace.

Important point: workspace catalog is isolated by default

The automatically created workspace catalog is normally bound only to that workspace. That means it is not openly shared with every workspace by default. Databricks documents this as the default workspace-catalog binding behavior. (docs.databricks.com)

So if you create:

workspace-dev
workspace-uat
workspace-prod

Databricks may create separate workspace catalogs like:

workspace-dev
workspace-uat
workspace-prod

Each one is mainly for its own workspace.

Why did Databricks design it like this?

Because Unity Catalog is now the default governance model.

Previously, Databricks heavily used:

hive_metastore.database.table

Now the recommended model is:

catalog.schema.table

For example:

dev.raw.orders
dev.analytics.customer_summary

prod.raw.orders
prod.analytics.customer_summary

The catalog gives Databricks a clean top-level boundary for:

| Capability | Why catalog matters |
| ----------------- | --------------------------------------------- |
| Permissions | Grant access at catalog/schema/table level |
| Data isolation | Separate dev, uat, prod, finance, sales, etc. |
| Lineage | Track where data came from and where it goes |
| Auditing | See who accessed what |
| Sharing | Share governed data safely |
| Workspace binding | Control which workspace can use which catalog |

Is this a problem?

No. This is expected.

But for enterprise setup, I would not treat the auto-created workspace catalog as your final production design.

Use it for:

learning
testing
temporary work
small workspace-local data

For real project structure, create proper catalogs such as:

dev
uat
prod
sandbox
shared
finance
sales
analytics

or for your org:

evp_dev
evp_staging
evp_uat
evp_prod

Then apply permissions, storage locations, and workspace bindings properly.

Should you delete the auto-created catalog?

Usually, no need.

Better options:

| Action | When to use |
| ------------------------------------ | -------------------------------------------- |
| Leave it as-is | Best default |
| Change default catalog | If you want users to land in another catalog |
| Restrict permissions | If users should not create random objects |
| Bind catalogs to specific workspaces | For dev/prod isolation |
| Create proper project catalogs | For real enterprise data architecture |

A workspace admin can change the default catalog for a workspace. Databricks also warns that changing the default catalog can break existing operations if code depends on the old default. (docs.databricks.com)

Simple answer for your team

You can say this:

When we create a new Databricks workspace, Databricks automatically enables Unity Catalog and creates a default workspace catalog. This is expected behavior. The catalog is the top-level governance container used for schemas, tables, volumes, permissions, lineage, and auditing. It is usually named after the workspace and bound only to that workspace by default. For production, we should create dedicated environment/project catalogs and manage permissions and workspace bindings properly, instead of relying only on the auto-created workspace catalog.

[1]: https://docs.databricks.com/aws/en/data-governance/unity-catalog/get-started "Get started with Unity Catalog | Databricks on AWS"