Базовые типы: деньги, текст, время, идентичность

Семейства типов: выбирай по смыслу

Postgres группирует встроенные типы в несколько семейств. Хорошее моделирование начинается с того, что каждую колонку сопоставляют семейству, отвечающему тому, что значение означает, а не тому, что проще набрать. Прежде чем создать следующую колонку, спроси себя: что это значение представляет — счётчик, момент времени, идентификатор — и делает ли выбранный тип этот смысл обязательным или просто подразумевает его?

Числа: никогда не храни деньги во float

integer — 4-байтовое целое со знаком (до ~2,1 млрд); bigint — 8 байт (до ~9,2 квинтиллиона). Используй bigint для всего, что считает события, строки или деньги-в-центах на масштабе — переполнение integer на первичном ключе — это реальный инцидент.

Жёсткое правило: деньги — это numeric или целые центы, никогда real/double precision. numeric — точная десятичная дробь: хранит заданные цифры и считает в десятичной системе, так что 0.10 + 0.20 ровно 0.30. Плавающая точка хранит двоичное приближение, а у 0.1 нет точного двоичного представления. Посмотри сам:

SELECT 0.1::float8 + 0.2::float8 AS float_sum,   -- 0.30000000000000004
       0.1::numeric + 0.2::numeric AS exact_sum;  -- 0.3

-- денежная колонка как надо:
CREATE TABLE orders (
  id          bigint PRIMARY KEY,
  total_cents bigint NOT NULL,        -- целые центы: быстро, точно, без аргумента scale
  tax         numeric(12, 2) NOT NULL -- или numeric с фиксированной точностью
);

numeric(12, 2) значит до 12 значащих цифр, из них 2 после запятой. Компромисс: арифметика numeric эмулируется программно и примерно в 10–100× медленнее нативной float-математики CPU, а каждое значение переменной ширины. Для денег это не проблема — правит корректность, — но не тяни numeric в горячую научную агрегацию, где крошечная погрешность округления допустима.

Текст: text и varchar(n) одинаковы по скорости

Стойкий миф: varchar(50) быстрее или меньше, чем text. В Postgres это не так. Все три — text, varchar(n) и varchar — делят одинаковое хранение и одни и те же операторы. Единственное, что varchar(n) добавляет, — это check-ограничение на длину: Postgres проверяет, что каждая запись не длиннее n символов, и отвергает более длинные с ошибкой.

Значит, выбор только в том, нужно ли тебе это ограничение. Лимит длины, отражающий реальное бизнес-правило (2-символьный код страны), — хорошее моделирование; произвольный varchar(255), скопированный из MySQL-туториала, — шум. Postgres-нативная привычка — text плюс явный CHECK, когда граница действительно нужна: яснее, и можно менять границу без неуклюжего alter типа.

CREATE TABLE users (
  id        bigint PRIMARY KEY,
  email     text NOT NULL,
  country   text NOT NULL CHECK (char_length(country) = 2)  -- реальное правило, явно
);

Время: timestamptz, всегда

Это самая частая ошибка моделирования, и тихая. Есть два типа timestamp:

• timestamp (он же timestamp without time zone) хранит значение по настенным часам и выбрасывает зону. Это наивное «2026-06-02 14:00» без привязки к реальному моменту.
• timestamptz (timestamp with time zone) хранит абсолютный момент. На входе Postgres конвертирует ввод в UTC и хранит его; на выходе рендерит в зоне сессии TimeZone. Он не хранит исходную зону — он хранит момент.

timestamptz — правильный дефолт практически для любого события, строки лога, created_at и дедлайна. С простым timestamp два сервера в разных зонах, вставляя «сейчас», пишут разные абсолютные моменты, которые сравниваются неверно, и истину потом не восстановить. Храни момент; пусть приложение решает, как его показать.

CREATE TABLE events (
  id          bigint PRIMARY KEY,
  occurred_at timestamptz NOT NULL DEFAULT now(),  -- абсолютный момент в UTC
  kind        text NOT NULL
);

-- date — для календарных дат без времени; interval — для интервала:
SELECT occurred_at::date AS day,
       now() - occurred_at AS age      -- age это interval
FROM events;

Используй date для настоящих календарных дат (день рождения, день биллинга) и interval для промежутков («7 дней», «90 минут») — вычитание двух timestamptz даёт interval.

UUID: случайный v4 против упорядоченного по времени v7

uuid — 16-байтовый тип для ключей, генерируемых без центральной последовательности: полезен между шардами или до того, как строка дойдёт до базы. Версия важна для локальности индекса:

• v4 полностью случаен. Каждая вставка попадает в случайное место в B-tree первичного ключа, так что у индекса нет горячего хвоста — записи разбросаны по страницам, hit rate кеша падает, а индекс фрагментируется и пухнет под тяжёлой нагрузкой вставок.
• v7 встраивает миллисекундную метку времени в старшие биты, так что значения примерно упорядочены по времени. Вставки приклеиваются к правому краю B-tree, как serial, держа индекс компактным и дружелюбным к кешу.

Для таблицы с высоким темпом вставок v7 (или bigint identity) пишется ощутимо быстрее и куда меньше склонен к bloat индекса, чем v4. Тянись к случайному v4 только когда неугадываемость самого ключа — требование.

Касты: будь явным на границе

Postgres неявно кастует в одних контекстах и отказывается в других; опора на неявные касты — это как получить неожиданные планы (индекс пропущен, потому что сравнение вынудило каст) или ошибки времени выполнения. Делай касты явными через ::type или CAST(x AS type) на краях запроса, особенно при сравнении колонки с литералом другого типа.

SELECT '42'::int + 1                 AS to_int,      -- 43
       '2026-06-02'::date            AS to_date,
       total_cents::numeric / 100    AS dollars      -- центы → значение для показа
FROM orders;