Реклама мешает? Идти Без рекламы Сегодня 

UUID против ULID против CUID Какой уникальный идентификатор вам следует использовать?

Опубликовано Апр 19, 2026

Каждая строка базы данных, каждый ресурс API, каждый распределённый событие требует идентификатора. Проблема не в генерации идентификатора — в выборе формата, который не подведёт вас через шесть месяцев, когда индексы в Postgres будут фрагментированы, а ссылки будут выглядеть как шум.

Здесь полный сравнение генератора UUID: UUID v4, UUID v7, ULID, CUID2 и Snowflake — что они такое, где они начинают работать нестабильно, и какой из них вы действительно должны использовать.

UUID v4: Безопасный стандарт (с одной большой проблемой)

UUID v4 — это 128 бит случайности, форматированный как 550e8400-e29b-41d4-a716-446655440000. Он понятен во всём мире, поддерживается во всех языках, всех базах данных и всех ОРМах на планете.

Вероятность коллизии практически равна нулю — вам нужно генерировать миллиарды UUID в секунду в течение 85 лет, чтобы столкнуться с вероятностью 50% одной коллизии. Это не является практической проблемой.

Проблема — это порядок. UUID v4 — это полностью случайный, что означает, что при вставке строк в таблицу с индексом по UUID записи распределяются по всему B-дереву. При масштабировании это приводит к разрывам страниц, фрагментации индексов и снижению производительности вставок. Если вы вставляете тысячи строк в секунду в таблицу MySQL или Postgres с первичным ключом UUID, вы это почувствуете.

UUID v4 также имеет 36 символов в виде строки — не URL-безопасный без кодирования и слишком объёмный по сравнению с альтернативами.

UUID v7: Улучшенный брат UUID v4

UUID v7 решает проблему порядка. Это временной UUID, где наиболее значимые биты кодируют временные метки в миллисекундах, а остальные — случайные. Результат: 01875f3a-7b2d-7f8e-a3d1-4b2e6c1a0f93.

Строки, вставляемые в порядке времени, остаются в индексе примерно последовательными. Это значительное преимущество для рабочих нагрузок с высокой частотой вставок. UUID v7 совместим с существующей инфраструктурой UUID — тот же формат, та же длина поля, те же ожидания по поддержке библиотек — при этом добавляется возможность сортировки.

Рекомендация RFC была завершена в 2022 году, и поддержка библиотек быстро растёт. Если вы уже используете UUID и не можете изменить схему, переход с v4 на v7 является низким риском и высоким возвратом.

ULID: Наиболее удобный вариант для разработчиков

ULID (универсально уникальный и лексикографически сортируемый идентификатор) кодирует 48-битный временной отсчёт и 80 бит случайности в 26 символов базы 32: 01ARZ3NDEKTSV4RRFFQ69G5FAV.

То, что делает его уникальным:

сортируется по умолчанию — лексикографическая сортировка соответствует временной сортировке
URL-безопасный — без дефисов, без специальных символов
Без учета регистра — избегает 0/O и 1/I неопределённости, исключая эти символы из алфавита
Компактный — 26 символов против 36 для строки UUID

ULID является наиболее практичным выбором для новых проектов, не имеющих устаревших ограничений. Он достаточно сортируем для большинства случаев использования, короток для ссылок и достаточно понятен, чтобы человек мог скопировать его без ошибок при вводе.

Одна оговорка: если вы генерируете несколько ULID в течение одного миллисекунда, порядок сортировки гарантируется в рамках одного процесса, но не между распределёнными узлами. Для большинства приложений это нормально.

CUID2: Создан для распределённых систем

CUID2 — это преемник CUID, пересмотренный с нуля с целью повышения безопасности и устойчивости к коллизиям в распределённых средах. Пример CUID2 выглядит так: clh3uj5ln0000qzrmn831mbhe.

Он использует хэш SHA-3 от комбинации временной метки, счётчика, отпечатка (идентификатор процесса + имя хоста) и случайных байтов. Отпечаток — ключевое отличие — он специально разработан для предотвращения коллизий при одновременной работе множества генераторов ID на разных серверах.

