Almost every schema contains a varchar(255) somewhere, usually for a name or an email address. Ask why 255 and the answer is usually that it is what everyone uses.
In many modern databases, that limit provides no storage or performance benefit at all. The column stores exactly the bytes present regardless of the declared maximum, and the limit is enforced as a check on write.
What changed in 2026
- The convention persisted despite being understood. Awareness that 255 is arbitrary did not stop it being copied into new schemas.
- Application-level validation became the norm. Length enforcement moved largely to application code and API schemas.
- Migration pain got documented. The cost of changing a length limit on a large table became better known.
- Unicode handling clarified. The distinction between character count and byte length continued to catch people out.
Where 255 comes from
It is not a modern constraint. It comes from an older storage format where the length of a variable-length field was recorded in a single byte, which can represent values up to 255. Exceeding that required two bytes, so 255 was the largest length with the cheapest length prefix.
That storage detail is irrelevant in most current databases. The number survived as convention long after the reason disappeared, which is why you see it applied to fields where it makes no sense — a country code capped at 255 characters, a URL capped at 255 when real URLs exceed it.
What the limit actually does
|
Varchar with limit |
Text / unlimited |
| Storage used |
Bytes present |
Bytes present |
| Performance |
Same |
Same |
| Enforces maximum length |
Yes |
No |
| Changing the limit |
May rewrite the table |
N/A |
| Catches oversized input |
Yes, at the database |
No |
This is engine-specific and worth verifying rather than assuming: some databases do store fixed-width or otherwise differentiate, and behaviour around increasing versus decreasing a limit differs. The general point holds for the widely-used engines — the limit is a constraint, not a storage decision.
Which reframes the question. It is not "which type is faster" but "do I want a length constraint enforced in the database, and if so, what value".
When a limit is worth having
There are genuine reasons to constrain length.
A real domain limit exists. A country code is two or three characters. A currency code is three. Encoding that in the schema documents it and catches errors.
Preventing accidental large inserts. A bug writing an entire document into a name field is caught immediately rather than discovered later.
A downstream system has a limit. If data flows to something that truncates at a length, enforcing it at the source is better than discovering truncation later.
Storage predictability. Where you need to bound a table's worst-case size.
What is not a good reason: because the previous schema did it, or because a limit feels tidier than no limit.
Choose the value from the actual domain, and choose generously — a name field limited to 50 characters excludes real names, and this is a recurring source of user-facing bugs. Where you cannot state a domain reason, an unlimited type is the honest choice.
The Unicode wrinkle
Length limits are typically expressed in characters, and storage is in bytes. A multi-byte character consumes more storage than a Latin character while counting as one toward the limit.
That matters when a downstream system limits bytes rather than characters. A field passing a 100-character check can exceed a 100-byte limit elsewhere, and the failure appears at the boundary rather than at the source.
Where a byte limit is what actually matters, enforce that specifically rather than relying on a character count.
Common mistakes
- 255 by default. Legacy artefact applied without thought.
- Assuming a limit improves performance. It generally does not.
- Limits too tight for real data. Names, addresses, and URLs exceed intuitive maximums.
- Confusing character and byte limits. Different constraints.
- Changing limits casually on large tables. May rewrite.
- No limit anywhere, including the application. Invites accidental large values.
FAQ
Should I use text everywhere?
Where no domain limit exists, that is a defensible default with application-level validation. Where a real limit exists, encoding it in the schema documents and enforces it.
Is changing a length limit expensive?
Depends on engine and direction — increasing is often cheap metadata, decreasing usually requires validating existing rows. Check before running it on a large table.
What about indexing?
Indexes on very long values are limited in most engines. If you index a column, that is a genuine reason to constrain its length.
Does this apply to all databases?
The general point does; the specifics vary. Some engines differentiate more than others, so verify for yours rather than generalising.
Where to go next
For enforcing rules beyond length, read check constraints. For handling large values, TOAST storage, and for changing column types safely, expand and contract migrations.