Guides
Constraints
DuckDB allows defining [constraints](#docs:sql:constraints) such as `UNIQUE`, `PRIMARY KEY`, and `FOREIGN KEY`. These constraints can be beneficial for ensuring data integrity but they have a negative effect on load performance as they necessitate building indexes and performing checks. Moreover, they _very rarely improve the performance of queries_ as DuckDB does not rely on these indexes for join and aggregation operators (see [indexing](#docs:guides:performance:indexing) for more details).  
> **Best practice.  ** Do not define constraints unless your goal is to ensure data integrity.  
#### Microbenchmark: The Effect of Primary Keys {#docs:guides:performance:schema::microbenchmark-the-effect-of-primary-keys}  
We illustrate the effect of using primary keys with the [LDBC Comment table at scale factor 300](https://blobs.duckdb.org/data/ldbc-sf300-comments.tar.zst). This table has approx. 554 million entries. We first create the schema without a primary key, then load the data. In the second experiment, we create the schema with a primary key, then load the data. In both cases, we take the data from `.csv.gz` files, and measure the time required to perform the loading.  
<div class="narrow_table"></div>  
| Operation                | Execution time |
| ------------------------ | -------------: |
| Load without primary key | 92.2 s         |
| Load with primary key    | 286.8 s        |  
In this case, primary keys will only have a (small) positive effect on highly selective queries such as when filtering on a single identifier. They do not have an effect on join and aggregation operators.  
> **Best practice.  ** For best bulk load performance, avoid defining primary key constraints if possible.