The table-size thresholds for partitioning, partition sizing, and why liquid clustering is usually the better choice.
From Ultra Transcenders DP-750 by Tony Rough (coming November 2026)
Partitioning splits a table’s files into directories by the values of one or more columns. Learn’s current guidance is that most tables do not need it: Databricks recommends liquid clustering for all new tables, and unpartitioned Delta tables automatically get ingestion time clustering, which gives partitioning-like performance for date-based queries without tuning.
| Table size | Learn’s recommendation |
|---|---|
| Less than 1 TB | Do not partition |
| 1 TB to 100 TB | Use liquid clustering instead of partitioning; partitioning is more likely to hurt than help |
| 100 TB or more | Partitioning might help, but try liquid clustering first and verify the improvement |
| Any partitioned table | Each partition should hold at least 1 GB; fewer, larger partitions beat many small ones |
If you do partition, choose low or known cardinality columns (dates, regions), never high-cardinality ones such as timestamps or customer IDs. Partition columns must be top-level columns of a supported type (date, timestamp, string, numeric, boolean, binary and so on); you cannot partition by a struct field, map, array or VARIANT. Transactions in Delta are not defined by partition boundaries, so partitioning is not needed for atomicity. An ineffective scheme may need a full rewrite to fix, which is slow and expensive for large tables.
For managed Iceberg tables, Unity Catalog supports only liquid clustering and interprets PARTITIONED BY columns from external engines as clustering keys. To move an existing partitioned Delta table to liquid clustering in Databricks Runtime 18.1 and above, use ALTER TABLE ... REPLACE PARTITIONED BY WITH CLUSTER BY, which minimises downtime and works for managed and external tables (not for pipeline streaming tables and materialized views, where you change the definition to CLUSTER BY):
ALTER TABLE main.sales.events REPLACE PARTITIONED BY WITH CLUSTER BY (event_date, customer_id);
OPTIMIZE main.sales.events;Common trap: Partitioning a fact table by its event timestamp or customer ID - partitioning works only for low or known cardinality columns and creates many tiny partitions otherwise. Use liquid clustering, which handles high-cardinality columns and avoids fixed partition boundaries.
This note is one section of Ultra Transcenders DP-750: Implementing Data Engineering Solutions Using Azure Databricks, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.
Due on Amazon in November 2026, in Kindle and paperback editions.
About the book · DP-750 terms in the glossary · All DP-750 study notes
What standard (formerly shared) and dedicated (formerly single user) access modes allow, and when each is required.
Who manages the files, what DROP TABLE does to each, and why Databricks recommends managed tables.
How SQL UDF row filters and column masks restrict data per user, and how they differ from dynamic views.
How the two retention properties and VACUUM decide which table versions you can still query or restore.
SCD types 0, 1, 2 and others compared, and when to keep history in a dimension table.
How expectations validate records in Lakeflow Spark Declarative Pipelines and what each violation action does.
Job and task notifications, system destinations, duration warnings and how retries affect which alerts are sent.