Choosing managed tables versus unmanaged tables

In Azure Databricks, tables are either managed—where Databricks controls both the metadata and the underlying data files in the default storage location—or unmanaged (external), where Databricks only manages the metadata while you control the data's storage location. Choosing between them affects how DROP TABLE behaves and how you organize data for sharing or governance across multiple systems.

1 · Learn the must-know

• 1Dropping a managed table deletes both its metadata and the underlying data files, so it cannot be recovered unless you have a separate backup.
• 2Dropping an unmanaged (external) table only removes the metadata from the metastore; the actual data files remain untouched in their external location.
• 3Managed tables store data in the default location under the metastore's or database's managed storage path (e.g., DBFS root or a configured managed storage location), while unmanaged tables use a LOCATION clause pointing to an external path such as ADLS Gen2.
• 4Use unmanaged tables when data must persist independently of the table definition, be shared across multiple workspaces/tools, or already exists in a specific storage location you don't want Databricks to control.
• 5Use managed tables for simpler lifecycle management, since Databricks handles storage cleanup automatically and they integrate cleanly with Unity Catalog governance features.
• 6In Unity Catalog, managed tables benefit from optimized storage and governance features (like Predictive Optimization), whereas external tables require an external location and storage credential to be configured for access.

2 · Check your understanding