Здравствуйте, vsb, Вы писали:

vsb>Разница в производительности на больших объёмах вставок тоже объективно будет. Вариант 2.2 собственно только ради этого и придумывался.

Не только на вставках, но и на последующих выборках.

vsb>3. Запросы order by id. Понятно, что обычно есть что-то вроде created_at, но всё равно удобно иметь возможность упорядочить строки в порядке создания, переиспользуя уже существующий индекс.

vsb>4. Читабельность. Ну тут целые числа однозначно приятней глазу, чем UUID.

Если нужен читабельный пользователями ID, лучше завести отдельный ключ, отличный от PK. Даже если PK это такой же int.

vsb>5. Безопасность.
vsb>Однако с вариантом 2.3 с безопасностью есть нюансы — утекает timestamp так или иначе.

И 2.2 и 2.3 можно перебирать/подбирать. Чуть сложнее, чем 1, но вполне успешно. Если нужно защититься от подбора, опять же заводим отдельный ключ, видимый "извне".

vsb>Также есть проблема с реализацией вариантов 2.2 и 2.3, это не слишком часто используемые подходы и возможно придется использовать редкие библиотеки или писать самому. Это не великая проблема, но всё же.

Не вижу проблемы. Библиотек полно, и все современные ОС предоставляют подобный сервис.

vsb>Я сейчас работаю над best practices, которыми будем руководствоваться в будущем для создания сервисов. И нужно этот вопрос решить. Плюсы и минусы там и там есть. Скорей склоняюсь к UUID 2.3, т.к. считаю, что проблемы с производительностью будут малозаметны, а удобство читаемых id не перевешивает плюсов UUID.

Главное помнить, что best practices это не догмы, а рекомендации. Подходы вполне можно совмещать, даже в рамках одной БД.
Таблицы-справочники, меняющиеся раз в год, и таблицы-перечисления, на которые ссылается полбазы, вполне могут жить с целочисленными ключами. Особенно если ключи укладываются, скажем, в байт. Проблемы генерации ключа на клиенте (раз в год) их не касаются.