Чем text отличается от varchar(n) и char(n)? Что выбирать в проде?

text

Неограниченная строка переменной длины. Максимальный размер значения — 1 ГБ (ограничение одной строки таблицы). Нет накладных расходов на проверку длины при каждой вставке.

CREATE TABLE articles (
    id      bigserial PRIMARY KEY,
    title   text NOT NULL,
    body    text
);

INSERT INTO articles(title, body)
VALUES ('Hello', repeat('x', 100000)); -- без проблем

text, varchar(n) и char(n) в PostgreSQL

PostgreSQL хранит все три типа одинаково — через единый системный тип varlena в куче. Разница только в семантике и в проверках на уровне DDL.

varchar(n)

Синоним character varying(n). Хранение идентично text, но PostgreSQL добавляет CHECK на длину при вставке/обновлении. Без параметра n — то же самое, что text.

CREATE TABLE users (
    username varchar(50) NOT NULL -- триггерит ошибку при длине > 50
);

INSERT INTO users(username) VALUES (repeat('a', 51));
-- ERROR: value too long for type character varying(50)

Важно: изменение varchar(50) на varchar(100) — операция без блокировки таблицы (только изменение каталога). Уменьшение — требует проверки всех строк.

char(n)

Синоним character(n). Строка фиксированной длины: значения короче n дополняются пробелами справа при хранении. При сравнении пробелы игнорируются, что создаёт неочевидное поведение.

CREATE TABLE codes (
    country_code char(2)
);
INSERT INTO codes VALUES ('RU');
SELECT country_code = 'RU  ' FROM codes; -- TRUE (пробелы игнорируются)
SELECT length(country_code) FROM codes;  -- 2 (пробелы отсекаются при выводе)

Несмотря на фиксированную семантику, хранение char(n) в PostgreSQL всё равно переменное (varlena), поэтому экономии места нет — только семантика и накладные расходы на padding.

Что выбирать в продакшне

• Используйте text как основной тип для строк. Он наиболее гибкий и не создаёт ограничений, которые трудно изменить позже.
• Если нужно ограничение длины, добавьте CHECK-constraint — его проще изменить, чем тип колонки, и он не требует миграции данных при изменении лимита:

ALTER TABLE users
    ADD CONSTRAINT chk_username_len CHECK (char_length(username) <= 50);

• Используйте varchar(n) только если ограничение длины является частью бизнес-правила (например, ISO-коды стран).
• Избегайте char(n) почти во всех сценариях — семантика пробелов создаёт баги, а экономии места нет.

Производительность

Разницы в скорости между text и varchar(n) нет — ни для хранения, ни для индексирования. B-tree индекс работает одинаково на обоих типах. Для полнотекстового поиска используется тип tsvector независимо от базового строкового типа.

CREATE INDEX idx_users_username ON users (lower(username));
-- Работает одинаково для text и varchar

Подводные камни

• char(n) дополняет пробелами при хранении, и эти пробелы могут «утечь» через JSON-сериализацию или старые драйверы.
• Уменьшение varchar(100) до varchar(50) требует полного сканирования таблицы и блокировки — планируйте это в окно обслуживания.
• varchar без (n) идентичен text — многие разработчики не знают об этом и используют его «по привычке из MySQL».
• ORM-фреймворки (Django, SQLAlchemy) часто генерируют VARCHAR(255) по умолчанию — это артефакт MySQL-эпохи, в PostgreSQL это не нужно.
• При работе с TOAST: строки длиннее ~2 кБ автоматически выносятся в TOAST-таблицу — это происходит независимо от выбора типа.
• Функция length() считает символы, octet_length() — байты. Для многобайтовых символов (кириллица, CJK) эти значения различаются.
• Изменение типа колонки с text на varchar(n) через ALTER TABLE ... ALTER COLUMN ... TYPE перезапишет все строки таблицы — это долгая операция.

• Считать varchar быстрее text.
• Использовать char для произвольных строк.
• Зашивать случайные лимиты без бизнес-причины.

• Просит объяснить storage/performance в PostgreSQL.
• Уточняет, где нужен CHECK constraint.
• Проверяет пример с country_code.