UUID vs ULID vs serial IDs: как выбрать правильный ID для вашей БД

Настоящая проблема: выбор ID, о котором не захочется жалеть позже

Выбор ID кажется скучным на первой неделе. Потом вы релизите, данные растут, и это «простое» решение проявляется повсюду: индексы, URL, логи, экспорты и интеграции.

Настоящий вопрос не «что лучше?», а «какую боль я хочу избежать позже?» ID сложно менять, потому что они копируются в другие таблицы, кэшируются клиентами и зависят в других системах.

Когда ID не соответствует развитию продукта, это обычно видно в нескольких местах:

• Вставки и запросы замедляются, потому что первичный индекс растёт в неблагоприятном порядке.
• Пагинация становится неудобной, когда сортировка по ID не соответствует времени создания.
• Миграции становятся рискованными, когда другие системы зависят от формата ID.
• Отладка занимает больше времени, если ID трудно читать или сравнивать.
• Импорты коллидят при слиянии данных из нескольких источников.

Всегда есть компромисс между удобством сейчас и гибкостью позже. Последовательные целые числа легко читать и они часто быстры, но раскрывают количество записей и усложняют слияния наборов данных. Случайные UUID хороши для уникальности между системами, но они тяжёлее для индексов и неудобны для человека. ULID стремится дать глобальную уникальность с приблизительным упорядочиванием по времени, но у него тоже есть компромиссы по хранению и инструментам.

Полезный способ подумать: для кого в основном этот ID?

Если ID в основном для людей (саппорт, отладка, опс), выигрывают короче и проще для чтения варианты. Если для машин (распределённые записи, оффлайн-клиенты, мульти-региональные системы), важнее глобальная уникальность и избежание коллизий.

Короткие определения простым языком

Когда люди спорят "UUID vs ULID vs serial IDs", на самом деле они выбирают, как каждой строке присвоить уникальную метку. Эта метка влияет на то, насколько легко вставлять, сортировать, сливать и перемещать данные позже.

Serial IDs (integer/bigint)

Serial ID — это счётчик. База даёт 1, затем 2, затем 3 и так далее (обычно как integer или bigint). Его легко читать, дешево хранить и обычно быстро, потому что новые строки попадают в конец индекса.

UUIDs

UUID — 128-битный идентификатор, который выглядит случайным, вроде 3f8a.... В большинстве настроек его можно генерировать без обращения к базе, поэтому разные системы могут создавать ID независимо. Компромисс в том, что вставки с "случайным" видом могут сильнее нагружать индексы и занимать больше места, чем простой bigint.

ULIDs

ULID тоже 128-битный, но спроектирован так, чтобы быть приблизительно упорядоченным по времени. Новые ULID обычно сортируются позже старых, оставаясь глобально уникальными. Вы часто получаете часть преимуществ "генерации в любом месте" как у UUID, но с более дружелюбным поведением при сортировке.

Короткое резюме:

• Serial: самый компактный и по умолчанию упорядочен.
• UUID: проще всего генерировать независимо, менее удобочитаем, часто случайный порядок.
• ULID: как UUID — независимая генерация, но приблизительный порядок по времени.

Serial ID распространены в приложениях с одной базой и внутренних инструментах. UUID появляются, когда данные создаются в нескольких сервисах, на устройствах или в регионах. ULID популярен, когда команда хочет распределённую генерацию ID, но заботится о порядке сортировки, пагинации или "последние сверху" запросах.

Индексация и производительность: что меняется на практике

Первичный ключ обычно поддерживается индексом (часто B-tree). Думайте об этом индексе как о сортированной телефонной книге: каждой новой строке нужно место в нужном порядке, чтобы выдача оставалась быстрой.

С случайными ID (классический UUIDv4) новые записи попадают по всему индексу. Это значит, что база трогает много страниц индекса, чаще делает split-ы страниц и выполняет дополнительные записи. Со временем вы получаете больший "хаос" в индексе: больше работы на вставку, больше пропусков кэша и большие индексы.

