Is there a performance difference between text and varchar(n) in PostgreSQL?
No. PostgreSQL stores text, varchar and varchar(n) the same way, and the length limit in varchar(n) is only a check. Use text unless a real business rule needs a maximum length.
Explain it simply
In some older databases, a column declared with a size reserves that much room, so choosing the size mattered. PostgreSQL does not work like that. A varchar(50) holding "Asha" uses the same space as a text column holding "Asha". The (50) is just a bouncer at the door: it rejects strings longer than 50 characters and does nothing else.
Because the limit is only a rule, text is not slower, and char(n) (which pads with spaces) is actually the one to avoid.
Example
CREATE TABLE students (
roll_no varchar(10) NOT NULL, -- a real rule: roll numbers are short
full_name text NOT NULL, -- no sensible fixed limit
CHECK (length(full_name) <= 200) -- easy to change later if needed
);
INSERT INTO students VALUES ('CS2024001234', 'Asha');
-- ERROR: value too long for type character varying(10)Raising a limit later with ALTER COLUMN ... TYPE varchar(20) is cheap in modern versions, but a CHECK constraint is the more flexible way to enforce length.
What to say in the interview
"There is no storage or speed difference between text and varchar(n) in PostgreSQL. The n is only a length check. I default to text and add a CHECK or a varchar(n) when the business really has a limit, like a 10-character roll number. I avoid char(n) because it pads with spaces."
Common mistakes
- Picking varchar(255) out of MySQL habit; in PostgreSQL it adds a limit without any benefit.
- Using char(n) and being surprised by trailing-space padding.