# Azure Synapse Analytics: Partition vs Distribution

While using Azure Synapse Analytics dedicated SQL pools, sometimes it is confusing the purpose of **partitioning** and **distribution.** They are both used to manage data for performance optimization, but serve different purposes.

### Distribution

**Distribution** refers to how data is spread across **60 physical nodes** (called **distributions**) in a dedicated SQL pool. When you create a table, you choose a **distribution strategy** that defines how data is distributed across these nodes:

* **Hash distribution**: Distributes rows based on the hash value of a specified column. This is effective for large tables involved in joins or aggregations on that column, as it minimizes data movement during queries.
    
* **Round-robin distribution**: Distributes rows evenly across all nodes, without regard to column values. This is useful for smaller tables or those not frequently joined.
    
* **Replicated distribution**: Creates a full copy of the table on each node. This is suitable for small, dimension-type tables (e.g., lookup tables) and helps avoid data movement during joins.
    

The primary goal of distribution is **parallel processing**—breaking down data so that each distribution (node) processes a part of the workload simultaneously, which enhances performance, especially for large datasets.

### Partitioning

**Partitioning** organizes data **within each distribution** based on a specific column, such as a date or transaction month. Each distribution (node) holds multiple partitions based on the chosen partition key. For example, if you partition by **TransactionMonth**, each distribution will have separate partitions for each month.

Partitioning works well when you need to manage **very large tables** (hundreds of millions or billions of rows) with queries frequently filtered by the partitioned column (e.g., querying specific months or years).

The main goal of partitioning is to **optimize data scanning and query performance** by allowing the SQL pool to quickly eliminate irrelevant data partitions based on the filter conditions in queries. This reduces the amount of data read, saving time and resources.

### Key Differences

| **Aspect** | **Distribution** | **Partitioning** |
| --- | --- | --- |
| **Function** | Spreads data across nodes for parallelism | Organizes data within each node for filtering efficiency |
| **Scope** | Applies at the **table level** across nodes | Applies within each **distribution** on each node |
| **Strategies** | Hash, Round-robin, Replicated | Typically partitioned by range (e.g., date) |
| **Use Cases** | Joins, aggregations across large tables | Query performance on very large tables with predictable filters (e.g., date) |
| **Common Keys** | Join or common filter column | Date or time-based column for efficient slicing |

**Distribution** would apply to how the table is spread across nodes, and **partitioning** by date range or month would organize the data within each node to improve filtering and query performance.