С преимущественно возрастающими ID (serial/bigint или ID, упорядоченные по времени, как многие ULID) база обычно может дописывать новые записи ближе к концу индекса. Это более кэш-дружелюбно: недавние страницы остаются горячими, и вставки идут ровнее при высоких нагрузках записи.

Размер ключа важен, потому что записи индекса не бесплатны:

• serial bigint: 8 байт
• UUID: 16 байт
• ULID: 16 байт при хранении в бинарном виде, значительно больше при хранении как 26-символьной строки

Больше ключи означают меньше записей на страницу индекса. Часто это приводит к более глубокой структуре индекса, большему числу прочитанных страниц на запрос и большему объёму RAM, необходимому для высокой скорости.

Если у вас есть таблица событий с постоянными вставками, первичный ключ в виде случайного UUID может начать ощущаться медленнее, чем bigint, даже если одиночные выборки по строке всё ещё быстрые. При ожидаемой высокой записи стоимость индексации — обычно первое заметное отличие.

Сортировка, пагинация и временной порядок

Если вы делали "Загрузить ещё" или бесконечную прокрутку, вы уже сталкивались с проблемой ID, которые плохо сортируются. ID "хорошо сортируется", когда порядок по нему даёт стабильную, осмысленную последовательность (часто по времени создания), чтобы пагинация была предсказуемой.

Со случайными ID (как UUIDv4) новые строки разбросаны. Сортировка по id не будет соответствовать времени, и курсорная пагинация вроде "дай элементы после этого id" становится ненадёжной. Обычно вы переходите на created_at, что нормально, но нужно делать аккуратно.

ULID спроектирован так, чтобы быть приблизительно упорядоченным по времени. Если вы сортируете по ULID (как по строке или в бинарном виде), новые элементы, как правило, идут позже старых. Это упрощает курсорную пагинацию, потому что курсором может быть последний увиденный ULID.

Что даёт ULID (и чего не даёт)

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

Но ULID не гарантирует идеального временного порядка, когда много ID генерируется в одну и ту же миллисекунду на разных машинах. Если вам нужен точный порядок, всё равно лучше полагаться на реальную метку времени.

Когда created_at всё ещё лучше

Сортировка по created_at часто безопаснее при бэфиллах, импортах исторических записей или когда нужно ясное разрешение совпадений.

Практический паттерн — сортировать по (created_at, id), где id выступает только тай-брейкером.

Шардирование позже: как избежать коллизий ID

Шардирование — это разделение одной базы на несколько меньших, чтобы каждая шарда хранила часть данных. Команды обычно делают это позже, когда одна база уже тяжело масштабируется или представляет риск единой точки отказа.

Выбор ID может сделать шардирование управляемым или болезненным.

С последовательными ID (автоинкремент serial или bigint) каждая шард будет счастливо генерировать 1, 2, 3.... Один и тот же ID может существовать на разных шардах. Когда придёт время сливать данные, перемещать строки или строить кросс-шардовые фичи, вы получите коллизии.

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

UUID и ULID уменьшают необходимость координации, потому что каждая шард может генерировать ID независимо с крайне низким риском дубликатов. Если вы думаете о разделении данных между базами, это один из сильнейших аргументов против чистых последовательностей.

Простой план, который работает (и его стоимость)

Популярный компромисс — добавить префикс шарда и использовать локальную последовательность на каждой шарде. Можно хранить как две колонки или упаковать в одно значение.

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

Задайте один вопрос рано: нужно ли вам когда-нибудь объединять данные из нескольких баз и сохранять стабильные ссылки? Если да, планируйте глобально уникальные ID с самого начала или выделите бюджет на миграцию позже.

Экспорт и импорт данных — где выбор ID становится реальным

Экспорт/импорт — это то место, где выбор ID перестаёт быть теорией. Как только вы клонируете прод в стейдж, восстанавливаете бэкап или сливаете данные из двух систем, вы узнаете, стабильны ли ваши ID и пригодны ли для переноса.

