Мой подписчик написал комментарий, который тянет на пост:

если бизнес логика у тебя полагается на монотонное возрастание uuidv7 (например дедубликация), а у тебя отсортировано не в том порядке — не самое приятное событие...
uuidv7 "ориентированный по времени" а не "транзакционно ориентированный"
тоесть у тебя может быть кейс когда транзакция с более поздним uuid закомитится раньше чем транзакция с более ранним uuid.
а раз раньше закомитилась — раньше вернула поток управления коду. и связанные записи (например релейшены) получают другой ордер (если это важно).

+ точность ордера ограничена 1 миллисекундой. если прилетело 5 запросов в одну миллисекунду — нет способа зарезолвить порядок. это кстати касается и бэкенда если что... но (!) при смене мастера — если часы рассинхронизированы больше чем на 1 миллисекунду возможны уже скачки во времени.
если у тебя реплики в разных датацентрах - скорее всего рассинхрон порядка 10-100мс, и значит точно будет прыгать.
что собственно не защищает и бэк, находящийся на разных инстансах за балансиром...

это не то что бы минусы uuid7, просто ограничение модели, но о них важно помнить, если не хочется гулять по граблям)