# SerialFields - Yay or Nay?

**URL:** https://forum.djangoproject.com/t/serialfields-yay-or-nay/32541
**Category:** ORM
**Created:** [June 28, 2024, 10:31am UTC](https://forum.djangoproject.com/t/serialfields-yay-or-nay/32541 "2024-06-28T10:31:55Z")
**Posts on this page:** 1
**Showing post:** 21

<div class="post-metadata">

### Author: ![nessita](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/nessita/32/12194_2.png) [@nessita](https://forum.djangoproject.com/u/nessita)
#### Post date: [September 17, 2024, 3:15pm UTC](https://forum.djangoproject.com/t/serialfields-yay-or-nay/32541/21 "2024-09-17T15:15:18Z")

</div>

Hello everyone!

I had an action item to follow up on this. I did: I read tickets and this post, database docs and I had a chat with @charettes. Given this nice summary from Ben, below my thinking:

> [@csirmazbendeguz](#):
>
> | Feature | SQLite | MySQL | Oracle | PostgreSQL |
> | --- | --- | --- | --- | --- |
> | Multiple AutoFields | no | no | no | yes |
> | AutoField in composite PK | no | yes | yes | yes |
> 
> 1. If we’re considering using AutoFields in composite primary keys, all backends except SQLite support that.
> 2. If we’re considering using AutoFields for any other purpose (e.g. “order column”), then only PostgreSQL supports that.
> 
> SerialFields were originally intended for _(2)_. We just also saw the opportunity to use it for _(1)_.

I believe both items (1) and (2) are relevant on their own, each with a distinct use case, and can be addressed as separate tickets. Divide and conquer! 🛡

Currently, item (1) is tracked in [ticket-8576](https://code.djangoproject.com/ticket/8576), which is open but in a “Design Decision Needed” triage state. Allowing `primary_key=False` in an `AutoField` would enable all DB backends except SQLite to use such a field as part of a composite primary key. However, no backend except PostgreSQL supports having more than one `AutoField`. To progress this ticket, we need someone to take ownership and propose an outline for the implementation, so it can be moved to “Accepted” and enter the review process. Given the nature of the change, I fear this may be a longer and slower process.

On the other hand, I see value in having a way to define DB-level “counters” (independent of composite PKs), which is what item (2) addresses. Only PostgreSQL supports this, so I would prefer a PostgreSQL-specific field for this feature. While `serial` is no longer recommended, a `GeneratedIdentityField` in `django.contrib.postgres`, as suggested by Simon, seems like a promising alternative and could be more actionable in the short term. I recommend reopening [ticket-27452](https://code.djangoproject.com/ticket/27452) and repurposing it for this feature.

---

_[View the full topic](https://forum.djangoproject.com/t/serialfields-yay-or-nay/32541)._