С serial (автоинкремент) вы обычно не сможете безопасно воспроизвести вставки в другую базу и сохранить ссылки, если не сохранить оригинальные номера. Если вы импортируете только подмножество строк (скажем, 200 клиентов и их заказы), нужно загружать таблицы в правильном порядке и сохранять первичные ключи. Любая перенумерация ломает внешние ключи.

UUID и ULID генерируются вне последовательности базы, поэтому их проще переносить между средами. Вы можете копировать строки, сохранять ID, и отношения останутся корректными. Это удобно при восстановлении бэкапов, частичных экспортов или слияниях.

Пример: экспортируете 50 аккаунтов из продакшена для отладки в стейдже. С UUID/ULID первичными ключами вы можете импортировать аккаунты и связанные строки (проекты, инвойсы, логи) и всё будет ссылаться на правильных родителей. С serial ID обычно придётся строить таблицу соответствий (old_id -> new_id) и переписывать внешние ключи при импорте.

Для массовых импортов базовые практики важнее типа ID:

• Убедитесь, что импортер по умолчанию не генерирует новые ID.
• Импортируйте родителей перед детьми и валидируйте внешние ключи после загрузки.
• Если вы используете serial ID, сбрасывайте sequence, иначе следующие вставки могут коллидить.
• Для ULID храните и экспортируйте их последовательно (строка vs бинарный формат).

Как выбрать за 10 минут

Можно принять разумное решение быстро, если сосредоточиться на том, что будет болеть позже.

1. Запишите основные риски на будущее. Конкретные события помогают: разделение на несколько баз, слияние данных из другой системы, оффлайн-записи, частые копии между окружениями.

2. Решите, должен ли порядок ID соответствовать времени. Если вы хотите "последние сверху" без дополнительных колонок, ULID (или другой time-sortable ID) хорош. Если устраивает сортировка по created_at, то подойдут UUID и serial.

3. Оцените объём записей и чувствительность индекса. При интенсивных вставках и сильно нагруженном первичном индексе BIGINT обычно легче для B-tree. Случайные UUID повышают churn.

4. Выберите дефолт и задокументируйте исключения. Держите всё просто: один дефолт для большинства таблиц и чёткое правило, когда отклоняться (часто: публичные ID vs внутренние ID).

5. Оставьте возможность поменять. Не кодируйте смысл в ID, решите где генерируются ID (БД или приложение) и держите ограничения явными.

Частые ошибки и ловушки

Самая большая ловушка — выбрать ID, потому что он популярен, и обнаружить, что он конфликтует с тем, как вы делаете запросы, масштабируетесь или делитесь данными. Большинство проблем проявляются через месяцы.

Типичные провалы:

• Использовать UUID везде, не проверив стоимость. UUIDv4 может раздуть индексы и ухудшить кэш-френдли поведение. Приложение продолжит работать, но вы заплатите замедленными записями и большими бэкапами.
• Полагаться на serial ID, а затем нуждаться в слиянии данных из нескольких систем, регионов или шардов. Коллизии появляются при импорте или синке, и быстрые фиксы вроде смещений и префиксов протекают в интеграциях.
• Предполагать, что ULID всё ускорит. Он помогает с порядком вставок и сортировкой по времени, но не решит медленные join'ы, отсутствующие индексы или широкие строки. Некоторые генераторы также не строго монотонны при большой конкуренции.
• Публично выставлять последовательные ID. Если в URL или API видны 123, 124, 125, люди могут угадывать соседние записи и сканировать систему.
• Менять тип ID в середине проекта без плана миграции. Внешние ключи, кэши, логи и внешние payload'ы могут продолжать ссылаться на старые ID долго после смены.

Сигналы тревоги, которые стоит решать рано:

