POST_START

Transferring Ownership of Unity Catalog Objects

I recently took on the responsibility of managing access to our Unity Catalog in Databricks. As part of a team restructuring, I needed to transfer ownership of various catalog objects to different teams. The goal was to ensure that the right people had control over the data assets they worked with, while maintaining security and compliance. I started by identifying the catalog and schema that needed ownership changes.

Changing Catalog Ownership

I began with the catalog itself. The training catalog was initially owned by the data team, but we decided it should be managed by the data admins to centralize control. I ran the following command to transfer ownership:

ALTER CATALOG training SET OWNER TO `data_admins`;

I verified that the ownership had changed by checking the catalog details in the Databricks UI. It was clear that the new owner was now listed, and I felt confident that the first step was complete.

Transferring Schema Ownership

Next, I moved on to the schema within the training catalog. The sales schema was being used by the data engineers, and I wanted to ensure they had full control over it. I executed the following command:

ALTER SCHEMA training.sales SET OWNER TO `data_engineers`;

I checked the schema details in the UI again, and the owner was now listed as data_engineers. This step made sense because the data engineers would be the primary users of the sales schema, and having ownership aligned with usage is critical for collaboration and accountability.

Updating Table Ownership

With the schema ownership in place, I turned my attention to the tables within it. The customers table was a key asset for the data engineers, and I wanted to ensure they had full control over it as well. I ran the following command:

ALTER TABLE training.sales.customers SET OWNER TO `data_engineers`;

I confirmed the ownership change in the Databricks UI and noticed that the table now appeared under the data_engineers team. This made it clear that the data engineers would be the primary stewards of the customers table, which was exactly what we wanted.

Setting View Ownership

Finally, I addressed the views within the sales schema. The customer_view was a commonly used view, and I wanted to ensure that the data engineers could manage it effectively. I executed the following command:

ALTER VIEW training.sales.customer_view SET OWNER TO `data_engineers`;

I checked the view details in the UI, and the owner was now listed as data_engineers. This final step completed the transfer of ownership for all the key objects in the sales schema. I felt good about the changes, as they aligned with the new team structure and ensured that the right people had the right level of access and control.

Throughout the process, I learned the importance of carefully managing ownership in Unity Catalog. It’s not just about assigning rights—it’s about ensuring that the right teams have the responsibility and authority to manage the data assets they use. This experience has given me a deeper understanding of how to work with Unity Catalog in a collaborative and secure environment.