CHAR vs VARCHAR vs TEXT in SQL: What's the Real Difference?

Why This Comes Up in Almost Every Interview

CHAR, VARCHAR, and TEXT all store character data, so it's tempting to treat them as interchangeable — but they differ in storage mechanics, performance characteristics, and behavior across databases, which is exactly why this is one of the most reliably-asked fundamentals questions. Getting a confident, precise answer here signals you understand storage internals, not just syntax.

CHAR(n): Fixed-Length

CHAR(n) always stores exactly n characters — shorter values are right-padded with spaces up to that length, and the padding is typically stripped automatically on read (behavior varies slightly by database).

CREATE TABLE countries (
  code CHAR(2) NOT NULL   -- always exactly 2 characters, e.g. 'US', 'IN', 'GB'
);

Best for: genuinely fixed-length codes — country codes, currency codes, fixed-format identifiers. Storage is predictable and, on some databases, marginally faster to compare since every value is the same byte length.

VARCHAR(n): Variable-Length, Bounded

VARCHAR(n) stores only the actual characters given, up to a maximum of n, plus a small length prefix (1-2 bytes depending on the database and length). No padding.

CREATE TABLE users (
  email VARCHAR(255) NOT NULL,
  username VARCHAR(50) NOT NULL
);

Best for: the vast majority of text columns — names, emails, titles, short descriptions. The explicit length limit both saves space (versus always-padded CHAR for variable-length data) and documents an intentional constraint at the schema level.

TEXT: Variable-Length, Unbounded

TEXT stores variable-length character data with no (or a very large, effectively irrelevant) length limit — but its underlying storage mechanics differ meaningfully by database.

• PostgreSQL — TEXT and VARCHAR(n) are stored identically internally; there's no performance difference between them. VARCHAR with a limit exists purely to enforce that limit at the schema level, not for any storage or speed advantage.
• MySQL — TEXT is stored differently from VARCHAR once content exceeds a certain size, potentially stored off-page, which can make some operations (particularly sorting or certain in-place updates) slower than an equivalent VARCHAR.
• SQL Server — the legacy TEXT type is deprecated in favor of VARCHAR(MAX)/NVARCHAR(MAX), which behave more predictably and support standard string functions that the old TEXT type didn't.

-- PostgreSQL: functionally identical performance to VARCHAR(500), TEXT is preferred by many teams for simplicity
CREATE TABLE articles (
  body TEXT NOT NULL
);

-- SQL Server: use VARCHAR(MAX), not the deprecated TEXT type
CREATE TABLE articles (
  body VARCHAR(MAX) NOT NULL
);

Side-by-Side Comparison

	CHAR(n)	VARCHAR(n)	TEXT
Length	Fixed, padded	Variable, up to n	Variable, effectively unbounded
Storage for short values	Wastes space (padding)	Efficient	Efficient
Enforces a max length at the schema level	Yes (exact length)	Yes	No (or a very high limit)
Typical use case	Fixed-format codes	Most text columns	Long-form, unbounded content

Does the Length Limit on VARCHAR Actually Matter for Performance?

On PostgreSQL, no — a shorter VARCHAR(n) declaration doesn't make storage or queries faster than a longer one or an unbounded TEXT, since the actual stored bytes only reflect the real content either way. On MySQL and SQL Server, the declared length can influence how much space is reserved in certain in-memory operations (like temporary tables during a sort), so an unnecessarily huge VARCHAR length can have a small real cost there. The length limit's main universal value across all three databases is as a documented, enforced business constraint — not a guaranteed performance lever.

Unicode Considerations

PostgreSQL and MySQL (with a UTF-8-family charset like utf8mb4) store Unicode text natively in VARCHAR/TEXT. SQL Server is the outlier: plain VARCHAR is single-byte and non-Unicode — for any text that might contain non-English characters, use NVARCHAR/NVARCHAR(MAX) instead, or names, addresses, and other international data can be silently corrupted or lost.

Common Mistakes

• Using CHAR for variable-length data — wastes storage on padding and requires trimming logic that's easy to forget, producing subtle comparison bugs ('US' = 'US ' behavior varies by database and context).
• Assuming VARCHAR(n) is always faster than TEXT — true on some databases, irrelevant on PostgreSQL specifically, where they're stored identically.
• Using plain VARCHAR on SQL Server for genuinely international data — silently mishandles non-Latin characters; NVARCHAR is required for real Unicode support there.
• Setting VARCHAR length limits arbitrarily large "just in case" instead of reflecting the actual real-world constraint (e.g. VARCHAR(9999) for a username) — this loses the documentation value of the limit entirely.

Common Interview Questions

1. What's the core difference between CHAR and VARCHAR? CHAR is fixed-length and pads shorter values with spaces; VARCHAR is variable-length and stores only the actual characters given, up to its declared max.
2. Is there a performance difference between VARCHAR(255) and TEXT? On PostgreSQL, no — they're stored identically. On MySQL and SQL Server, there can be meaningful differences depending on content size and the specific operation.
3. When would you actually choose CHAR over VARCHAR? Only for genuinely fixed-length values, like 2-letter country codes or fixed-format reference codes — almost never for names, emails, or any naturally variable-length text.
4. Why might VARCHAR silently corrupt non-English text on SQL Server? Plain VARCHAR on SQL Server is single-byte and non-Unicode by default; NVARCHAR is required to correctly store Unicode characters.

Frequently Asked Questions

Should I just always use TEXT to avoid thinking about length limits?

Not by default — an explicit, realistic VARCHAR length documents an intentional constraint your application already enforces, which is valuable schema-level self-documentation even when there's no performance difference (as on PostgreSQL). Reserve TEXT for content that's genuinely unbounded, like article bodies or free-form notes.

Does changing VARCHAR(50) to VARCHAR(255) later require a table rewrite?

On PostgreSQL, increasing a VARCHAR length is a fast, metadata-only change. On MySQL and SQL Server, it can require a table rewrite depending on the specific change and storage engine — always check your specific database's behavior before assuming it's instant on a large table.

Practice With Real Schema Decisions

Choosing the right string type is a small decision that compounds across an entire schema. Try it hands-on with our SQL practice questions, or work through full schema design in our case studies. For the complete picture across all data types, see our SQL data types cheat sheet.