# Wrong BigAutoField? **URL:** \ **Category:** Using Django\ **Created:** [October 3, 2021, 4:30pm UTC](https://forum.djangoproject.com/t/wrong-bigautofield/9953 "2021-10-03T16:30:14Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![ukrolelo](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/ukrolelo/32/4193_2.png) [@ukrolelo](https://forum.djangoproject.com/u/ukrolelo)\ **Post date:** [October 3, 2021, 4:30pm UTC](https://forum.djangoproject.com/t/wrong-bigautofield/9953/1 "2021-10-03T16:30:14Z")
Greetings, as per documentation on [Model field reference | Django documentation | Django](https://docs.djangoproject.com/en/3.2/ref/models/fields/) BigAutoField `BigAutoField` ( \*\*_options_ )[¶]except that it is guaranteed to fit numbers from `1` to `9223372036854775807` . It created in Mysql this bigint which is A large integer. The signed range is `-9223372036854775808` to `9223372036854775807` ```auto id = models.BigAutoField(primary_key=True) ``` Any ides how can i make positive bigautofield only? ---
**Author:** ![adamchainz](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/adamchainz/32/26_2.png) [@adamchainz](https://forum.djangoproject.com/u/adamchainz)\ **Post date:** [October 3, 2021, 5:13pm UTC](https://forum.djangoproject.com/t/wrong-bigautofield/9953/2 "2021-10-03T17:13:24Z")
Django’s autoincrement behaviour will only use the positive numbers by default. If you’re concerned about accidental insertion of negative values, you can subclass the field or use a check constraint to limit the range as per [my related blog post](https://adamj.eu/tech/2021/05/08/django-check-constraints-limit-range-integerfield/). ---
**Author:** ![ukrolelo](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/ukrolelo/32/4193_2.png) [@ukrolelo](https://forum.djangoproject.com/u/ukrolelo)\ **Post date:** [October 3, 2021, 6:26pm UTC](https://forum.djangoproject.com/t/wrong-bigautofield/9953/3 "2021-10-03T18:26:55Z")
Hi, i am not much concerned about negative numbers but rather correct implementation for migration and syncdb. As it is not correct. ---
**Author:** ![adamchainz](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/adamchainz/32/26_2.png) [@adamchainz](https://forum.djangoproject.com/u/adamchainz)\ **Post date:** [October 3, 2021, 7:45pm UTC](https://forum.djangoproject.com/t/wrong-bigautofield/9953/4 "2021-10-03T19:45:45Z")
> [@ukrolelo](#): > > As it is not correct. I don’t understand in what way it is not correct. Django promises to fit _at least_ the numbers 1 to 9223372036854775807. That 0 and negative numbers are supported is an extension. ---
**Author:** ![ukrolelo](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/ukrolelo/32/4193_2.png) [@ukrolelo](https://forum.djangoproject.com/u/ukrolelo)\ **Post date:** [October 4, 2021, 11:08am UTC](https://forum.djangoproject.com/t/wrong-bigautofield/9953/5 "2021-10-04T11:08:17Z")
Okay, lets say i want 0-65535 smallint unsigned on mysql. How can i achieve that? With 2 Storage (Bytes) as per mysql documentation smallint unsigned. Correct me if i’m wrong but the empty cells still consume storage in DB. So if we have 1 to 9223372036854775807 or -9223372036854775808`to`9223372036854775807 It is 2x the difference in storage space. ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [October 4, 2021, 11:12am UTC](https://forum.djangoproject.com/t/wrong-bigautofield/9953/6 "2021-10-04T11:12:13Z")
> [@ukrolelo](#): > > Correct me if i’m wrong but the empty cells still consume storage in DB. > So if we have > 1 to 9223372036854775807 > or > -9223372036854775808 `to` 9223372036854775807 > It is 2x the difference in storage space. Ok, you’re wrong. 1 to 9223372036854775807 - requires 63 bits. -9223372036854775808 `to` 9223372036854775807 - uses 64 bits. In either case, an instance of that field is going to be stored in 64 bits. If you’re working with a 64-bit unsigned value (instead of a two’s complement integer), the range would be `0` to `18446744073709551615`. ---
**Author:** ![adamchainz](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/adamchainz/32/26_2.png) [@adamchainz](https://forum.djangoproject.com/u/adamchainz)\ **Post date:** [October 4, 2021, 2:54pm UTC](https://forum.djangoproject.com/t/wrong-bigautofield/9953/7 "2021-10-04T14:54:57Z")
Ken is right that there’s no space saving from unsigned vs signed. > [@ukrolelo](#): > > Okay, lets say i want 0-65535 > smallint unsigned on mysql. > How can i achieve that? To use an autofield with small unsigned integers you’ll want to use a subclass. But it’s _not_ a good idea. The reason Django moved its default from 32 bit to 64 bit is the danger of _ID exhaustion_ - running out of autoincrement ID’s. This typically takes down a site until its database can be migrated - several large companies have had large outages because of this, e.g. Basecamp and Sentry. If you’re looking for the storage savings from using 2 bytes instead of 8 - they’re _really_ small compared to the cost of storage. The tradeoff will basically _never_ be worth it. You’ll realize much larger storage savings using a compressed database format e.g. PostgreSQL on ZFS or MariaDB’s table compression. This will compress _all_ your data, not just the autoincrement column, and can save you a bunch of disk space. ---
**Author:** ![ukrolelo](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/ukrolelo/32/4193_2.png) [@ukrolelo](https://forum.djangoproject.com/u/ukrolelo)\ **Post date:** [October 4, 2021, 6:43pm UTC](https://forum.djangoproject.com/t/wrong-bigautofield/9953/8 "2021-10-04T18:43:43Z")
Thank you guyz! Got it. ---
**Author:** ![ukrolelo](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/ukrolelo/32/4193_2.png) [@ukrolelo](https://forum.djangoproject.com/u/ukrolelo)\ **Post date:** [October 4, 2021, 6:48pm UTC](https://forum.djangoproject.com/t/wrong-bigautofield/9953/9 "2021-10-04T18:48:26Z")
But is it okay that django is automatking on mysql column with bigint and not bigint unassigned? Then its not 64bits?! Different question then, what should i do so that django model will create bigint unassigned? ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [October 4, 2021, 6:52pm UTC](https://forum.djangoproject.com/t/wrong-bigautofield/9953/10 "2021-10-04T18:52:50Z")
> [@KenWhitesell](#): > > 1 to 9223372036854775807 - requires 63 bits. > -9223372036854775808 `to` 9223372036854775807 - uses 64 bits. > > **In either case, an instance of that field is going to be stored in 64 bits.** (emphasis added) To answer your other question, you don’t - nor should you worry about it. It will never become a problem.