Workspace and Data Objects

Two containers: the account and the workspace

The first screens name a lot of things at once. Start with the two containers, because everything else lives inside one of them.

A Databricks account represents one organizational entity and can contain multiple workspaces. Account-level concerns include central identity, billing, support, and Unity Catalog access across workspaces. A workspace is a Databricks cloud deployment that gives a team an environment for accessing Databricks assets.

So the relationship runs one way: an account holds workspaces, never the reverse. A company with a marketing team and a risk team can give each its own workspace while keeping one account for identity and billing.

Three categories, not one long list

The single most useful habit early on is refusing to treat every named item as the same kind of thing. The Databricks user interface provides access to workspace folders and their objects, data objects, and computational resources.

Keep those three separate and most confusion disappears. A notebook is not compute — it is a page of work that needs compute to run. A table is not a folder — it is governed data, catalogued rather than filed. A cluster is not a data container — it processes data that lives elsewhere.

Reading a task through those three categories is a reliable habit:

• When a task says edit code, look for a notebook or another workspace asset.
• When it says run code, identify compute.
• When it says schedule repeatable work, think of a job.
• When it says locate governed data, move through the catalog and schema to the table, view, or volume.

This vocabulary is enough to understand the first screens, and it keeps later lessons readable: each new name slots into one of the three categories rather than joining an undifferentiated pile.

Workspace assets: what a team creates

A workspace organizes assets such as notebooks, libraries, dashboards, and experiments into folders. Folders are for people: they let a team keep its material together and find it again.

A notebook is a web-based interface that can contain runnable commands, visualizations, and narrative text. That combination is what makes it a development surface — code, its results, and the explanation of why it exists in one place. It is not the data, and it is not the machine that runs it.

A library is a package of code made available to a notebook or job. Reach for one when logic must be reused rather than pasted: the library is installed once and then imported by whatever needs it.

Compute runs it; a job repeats it

Writing a command is not running it. A cluster is a set of computation resources and configurations on which notebooks and jobs run. The configuration part matters as much as the machines: a cluster carries the settings under which your code executes.

Repeatable work needs a third thing. A job is a non-interactive mechanism for orchestrating and scheduling notebooks, libraries, and other tasks. In the product these appear as Lakeflow Jobs. Non-interactive is the key word — nobody has to open a page and press Run.

The practical distinction is where a person sits. A notebook is where someone develops and explores; a job coordinates repeatable execution once the exploring is finished.

Those three answer the three halves of a common request. Take an engineer who must write commands with explanatory text, run them on processing resources, and later schedule the same work without interaction.

1. Write it with the explanatory text — that is a notebook.
2. Run it on processing resources — that is a cluster.
3. Schedule it unattended — that is a job, which can take the notebook and any libraries as its tasks.

Nothing in the governed data hierarchy fits those three steps: a catalog, a schema, and a volume organize data, and a view saves a query rather than executing a timetable.

What Unity Catalog is responsible for

Once several teams share data, someone has to answer who may read what, where a column came from, and who touched it last. That is a separate responsibility from running code.

Unity Catalog provides centralized access control, auditing, lineage, and data discovery for data and AI assets across Databricks workspaces. Read the four words carefully, because each is a distinct guarantee:

The reach is what makes it central: it applies across workspaces, so an organization with one workspace per team still governs the shared tables in one place. Compute, libraries, and dashboards do other jobs entirely — executing, packaging, and presenting.

That combination answers a common design question. An organization with several workspaces that wants central access control and lineage for shared tables — while each team keeps its own working environment — does not have to choose. One account holds the multiple workspaces, and Unity Catalog governs the data across them.

The alternatives fail on their own terms. A separate account per table abandons the organizational container and leaves lineage as prose in comments. A single shared notebook is a development surface, not an access-control system. Compute cannot serve as the permission layer, because a cluster executes work rather than deciding who may see a table.

The governed hierarchy: catalog, schema, object

Governed data is addressed by walking down three levels, from the broadest container to the specific object.

A catalog is the highest-level container for organizing and isolating data. A schema, also called a database, is contained within a catalog and contains objects such as volumes, tables, functions, and models. Then comes the object itself.

A complete governed name follows the mental order catalog, then schema, then object. Only that order works: a schema cannot contain a catalog, and no object can contain either of them.

Choosing the object that matches your data

Inside a schema, pick the object by the shape of what you are storing.

A table organizes structured data and can be queried with Spark SQL or Spark APIs. A view is a read-only object derived from one or more tables or views and saves a query definition. A volume organizes and governs access to non-tabular data in cloud object storage.

Put the hierarchy and the objects together and a realistic request resolves itself. Say a team needs a governed object for structured sales rows and a separate governed location for image files, both inside the same business grouping.

• The business grouping is a schema, and that schema sits inside a catalog.
• The structured sales rows go into a table.
• The image files go into a volume.

Both objects live in the same schema, so they share its governance and are discovered together. The wrong-shaped answers invert the containment: a table cannot hold a schema, a volume does not host notebooks or clusters, and a view is a query definition rather than a place to put a job.

Key takeaways

• An account can contain multiple workspaces; a workspace is the team's environment for assets, data, and compute. Identity, billing, and cross-workspace governance are account-level concerns.
• The interface exposes three categories that should never be blurred: workspace folders and their objects, data objects, and computational resources.
• Notebooks hold interactive code and narrative content, while jobs orchestrate non-interactive tasks on compute. A library packages code so a notebook or job can reuse it, and a cluster is the set of computation resources and configurations they run on.
• Unity Catalog is the governance layer: centralized access control, auditing, lineage, and discovery for data and AI assets across workspaces.
• Unity Catalog organizes governed data from catalog to schema to an object such as a table, view, or volume. Tables take structured data, views save read-only query definitions, and volumes govern non-tabular files in cloud object storage.