Member-only story
Why We Switched Every varchar Column to text (And Why the Reason Wasn’t Performance)
A few months back, one of the backend engineers on my squad opened a PR that touched almost every migration file in our monorepo. The diff was huge, the description was short: “standardize string columns to text.” My first reaction, honestly, was skepticism. We had varchar(255) sprinkled everywhere — usernames, emails, titles, slugs — and it had worked fine for years. Why touch something that isn't broken?
So before approving anything, I did what I always do when a teammate proposes a schema-wide change: I tried to prove them wrong. I couldn’t. What I found instead reshaped how I think about string columns in PostgreSQL, and it’s not the story most “varchar vs text” articles online tell you.
The performance myth
If you search for this topic, you’ll find a dozen articles promising dramatic performance gains from switching to text. Almost none of them are testing PostgreSQL specifically — a lot of that advice is inherited from MySQL, where varchar and text genuinely are stored and indexed differently.
In Postgres, that’s not true. Both varchar(n) and text use the exact same underlying storage type internally — varlena, a variable-length structure with a length header, optionally compressed and toasted for large…
