Database VARCHAR Length Design: Best Practices for Character Limits
Choosing the right VARCHAR length for database columns is a fundamental design decision that affects storage efficiency, query performance, and data integrity. This article covers practical guidelines for common field types across major database systems.
VARCHAR Behavior Across Databases
| Database | VARCHAR Max | Unit | Notes |
|---|---|---|---|
| MySQL (utf8mb4) | 16,383 | Characters | Row size limit: 65,535 bytes |
| PostgreSQL | 10,485,760 | Characters | Effectively unlimited |
| SQL Server | 8,000 / MAX | Bytes or Characters | VARCHAR(MAX) for large text |
| Oracle | 4,000 / 32,767 | Bytes | Extended mode for 32K |
| SQLite | No limit | Characters | Length is advisory only |
Recommended Lengths by Field Type
| Field | Recommended VARCHAR | Rationale |
|---|---|---|
| 254 | RFC 5321 maximum | |
| Username | 50 | UI display constraints |
| Display Name | 100 | Multilingual support |
| Phone Number | 20 | International format with country code |
| URL | 2048 | Browser practical limit |
| Short Description | 255 | Common default, fits most summaries |
| Address Line | 200 | International address formats |
Key Principles
- Always use utf8mb4 in MySQL — utf8 (utf8mb3) cannot store emoji or some CJK characters
- Match API validation limits to database column lengths to prevent truncation errors
- Don't default everything to VARCHAR(255) — choose lengths that reflect actual data requirements
- Consider using TEXT types for fields that may exceed a few hundred characters
Conclusion
Thoughtful VARCHAR length design prevents data truncation, improves storage efficiency, and maintains consistency between your API and database layers. Use Character Counter to test real-world data lengths when designing your schema.