# (Soft-)deprecating \`Field.unique\`

**URL:** <https://forum.djangoproject.com/t/soft-deprecating-field-unique/38911>\
**Category:** Django Internals\
**Created:** [February 17, 2025, 3:40pm UTC](https://forum.djangoproject.com/t/soft-deprecating-field-unique/38911 "2025-02-17T15:40:28Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![tom](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/tom/32/6818_2.png) [@tom](https://forum.djangoproject.com/u/tom)\
**Post date:** [February 17, 2025, 3:40pm UTC](https://forum.djangoproject.com/t/soft-deprecating-field-unique/38911/1 "2025-02-17T15:40:28Z")

</div>

`db_index` has a note in the docs to use `Meta.indexes` instead. Because of the similarity of these and because of bugs such as [#34898 (Adding non-deterministic collations to unique CharFields crashes on PostgreSQL.) – Django](https://code.djangoproject.com/ticket/34898), I think it would also be wise to add a note to use `Meta.constraints` instead of `unique` as well.

Presumably more controversially I would also like to start a discussion around deprecating `db_index` and `unique`. Once removed it would reduce some logic in the schema generation code, which is currently quite complex because of these fields. It would also again give “one way to do it”. This will cause a lot of pain for users however, and there’s also some pain in the form of adding migrations for some of Django’s models. But I still think it’s worth having the conversation.

And if the answer is “no”, we should probably not say in the docs that “`db_index` may be deprecated in the future”. I personally think we should either do it or not, rather than give vague allusions that we may.

---

<div class="post-metadata">

**Author:** ![ryanhiebert](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/ryanhiebert/32/64_2.png) [@ryanhiebert](https://forum.djangoproject.com/u/ryanhiebert)\
**Post date:** [February 18, 2025, 8:36pm UTC](https://forum.djangoproject.com/t/soft-deprecating-field-unique/38911/2 "2025-02-18T20:36:31Z")

</div>

> [@tom](#):
>
> And if the answer is “no”, we should probably not say in the docs that “`db_index` may be deprecated in the future”.

Fully agreed here. It’s either worth deprecating or it’s not. If we don’t want to actually deprecate it, maybe we still want to have a pointer to another way because we think it’s generally better.

Personally, I think we need to have a little more appetite for breaking changes as we find better ways to do things. For me personally I’d be fine with it here, but recognize that it can be annoying.

---

<div class="post-metadata">

**Author:** ![emma](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/emma/32/21174_2.png) [@emma](https://forum.djangoproject.com/u/emma)\
**Post date:** [February 23, 2025, 2:36pm UTC](https://forum.djangoproject.com/t/soft-deprecating-field-unique/38911/3 "2025-02-23T14:36:15Z")

</div>

Is there any alternative?

I understand the want/need to simplify the schema generation logic. (which, admittedly I didn’t look at before posting this)

On the other hand, from the other ORM’s (mostly non-python) I’m familiar with, having unique/index set on the column definition itself is very common. (And I personally find it convenient).

By an alternative, I am thinking of a `get_constraints`, `get_indexes` method or something similar that would build an iterable similar to `Meta.indexes` and `Meta.constraints`. Those method would aggregate the content of `Meta` and what (if anything) is found in the fields declaration? Or is this already what we are doing and is this where the simplification would lie?