[naranha]

Does this stay compatible with the old uuid column type, as uuidv7() uses the same 128 bit format as gen_random_uuid()?

That would mean it's easy to update old apps, as we would only have to change the default value for the columns.

[pgaddict]

Yes, internally it's the same as every other UUID (16 bytes, passed by reference). There's no reason to store / represent it differently.

[mplanchard]

Yes, we have already updated our in-app UUID generation to use v7 UUIDs and are storing them in regular postgres UUID columns (postgres 14). Works great!

[ghusbands]

Note that, as jmull says in https://news.ycombinator.com/item?id=39262286 , embedding timestamps in every uuid can potentially expose private information.

[mplanchard]

Yes, you can check UUIDs to see if they’re v7, and extract the timestamp if so. This seems to me less problematic in most cases than being able to guess the next ID (as is the case with numeric IDs). At least for us, anybody with access to the ID also has access to the time the record was created, so there’s no new information being exposed.

It’s a good thing to keep in mind though for sure.

[Merad]

Yes, you can use v7 today with uuid columns, you just need to add a custom function (or the more performant pg_uuidv7 extension) to generate them.