If you want to a UUIDv7 key for partitioning your table by date (e.g., one partition per day or month), you need to be able to compute the partition range via the minimal UUIDv7 for a given date.
I’ve just updated the article with several clarifications and an additional section based on the feedback received yesterday. Thanks to everyone who contributed suggestions!
Having software create the UUID is, IMO, more problematic than letting the DB create it itself as a part of its autogeneration for that identity column. Not the least because of any latency issues between a backend and the DB itself, if the DB is safely isolated from world+dog on a separate server that is only accessible by the backend.
It gets even worse if more than one backend has the ability to create entires that need to be in precise chronological order, either inserted “immediately” to a master DB or via eventual consistency through geographically distributed backends+DBs.
Sure, you can also use separate timestamp columns, but the timestamp portion of v7 appears to be sufficient for most use cases anyhow -- why have redundant data?
I believe I have recently bookmarked a trigger for MSSQL Server that is meant to autogenerate a UUIDv7 for an identity column, will try to link here later if anyone signals interest.
I think it depends on the use case. When strict ordering of records from multiple processes is not super important and when you also need the UUID7 for other things, it may be more practical (and/or performant) to let the client compute the UUID7.
Thanks for the comment. In the article I actually show both approaches: Python 3.14’s uuid.uuid7() first, mostly for completeness, and then the recommended one where PostgreSQL 18 generates the UUIDv7 itself using the native uuidv7() function. The DB-side version is already the default path I suggest for anything beyond a simple local setup.
Regarding the timestamp, a dedicated column generated by the database from uuid_extract_timestamp() can be very practical in Django. It is written at insert time by PostgreSQL, defined declaratively in the model with GeneratedField, and handled entirely by the ORM without relying on triggers. It also makes filtering, ordering or using the Django admin faster and simpler, since querying on a proper datetime field avoids extra annotations or computation on the UUID expression.
If you have a reference for UUIDv7 support in MSSQL I’d really appreciate it, ideally from the official documentation. I’m also curious to know from which version it is available and whether the current Django MSSQL backend exposes it already.
If you want to a UUIDv7 key for partitioning your table by date (e.g., one partition per day or month), you need to be able to compute the partition range via the minimal UUIDv7 for a given date.
There is some discussion whether or not to add helpers for this to Python‘s uuid7 module: https://github.com/python/cpython/issues/130843#issuecomment...
I’ve just updated the article with several clarifications and an additional section based on the feedback received yesterday. Thanks to everyone who contributed suggestions!
Having software create the UUID is, IMO, more problematic than letting the DB create it itself as a part of its autogeneration for that identity column. Not the least because of any latency issues between a backend and the DB itself, if the DB is safely isolated from world+dog on a separate server that is only accessible by the backend.
It gets even worse if more than one backend has the ability to create entires that need to be in precise chronological order, either inserted “immediately” to a master DB or via eventual consistency through geographically distributed backends+DBs.
Sure, you can also use separate timestamp columns, but the timestamp portion of v7 appears to be sufficient for most use cases anyhow -- why have redundant data?
I believe I have recently bookmarked a trigger for MSSQL Server that is meant to autogenerate a UUIDv7 for an identity column, will try to link here later if anyone signals interest.
I think it depends on the use case. When strict ordering of records from multiple processes is not super important and when you also need the UUID7 for other things, it may be more practical (and/or performant) to let the client compute the UUID7.
So, as usual, “it depends”. ;-)
Thanks for the comment. In the article I actually show both approaches: Python 3.14’s uuid.uuid7() first, mostly for completeness, and then the recommended one where PostgreSQL 18 generates the UUIDv7 itself using the native uuidv7() function. The DB-side version is already the default path I suggest for anything beyond a simple local setup.
Regarding the timestamp, a dedicated column generated by the database from uuid_extract_timestamp() can be very practical in Django. It is written at insert time by PostgreSQL, defined declaratively in the model with GeneratedField, and handled entirely by the ORM without relying on triggers. It also makes filtering, ordering or using the Django admin faster and simpler, since querying on a proper datetime field avoids extra annotations or computation on the UUID expression.
If you have a reference for UUIDv7 support in MSSQL I’d really appreciate it, ideally from the official documentation. I’m also curious to know from which version it is available and whether the current Django MSSQL backend exposes it already.