3 comments

[ 138 ms ] story [ 1958 ms ] thread
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’ve just updated the article with several clarifications and an additional section based on the feedback received yesterday. Thanks to everyone who contributed suggestions!
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...