Admitting my hubris (and unconstrained TextFields and CharFields)
Published 13 March, 2026.
This post went in a different direction than I thought it would. I was going to write that given a CharField is always limited by its maximum length, so why not always use the TextField, which has unlimited length?
Then I actually read the documentation for CharField. It’s not explicitly called out, but the max_length argument is optional and has a default value of None.
class CharField(max_length=None, **options)
I was shocked that you don’t have to specify a maximum length at all! I’d assumed that this was a required argument for more than a decade. This assumption is a hold-over from working with SQL Server circa 2000. I did a quick test, and was amazed to see that it’s true.
The documentation calls out that it is required for some database backends in some scenarios (in MySQL, the maximum length must be less than or equal to 255 if there’s a uniqueness constraint on the field, for example). But in a surprising number of instances it’s optional.
Now this doesn’t mean that CharFields are unlimited. But neither are TextFields. I’ve done some digging and found the following limits in the databases supported by Django:
| Database | CharField maximum length | TextField maximum length |
|---|---|---|
| PostgreSQL 18 | about 1 GB1 | about 1 GB1 |
| MySQL 9 | 65,535 characters2 | 4 GiB3 |
| Oracle 19 | 4 KB4 | 4 GB4 |
| SQLite | 1 GB5 | 1 GB5 |
Where does this leave us? For my work which is mostly in PostgreSQL, it doesn’t matter whether you use a CharField or a TextField—they can store the same amount of data. The same is true for SQLite.
But there is a difference in MySQL, and a significant difference in Oracle.
If there are no other concerns, preferring TextFields over CharFields still seems a good idea. They consistently store a string which is much, much larger than anything you’d reasonably want to put into a database. But it doesn’t matter quite as much as I’d previously thought.