• Вы ожидаете импорты от партнёров или регулярно сливаете данные между окружениями.
• Нужна пагинация в порядке времени без отдельного таймстемпа.
• Планируете делиться ID вне системы (URL, вебхуки, мобильные приложения).
• Не можете позволить себе простои ради крупной миграции ID.
• Ожидаете очень большие таблицы, где размер индекса и скорость записи важны.

Быстрый чек-лист перед финальным выбором

Реальность БД и запросов

Выберите один тип первичного ключа и придерживайтесь его для большинства таблиц. Смешение типов (bigint в одном месте, UUID в другом) усложняет джоины, API и миграции.

Оцените размер индекса на ожидаемой шкале. Шире ключи — больший первичный индекс и больше IO/RAM.

Решите, как будете пагинировать. Если пагинация по ID — убедитесь, что ID имеет предсказуемый порядок (или примите, что не имеет). Если пагинация по таймстемпу — индексируйте created_at и используйте его последовательно.

Чек-лист на будущее

Протестируйте план импорта на данных, похожих на прод. Убедитесь, что можно воссоздать записи без ломки внешних ключей и что повторы импортов не генерируют новые ID незаметно.

Запишите стратегию на случай коллизий. Кто генерирует ID (БД или приложение) и что происходит, если две системы создают записи оффлайн и позже синхронизируются?

Убедитесь, что публичные URL и логи не выдают паттерны, которые вам важны (количество записей, скорость создания, внутренние подсказки шардов). Если используете serial ID, предполагается, что люди могут угадывать соседние ID.

Реалистичный пример: от MVP до мультисистемных данных

Один основатель запускает простой CRM: контакты, сделки, заметки. Одна Postgres-база, одно веб-приложение, цель — быстро запустить.

Сначала serial bigint первичный ключ кажется идеальным. Вставки быстры, индексы аккуратны, и в логах легко читать.

Через год клиент просит квартальные экспорты для аудита, и основатель начинает импорт лидов из маркетингового инструмента. ID, которые были внутренними, теперь появляются в CSV, письмах и тикетах поддержки. Если две системы используют 1, 2, 3..., слияния становятся запутанными. Приходится добавлять колонки с источником, таблицы мэппинга или переписывать ID при импорте.

К второму году появляется мобильное приложение. Оно должно создавать записи оффлайн и потом синкать. Теперь нужны ID, которые клиент может генерировать без связи с базой, с низким риском коллизий при синке в разных окружениях.

Компромисс, который часто стареет лучше:

• Оставьте bigint первичный ключ для внутренних джоинов и эффективности хранения.
• Добавьте отдельный неизменяемый публичный ID (ULID или UUIDv7, если доступно) для шаринга, синка и импортов.
• Используйте публичный ID в файлах экспорта и как ключ для объединения данных между системами.

Практические следующие шаги для вашего проекта

Если вы колеблетесь между UUID, ULID и serial ID — решайте, исходя из того, как данные будут перемещаться и расти.

Короткие рекомендации для типичных случаев:

• Внутренний инструмент с одной базой и низким риском интеграций: используйте bigint serial первичный ключ.
• Публичное приложение с шарируемыми URL или клиентской генерацией: используйте UUID (трудно угадать, безопасно между системами).
• SaaS, который может потом шардироваться по тенанту или региону: используйте ULID (или UUIDv7), чтобы новые строки обычно попадали рядом в индексе.
• Много импортов от партнёров и оффлайн-устройств: избегайте чистых serial ID для внешних сущностей.

Часто смешение — лучшее решение. Используйте serial bigint для внутренних таблиц, которые никогда не покидают базу (таблицы джоинтов, фоновые задачи), и UUID/ULID для публичных сущностей: пользователей, организаций, счетов и всего, что может экспортироваться или ссылаться из другой системы.

Если вы строите на Koder.ai (koder.ai), стоит решить шаблон ID до того, как сгенерируете много таблиц и API. Режим планирования платформы и снимки/откат облегчают применение и проверку изменений схемы на раннем этапе, пока систему ещё можно безопасно изменить.