CHAR(n) in SQL stores a string of up to characters, padded with trailing spaces to fill the declared length. The padding is invisible at the application level — most engines strip trailing spaces on comparison, though there are dialect-specific exceptions — and gives CHAR a predictable per-row footprint, which can help with storage layout on tables of truly fixed-width values.
“CHAR is always faster than VARCHAR” is a folk claim that doesn’t survive contact with modern storage engines and multi-byte character sets. Under a variable-width encoding like UTF-8, CHAR(n) in MySQL reserves up to characters’ worth of bytes (often or ), so the on-disk size isn’t even constant in bytes. In practice the performance difference between CHAR and VARCHAR for short strings is small enough that the correctness of the type (does the value have a genuinely fixed length, or not?) matters more than the supposed efficiency.
CHAR is the right choice for truly fixed-length data:
- Two-letter country codes (
CHAR(2)). - Phone-number formats with a known length.
- Status codes that are always the same width.
- ISO currency codes (
CHAR(3)).
If the length varies — names, emails, addresses, anything where a value might be a few characters or a few dozen — VARCHAR is the right type. Storing variable-length data in CHAR wastes space on padding; storing fixed-length data in VARCHAR wastes space on length headers and adds slight access overhead.
The maximum for CHAR is 255 in MySQL, 10485760 in PostgreSQL (CHARACTER(n)), 8000 in SQL Server. In SQLite, CHAR(n) is accepted as a type declaration but is treated as TEXT with no length enforcement at all — manifest typing means the column accepts any string.
CHAR is part of the family of SQL string types, alongside VARCHAR (variable length up to a maximum) and ENUM (MySQL-specific, constrained to a fixed list).