You can always treat IDs as UUIDv4, while actually storing them as UUIDv7—combining the benefits of both. From your perspective, they’re just UUIDv4

▲

kevlened 5 days ago | parent [-]

One impact of the_mitsuhiko's second point is during debugging.

Usually if you see an id in your http logs you can simply search your database for that id. The v4 to v7 indirection creates a small inconvenience.

The mismatch may be resolved if this was available as a fully transparent database optimization.

▲

aabbdev 5 days ago | parent | next [-]

A Postgres extension is currently in development to provide transparent database optimization with custom type uuid45 and optional helpers ;)

	▲	the_mitsuhiko 5 days ago \| parent [-]
		That would generally be nice to have. I would love to have base62 encoded IDs with prefixes but store it internally as UUID.

▲

nightpool 5 days ago | parent | prev [-]

Not just a small inconvenience—because there's no human readable way to tell the difference between v4 and v7 IDs, you have to guess and check whether or not the ID your server process is logging is a pre-conversion or post-conversion ID

	▲	Dylan16807 5 days ago \| parent \| next [-]
		The human readable way to tell the difference is you look at whether the third group starts with a 4 or a 7.
	▲	kbumsik 4 days ago \| parent \| prev [-]
		It is really easy to tell the difference btw. You will always see "4" or "7" in the middle.