we should also think about what if existing projects want to migrate to this

Thta's true, but that is more complicated and I don't think I want to tackle migrating existing installations in this pull request.

Such migration might not even be feasible in a database agnostic way, as writing a safe migration might need to use database specific features. The project is tested against Postgres only, but it doesn't seem to use any PG only features? Is it supposed to work on other databases backend supported by Django?

what is your take on this PR? although it is not 100% design wise #314

what is your take on this PR? although it is not 100% design wise #314

That could also be a solution to the problem described in #307, although I would argue that's solving an othogonal problem. It's a bit heavy handed for thoses who only want to customise the primary key, and new users usually won't know about the primary key overflow until it's too late.

I'm seeing a fundamental missing piece betwen both PRs: formalising django-celery-results app settings better. What do you think of the implementation in this PR? I took this pattern from this post, which is making a great case for it.

If you have another pattern you prefer, I'm happy to use another example as a blueprint. I can contribute this piece separately first.

we should also think about what if existing projects want to migrate to this

There was an excellent talk at DjangoCon Europe about how to do this kind of migration safely at scale, and the TL;DR is:

1. Add new shadow column
2. Backfill the values
3. Swap the columns in a transaction

The 2nd step is particularly tedious and manual. It can take a long time and has some operational implications (creates dead tuples in PostgreSQL, themselves causing spikes in VACUUM)...

IMO django-celery-results should document a recipe but this should be left out of the package. Perhaps we could link to the talk when it's out?