CUID2 — не сортируемый. Он приоритизирует устойчивость к коллизиям и непредсказуемость по сравнению с временной сортировкой. Если вы создаёте систему, где ID генерируются неуверенными клиентами или на множестве независимых узлов, и безопасность является важной, CUID2 стоит этого компромисса.

Для большинства бэкенд-API это избыточно.

Snowflake IDs: Высокая производительность, но вы находитесь в одиночестве

Snowflake IDs были изобретены в Twitter для генерации уникальных ID на миллионах в секунду в распределённой кластерной среде. Snowflake ID — это 64-битное целое число: временная метка (41 бит) + идентификатор центра (5 бит) + идентификатор машины (5 бит) + последовательность (12 бит).

Они сортируемы, компактны (вмещаются в BIGINT) и чрезвычайно быстрые. Discord, Instagram и многие высокопроизводительные системы используют этот паттерн.

Проблема: вам нужно управлять идентификаторами машин. Это означает использование сервиса координации (ZooKeeper, etcd, таблица в базе данных) для назначения уникальных идентификаторов машин каждому генератору ID. Если два узла имеют одинаковый идентификатор машины, возникают коллизии. Правильная настройка этого — не тривиальная задача, и поддержка требует операционных затрат.

Если вы не генерируете сотни тысяч ID в секунду, сложность не оправдана.

Сравнение

	Уникальный идентификатор версии 4	UUID v7	УЛИД	CUID2	Snowflake
Сортируемый	Нет	Да	Да	Нет	Да
URL-безопасный	Нет (дефисы)	Нет (дефисы)	Да	Да	Да (целое число)
Устойчивость к столкновениям	Очень высокий	Очень высокий	Высокий	Очень высокий	Высокий (с координацией)
Сложность	Никто	Никто	Никто	Низкий	Высокий
Типичное применение	Устаревшие системы, общий случай использования	Основные ключи в базе данных	API, ссылки, новые проекты	Распределённые/неуверенные клиенты	Высокопроизводительные платформы

Генерация каждого в Node.js

// UUID v4
import { v4 as uuidv4 } from 'uuid';
console.log(uuidv4()); // '9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d'

// UUID v7
import { v7 as uuidv7 } from 'uuid';
console.log(uuidv7()); // '01875f3a-7b2d-7000-8000-4b2e6c1a0f93'

// ULID
import { ulid } from 'ulid';
console.log(ulid()); // '01ARZ3NDEKTSV4RRFFQ69G5FAV'

// CUID2
import { createId } from '@paralleldrive/cuid2';
console.log(createId()); // 'clh3uj5ln0000qzrmn831mbhe'

// Snowflake (using @socialgouv/nextid for simplicity)
import Snowflake from '@socialgouv/nextid';
const snowflake = new Snowflake(1n); // machine ID = 1
console.log(snowflake.nextId().toString()); // '1641024000000000001'

Вы можете протестировать генерацию UUID напрямую с помощью IO Tools генератора UUID — он поддерживает UUID v1 по v7 и массовую генерацию без установки дополнительных компонентов.

Какой из них использовать?

Вот реальное рекомендация, а не «зависит от ситуации»:

Новый проект, без устаревших ограничений: Используйте УЛИД. Сортируемый, URL-безопасный, компактный. Это лучший стандарт по умолчанию.
Уже используете UUID, нужна улучшенная производительность базы данных: Перейдите на UUID v7. Простой переход, огромная выгода по индексам.
ID генерируются клиентами или в распределённых неуверенных узлах: Используйте CUID2. Отпечаток делает устойчивость к коллизиям надёжной даже в агрессивных условиях.
Высокопроизводительная платформа (более 100 000 ID в секунду), готовы управлять идентификаторами машин: Используйте Snowflake. В противном случае, не стоит беспокоиться.
UUID v4: Только если вы поддерживаете устаревший код и не можете изменить формат. Прекратите использовать его для новых таблиц.

Эра умолчательного выбора UUID v4 для всего исчезла. ULID — новый стандарт по умолчанию для большинства случаев использования, а UUID v7 — правильный путь обновления, если вы уже находитесь в мире UUID. Выберите один и двигайтесь дальше.