UUID vs bigint в PostgreSQL: сравнение размера индексов, порядка сортировки, готовности к шардингу и того, как ID проходят через API, веб и мобильные приложения.
Каждая строка в таблице PostgreSQL нуждается в надёжном способе снова её найти. Именно этим занимается идентификатор: он уникально обозначает запись, обычно служит первичным ключом и становится связующим звеном для отношений. Другие таблицы хранят его как внешний ключ, запросы джойнят по нему, а приложения передают его как «этот клиент», «этот счёт» или «этот тикет поддержки».
Поскольку ID в итоге появляются повсюду, выбор — это не просто внутренняя база данных. Он проявляется позже в размере индексов, шаблонах записи, скорости запросов, процентах попадания в кэш и даже в продуктовой работе: аналитике, импортах и отладке. Он также влияет на то, что вы показываете в URL и API, и насколько мобильному приложению удобно хранить и синхронизировать данные.
Большинство команд сравнивают UUID vs bigint в PostgreSQL. Проще говоря, вы выбираете между:
Ни один вариант не выигрывает во всём. Bigint обычно компактнее и лучше подходит для индексов и сортировки. UUID хорошо подходят, когда нужны глобально уникальные ID между системами, когда вы хотите безопасные публичные идентификаторы или ожидаете создание данных в многих местах (несколько сервисов, оффлайн‑мобильные клиенты или будущий шардинг).
Полезное правило: решайте, основываясь на том, как ваши данные будут создаваться и шариться, а не только на том, как они хранятся сегодня.
Когда люди сравнивают UUID vs bigint в PostgreSQL, они выбирают между двумя способами задавать имена строк: маленьким числом‑счётчиком или более длинным глобально уникальным значением.
bigint — это 64‑битный целочисленный тип. В PostgreSQL его обычно создают через identity column (или старый паттерн serial). База хранит последовательность и отдаёт следующее число при вставке строки. Это значит, что ID будут 1, 2, 3, 4... — просто, читаемо и удобно в инструментах и отчётах.
UUID (Universally Unique Identifier) — 128 бит. Обычно его представляют как 36 символов с дефисами, например 550e8400-e29b-41d4-a716-446655440000. Распространённые варианты:
Хранилище — одно из первых практических различий: bigint занимает 8 байт, а UUID — 16 байт. Эта разница проявляется в индексах и может повлиять на попадания в кэш (в памяти разместится меньше записей индексa).
Также подумайте, где ID появляются за пределами базы. Bigint короткие в URL и их удобно читать в логах или тикетах поддержки. UUID длиннее и неудобнее печатать, но их сложнее угадать и их безопасно генерировать на клиентах при необходимости.
Самое большое практическое отличие между bigint и UUID — это размер. Bigint — 8 байт; UUID — 16 байт. Это звучит незначительно, пока не вспомнить, что индексы дублируют ваши ID много раз.
Ваш первичный индекс должен оставаться «горячим» в памяти, чтобы работать быстро. Меньший индекс значит, что больше его частей помещается в shared buffers и кеш CPU, поэтому поиска и джойны требуют меньше чтений с диска. С UUID первичный индекс обычно заметно больше при том же количестве строк.
Множитель — это вторичные индексы. В B‑tree индексах PostgreSQL каждая запись вторичного индекса также хранит значение первичного ключа (чтобы найти строку). Значит, широкие ID увеличивают не только первичный индекс, но и каждый дополнительный индекс. Если у вас три вторичных индекса, дополнительные 8 байт от UUID фактически появляются в четырёх местах.
Внешние ключи и таблицы связей тоже это чувствуют. Любая таблица, ссылающаяся на ваш ID, хранит это значение в своих строках и индексах. Таблица many‑to‑many может состоять в основном из двух внешних ключей и небольшого накладного объёма, поэтому удвоение ширины ключа сильно меняет её размер.
На практике:
Если идентификатор пользователя встречается в users, orders, order_items и audit_log, это значение хранится и индексируется во всех этих таблицах. Выбор более широкого ID — это столько же решение о хранении, сколько решение об идентификаторе.
Большинство первичных ключей PostgreSQL лежат в B‑tree индексе. B‑tree лучше работает, когда новые строки добавляются ближе к концу индекса, так как база может дописывать записи без большой перестановки.
С bigint через identity/sequence новые ID растут со временем. Вставки обычно попадают в правую часть индекса, страницы остаются плотно заполнены, кэш тёплый, и PostgreSQL выполняет меньше дополнительной работы.
Это важно даже если вы никогда не делаете ORDER BY id. Путь записи всё равно должен поместить ключ в индекс в отсортированном порядке.
Случайный UUID (обычно UUIDv4) рассеивает вставки по всему индексу. Это повышает вероятность page split, когда PostgreSQL выделяет новые страницы индекса и перемещает записи, чтобы освободить место. В результате — большая запись на диск: больше байт индекса пишется, больше WAL генерируется и часто больше фоновой работы позже (vacuum и управление bloat).
UUID, упорядоченные по времени, меняют ситуацию. UUID, которые в основном увеличиваются со временем (например, UUIDv7 или подобные схемы), возвращают большую часть локальности, оставаясь при этом 16 байт и выглядя как UUID в API.
Вы почувствуете эти различия особенно при высоких скоростях вставок, больших таблицах, которые не помещаются в память, и при наличии нескольких вторичных индексов. Если вам важны резкие пики задержки записи из‑за page split, избегайте полностью случайных ID в горячих таблицах.
Пример: насыщенная событиями таблица, принимающая логи с мобильных приложений в течение дня, обычно будет работать плавнее с последовательными ключами или упорядоченными UUID, чем с полностью случайными UUID.
В большинстве реальных случаев нет простой формулы «UUID медленнее» или «bigint быстрее». Важно то, к каким страницам базы данных нужно обратиться, чтобы ответить на ваш запрос.
Планы запросов в основном зависят от того, может ли движок использовать индекс для фильтров, делать быстрые джойны по ключу и насколько физически упорядочена таблица (или близка к упорядоченности), чтобы чтения по диапазону были дешёвыми. С bigint новые строки попадают примерно в порядке увеличения, поэтому первичный индекс остаётся компактным и локалити‑дружественным. С случайными UUID вставки рассеиваются, что может создавать больше page split и менее аккуратный порядок на диске.
Чтения — это то, что команды замечают в первую очередь. Более крупные ключи — более крупные индексы, а большие индексы — меньше полезных страниц в RAM. Это снижает попадания в кэш и увеличивает IO, особенно на экранах с многими джойнами вроде «список заказов с данными клиентов». Если ваш рабочий набор не помещается в память, схема с UUID может довести вас до этого предела раньше.
Записи тоже меняются. Случайные UUID‑вставки увеличивают «шум» в индексе, что добавляет давления на autovacuum и может проявляться как всплески латентности в пиковые периоды.
Если вы бенчмарктите UUID vs bigint в PostgreSQL, делайте честный тест: одинаковая схема, одинаковые индексы, одинаковый fillfactor и достаточно строк, чтобы превысить RAM (не 10k). Измеряйте p95 латентность и IO, тестируйте с тёплым и холодным кэшем.
Если вы строите приложения в AppMaster на PostgreSQL, это часто проявляется как более медленные страницы списка и большая нагрузка на базу задолго до того, как появится «проблема CPU».
Если ваши ID покидают базу и появляются в URL, ответах API, тикетах поддержки и мобильных экранах, выбор влияет и на безопасность, и на удобство.
Bigint удобны для людей. Они короткие, их легко продиктовать по телефону, и команда поддержки быстро видит паттерны вроде «все упавшие заказы рядом с 9,200,000». Это ускоряет отладку, особенно когда вы работаете с логами или скриншотами клиентов.
UUID полезны, когда вы открываете идентификаторы публично. UUID трудно угадать, поэтому простое сканирование /users/1, /users/2 не сработает. Они также затрудняют внешним наблюдателям оценить количество записей.
Ловушка — думать, что «неугадываемый» = «безопасный». Если проверки авторизации слабые, предсказуемые bigint можно быстро злоупотребить, но UUID всё равно могут быть украдены из общей ссылки, утекшего лога или кэшированного ответа API. Безопасность должна исходить из проверок прав, а не из сокрытия ID.
Практический подход:
Пример: портал клиента показывает ID счёта. Если счёта используют bigint, а API только проверяет «invoice exists», кто‑то может перебирать номера и скачивать чужие счета. Исправьте проверку сначала. Затем решите, уменьшают ли UUID риск и нагрузку поддержки.
В платформах типа AppMaster, где ID текут через сгенерированные API и мобильные приложения, самый безопасный дефолт — это согласованная авторизация плюс формат ID, который клиенты могут надёжно обработать.
Тип данных в базе не остаётся там. Он просачивается через все границы: URL, JSON‑поля, локальное хранение, логи и аналитику.
Если вы когда‑то поменяете тип ID, ломка редко бывает «простой миграцией». Внешние ссылки, внешние таблицы и интеграции всё ещё будут ожидать старого формата. Даже простой GET /users/123 становится грязным, когда ID превращается в 36‑символьный UUID. Придётся обновлять кэши, очереди сообщений и все места, где ID сохранялись как числа.
Для API главное — формат и валидация. Bigint идут как числа, но в некоторых системах и языках есть риск потери точности для очень больших значений, если их парсить как float. UUID идут как строки, что безопаснее для парсинга, но требует строгой валидации, чтобы «почти UUID» не попадали в логи и базу.
На мобильных клиентах ID постоянно сериализуются и сохраняются: JSON‑ответы, локальная SQLite и оффлайн‑очереди. Числовые ID меньше по размеру, но строковые UUID часто удобнее как «непрозрачные» токены. Хуже всего — непоследовательность: один слой хранит как число, другой как текст, и сравнения или джойны становятся ломкими.
Несколько правил, чтобы избежать проблем:
Если вы строите веб и мобильные клиенты на генераторе (например, AppMaster), стабильный контракт ID имеет ещё большее значение, потому что он становится частью каждой сгенерированной модели и запроса.
«Готовность к шардингу» в основном значит, что вы можете создавать ID в нескольких местах без нарушения уникальности и сможете переносить данные между узлами позднее без переписывания всех внешних ключей.
UUID популярны в мульти‑региональных и multi‑writer системах, потому что любой узел может сгенерировать уникальный ID без обращения к центральной последовательности. Это снижает координацию и упрощает приём записей в разных регионах и последующее слияние данных.
Bigint тоже может работать, но требует плана. Обычные подходы: выделять числовые диапазоны на шард (шард 1 использует 1–1B, шард 2 — 1B–2B), запускать отдельные последовательности с префиксом шарда или использовать генераторы типа Snowflake (бит времени плюс бит машины/шарда). Они могут держать индексы уже, чем UUID, и сохранять некоторую упорядоченность, но добавляют операционные правила.
Ежедневные компромиссы:
Для многих команд «готовность к шардингу» означает скорее «готовность к миграции». Если сегодня у вас одна база, выберите ID, который упрощает текущую работу. Если вы уже строите несколько писателей (например, через сгенерированные API и мобильные клиенты в AppMaster), решите заранее, как ID будут создаваться и валидироваться между сервисами.
Начните с того, чтобы честно описать форму вашего приложения. Одиночная база PostgreSQL в одном регионе имеет другие потребности, чем multi‑tenant система, окружение, которое позже разделится по регионам, или оффлайн‑первичное мобильное приложение, которое должно создавать записи оффлайн и синхронизировать их позже.
Далее честно ответьте, где будут появляться ID. Если идентификаторы остаются внутри бэкенда (джобы, внутренние инструменты, админка), простота часто выигрывает. Если ID появляются в URL, логах, экспортируемых данных или глубоких ссылках мобильного приложения, предсказуемость и приватность становятся важнее.
Используйте упорядочивание как критерий, а не думайте о нём потом. Если вам нужны «новые сверху» ленты, стабильная пагинация или удобные для просмотра аудиторские следы, последовательные ID (или временно‑упорядоченные ID) сокращают неожиданности. Если порядок не привязан к первичному ключу, вы можете держать PK и сортировать по timestamp отдельно.
Практический поток принятия решения:
Пример: если мобильное приложение создаёт «черновые заказы» оффлайн, UUID позволяет устройству генерировать ID безопасно до отправки на сервер. В таких инструментах, как AppMaster, это удобно, потому что один формат ID течёт от базы к API и в нативные приложения без специальных исключений.
Большинство дискуссий об ID заходят не туда, потому что команды выбирают тип ID по одной причине, а затем удивляются побочным эффектам.
Одна частая ошибка — использовать полностью случайные UUID в горячей таблице и потом удивляться пиковым вставкам. Случайные значения рассеивают новые строки по индексу, что приводит к большему количеству page split и дополнительной нагрузке при высокой записи. Если таблица «горячая», продумайте локальность вставок.
Ещё одна проблема — смешение типов ID между сервисами и клиентами. Например, один сервис использует bigint, другой — UUID, и API в итоге возвращает и числовые, и строковые ID. Это ведёт к тонким багам: JSON‑парсеры теряют точность больших чисел, мобильный код в одном экране считает ID числом, в другом — строкой, или ключи кэша не совпадают.
Третья ловушка — считать «неугадываемые ID» мерой безопасности. Даже с UUID нужны корректные проверки доступа.
И, наконец, команды меняют тип ID поздно без плана. Сложность — не в одном столбце, а во всём вокруг: внешние ключи, таблицы связей, URL, аналитика, глубокие ссылки и состояние на клиентах.
Чтобы избежать боли:
Если вы разрабатываете с генерацией кода, как в AppMaster, консистентность ещё важнее, потому что один тип ID проходит от схемы базы к сгенерированному бэкенду и в веб и мобильные клиенты.
Если застряли, не начинайте с теории. Начните с того, каким будет ваш продукт через год и в каких местах этот ID будет использоваться.
Спросите себя:
После ответов проверьте инфраструктуру: для bigint убедитесь, что есть чёткий план генерации ID везде (особенно в локальной разработке и при импортах). Для UUID убедитесь, что контракты API и модели клиентов обрабатывают строковые ID последовательно и команда комфортно читает и сравнивает их.
Быстрый реальный тест: если мобильное приложение должно создать заказ оффлайн и синхронизировать позже — UUID часто упрощают работу. Если приложение в основном онлайн и вам нужны простые компактные индексы — bigint обычно легче.
Если вы работаете в AppMaster, решите рано, потому что соглашение об ID проходит через модель PostgreSQL, сгенерированные API и веб/нативные клиенты.
Небольшая компания имеет внутренний инструмент операций, портал клиента и мобильное приложение для полевых сотрудников. Все три используют одну PostgreSQL через единое API. Новые записи создаются постоянно: тикеты, фото, обновления статуса и счета.
С bigint API‑пейлоады компактны и читаемы:
{ "ticket_id": 4821931, "customer_id": 91244 }
Пагинация ощущается естественно: ?after_id=4821931&limit=50. Сортировка по id обычно соответствует времени создания, поэтому «последние тикеты» быстры и предсказуемы. Отладка проще: поддержка может попросить «тикет 4821931» и большинство людей напечатают его без ошибок.
С UUID полезная нагрузка становится длиннее:
{ "ticket_id": "3f9b3c0a-7b9c-4bf0-9f9b-2a1b3c5d1d2e" }
Если используется случайный UUID v4, вставки попадают по всему индексу. Это может означать больше индексационного шума и чуть более громоздкую отладку (копировать/вставлять — обычное дело). Пагинация часто смещается в сторону курсорных токенов вместо простого «after id». Если использовать временно‑упорядоченные UUID, вы сохраните поведение «новые сверху», но избежите угадываемых публичных ID.
На практике команды обычно замечают четыре вещи:
Большинство команд застревают, потому что ищут идеальный ответ. Он не нужен. Нужен дефолт, который подходит продукту сегодня, и быстрый способ доказать, что это не навредит в будущем.
Правила для стандартизации:
Перед финалом запустите маленький spike. Создайте таблицу с реальным размером строки, вставьте 1–5 миллионов записей и сравните (1) размер индексов, (2) время вставки и (3) несколько типичных запросов с первичным ключом и парой вторичных индексов. Делайте это на вашем реальном железе и с реальной формой данных.
Если боитесь изменений позже, планируйте миграцию по‑умному:
Если вы строите на AppMaster (appmaster.io), стоит решить рано: соглашение об ID проходит через модель PostgreSQL, сгенерированные API и веб/нативные клиенты. Тип важен, но консистентность важнее, когда у вас реальные пользователи и несколько клиентов.
Стоит ли использовать bigint или UUID как первичный ключ в PostgreSQL?По умолчанию выбирайте bigint, когда у вас один экземпляр PostgreSQL, большинство записей создаются на сервере, и вам важны компактные индексы и предсказуемое поведение вставок. Выбирайте UUID, когда идентификаторы должны создаваться в разных местах (несколько сервисов, оффлайн‑мобильные приложения, будущее шардинг) или когда вы не хотите, чтобы публичные ID было легко угадывать.
Почему UUID так сильно увеличивают размер индексов и хранилища?Потому что значение идентификатора копируется во множество мест: первичный индекс, каждая вторичная индексная запись (чтобы найти строку), столбцы внешнего ключа в других таблицах и таблицы связей. UUID занимает 16 байт против 8 байт у bigint, поэтому разница по размеру умножается по всей схеме и может снижать коэффициент попаданий в кэш.
Ускорят ли UUID вставки по сравнению с bigint?На «горячих» таблицах с частыми вставками — да. Случайные UUID (например, v4) рассредоточивают вставки по дереву B‑tree, что увеличивает количество page split, индексный шум и нагрузку на WAL. Если вы хотите UUID и при этом гладкие записи, используйте стратегию с упорядоченными по времени UUID.
Заметны ли замедления чтения с UUID?Это чаще проявляется как рост IO, а не как нагрузка на CPU. Более широкие ключи — более крупные индексы, и меньше страниц помещается в память, поэтому джойны и поиска могут вызывать больше чтений. Разница заметнее на больших таблицах, при тяжёлых джойнах и когда рабочий набор не помещается в RAM.
Являются ли UUID безопаснее, чем bigint в публичных API?UUID уменьшают простоту угадывания вроде /users/1, но они не заменяют авторизацию. Если проверки прав реализованы неверно, UUID всё равно могут быть украдены из ссылок или логов и использованы. Считайте UUID удобством для публичных идентификаторов, а безопасность обеспечивайте строгими проверками доступа.
Как лучше представлять идентификаторы в JSON API?Выберите одно каноническое представление и придерживайтесь его. Практичный вариант — передавать ID как строки в API (даже если в базе используется bigint), чтобы избежать проблем с точностью на клиентах. Что бы вы ни выбрали, делайте это консистентно в вебе, мобильных клиентах, логах и кэше.
Вызывают ли bigint проблемы в JavaScript или мобильных приложениях?bigint может создавать проблемы в некоторых клиентах, если он парсится как число с плавающей точкой и теряет точность при больших значениях. UUID избегают этой проблемы, потому что передаются как строки, но требуют строгой валидации. Самое безопасное — консистентность: один тип везде и чёткая валидация на краю API.
Что выбрать, если есть вероятность шардинга или мульти‑региона в будущем?UUID — более простой путь, потому что любой узел может создать уникальный идентификатор без обращения к центральной последовательности. Bigint тоже возможен, но требует правил (диапазоны на шард, префиксы, Snowflake‑подобный генератор) и дисциплины. Если хотите самый простой распределённый сценарий, выберите UUID (желательно упорядоченные по времени).
Насколько болезненно мигрировать с bigint на UUID (или обратно)?Смена типа первичного ключа затрагивает намного больше, чем один столбец: внешние ключи, таблицы связей, контракты API, хранимые состояния клиентов, события аналитики и интеграции. При планировании миграции делайте поэтапный подход: добавьте новый столбец, dual‑write для новых записей, бэктфил в партиях, обновите клиентов и только затем удаляйте старый ключ.
Можно ли использовать оба подхода: bigint внутри и UUID снаружи?Да. Храните внутренний компактный bigint для эффективности базы, а для публичных URL и внешних API заводите отдельный публичный UUID или токен. Так вы сохраняете компактные индексы и удобство отладки внутри, а на внешней стороне избегаете простой переборки ID. Главное — заранее определить, какой из них будет «публичным», и не смешивать два подхода бессистемно.
27 янв. 2026 г.
1 мин
26 янв. 2026 г.1 мин
21 янв. 2026 г.1 минЭкспериментируйте с AppMaster с бесплатной подпиской.
Как только вы будете готовы, вы сможете выбрать подходящий платный план.
