Great question! Here’s the reason behind storing emails as VARCHAR(255) instead of VARCHAR(320), even though RFC 5321 allows up to 320 characters:
1. Practical Database Limits
Older databases/software (especially MySQL) often had limitations where the maximum length of an indexed VARCHAR field was 255 characters. Using VARCHAR(255) became a convention because it was the largest size that could be easily indexed and supported by most systems without issues.
2. Indexing Considerations
Indexing longer fields can significantly impact database performance. Since most email implementations never use addresses that even approach 255 characters, the added space (and performance penalty) of using VARCHAR(320) isn’t usually justified.
3. Real-World Usage
The vast majority of email addresses in use are much shorter than 255 characters. Using a larger limit rarely gives any benefit, but doing so can marginally waste storage.
4. Standards vs. Practice
RFC 5321 defines the theoretical maximum (320 characters: 64 for local-part + 1 for @ + 255 for domain), but most applications and services don’t allow anywhere near this length in practice.
5. Compatibility
VARCHAR(255) is widely compatible, and frameworks/ORMs may even assume this field length for things like user authentication.
Summary Table
| Max Length | Standard (RFC 5321) | Typical Usage / DB convention |
|---|---|---|
| 320 | Yes | Rare / Uncommon |
| 255 | No | Very common |
If you truly need to support the maximum size as per the RFC, you can use VARCHAR(320), but for practical, compatibility, and performance reasons, VARCHAR(255) is recommended and more than sufficient for almost all applications.
Example of an email field in a migration:
$table->string('email', 255)->unique();
In summary:
We use VARCHAR(255) by convention because it balances standards, compatibility, and efficiency. If you want to strictly follow RFC 5321, you can use VARCHAR(320), but it’s rarely necessary.