Не подскажите, есть ли смысл использовать UUID как PK если не планируется кластеризация или распределённая БД?
И в целом, когда стоит использовать UUID вместо auto incremented integers?

почему бы и нет?

Например потому, что UUID занимает больше места, по нему нельзя сортировать, у некоторых БД использование  UUID вызывает проблемы с производительностью (читал, что InnoDB приходится чаще читать данные с диска когда индекс построен по UUID

Впервые слышу про такую проблему с InnoDB.
Уверен, что в обновлениях это решили или решат.

Касательно сортировки это вообще фигня. С ид ты будешь создавать поле с датой, чтоб знать когда это было сделано.

мне честно сказать никогда не приходилось сортировать по id

А в чем тогда преимущество UUID перед обычным числом как PK?
Во многих проектах его ставят по умолчанию. Интересно почему

Хороший вопрос
Я даже видел использование uuid при том, что это была база с кластеризованным pk, и добавление записей было крайне дорогим. Я так понял, люди сделали это просто по незнанию
А в монге, например, это используется для того, чтобы вставка записи в кластере была дешёвой, не надо было бы синхронизировать счётчик между разными базами

В твому питанні вище написано частково. Реалізації uuid гарантують надвисоку ймовірність відсутності колізій для більшості кейсів. Відповідно при взаємодії двох систем їм не потрібно самим займатись питанням ймовірних колізій в ідентифікаторах, а перекласти це на реалізацію uuid.
Наприклад, якщо ти використовуєш авто-інкремент, а твоя система інтегрується з іншими, тобі треба зберігати ще якийсь "бізнес-ідентифікатор" для своїх сущностей, щоб при міграції в іншу БД не злетіли зв'язки між сущностями. З uuid такої проблеми нема.
Інший кейс - зовнішня система хоче інтегрувати якусь свою сущность в твою систему. З простими ід, вона не зможе просто по тому ж ідентифікатору засунути тобі цю сущность, бо можуть бути колізії з твоїми сущностями. Но якщо ви юзаєте uuid, то унікальність гарантує його реалізація і можна сміливо інтегрувати, не створюючи додаткових ключів

Я участвовал в нескольких проектах, на одном MSSQL на другом PostgreSQL, и в обоих использовался UUID как PK при том, что PK в обоих случаях был чисто внутренним для связи между таблицами и "бизнес идентификатором" всегда было другое поле

для mssql это вообще странно, потому что там pk по умолчанию кластеризованный

Різні кейси бувають.  Мб там звязок був не 1 до 1, або не хотіли палити uuid назовні, чи патерни спеціальні для бізнес-ключів були.
Суть в тому, що uuid дозволяє не робити додаткових ключів для подолання колізій

Ну і навіть без звязків, uuid полегшує міграції

если в таблицу не добавляются данные, это ещё может быть нормально
но если добавление есть - исползование uuid как pk в mssql это наидичайший случай, который просто убивает производительность вставки

Спасибо, теперь причины принятия таких решений стали понятнее)

И ещё один вопрос по другой теме, если можно.
Как вы реализовываете итерацию по большим коллекциям?
Например, у меня есть веб сервис. В некоторых запросах нужно итерироваться по коллекциям в 100к элементов. Это, естественно, делает сервис полностью неотзывчивым на неснолько секунд.
Видел примеры по асинхронному итерированию в how programming works. Было интресно, используете ли вы такое в проде

Спочатку треба задати питання, чи точно потрібна ця ітерація)
Асинхронна ітерація не поможе, якщо це http - кол і тобі треба згенерувати відповідь)
Асинхронна ітерація скоріше помагає для "бекграундних" процесів. Типу зібрати якусь статистику, виконати всі скедулери і тд

Но навіть з http колом, як мінімум це поможе сервісу відповісти на інші коли, не заставляючи їх чекати поки попередній виконається.

Спробую дати трохи більше контексту)
По http запиту треба згенерувати велику кількість entity та записати їх в БД. Віддавати їх назад клієнту не потрібно. Треба лише дати знати, що генерація завершена

Ну тоді асинхронна ітерація не дасть виграшу в контексті саме цього запиту. Він все одно довго висітиме.
Але дасть можливість цьому ж сервісу відповісти на інші запроси, не заставляючи їх чекати поки перший запит повістю виконається.
Но взагалі в таких випадках варто зробити ресьорч в сторону того, чи можна на плечі бази перекласти таку генерацію.
+ Мб порити в сторону того, щоб http запит не чекав на виконання, а наприклад по ws передавати асинхронно  повідомлення.

В даному випадку однією з вимог була мінімальна залежність від БД, тож використовувати її не вийде.
Те, що запит буде висіти, поки не проблема. Головне щоб сервіс продовжував відповідати на інші запити. Використання ws для нотифікацій було б непогано, але поки на фронті нема підтримки.
Я так розумію, у випадку з ws можна було б виконати генерацію в worker thread і відправити повідомлення клієнту коли все готово