flâneur

Postgres: Boundless `text` and Back Again — brandur.org

brandur.org · 1,760 words · saved by 1 readers

One of the major revelations for almost every new user to Postgres is that there’s no technical advantage of specifying columns as varchar(n) compared to just using bound-less text. Not only is the text type provided as a convenience (it’s not in the SQL standard), but using it compared to constrained character types like char and varchar carries no performance penalty. From the Postgres docs on character type (and note that character varying is the same thing as varchar): There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead. For many of

Postgres: Boundless `text` and Back Again — brandur.org brandur.org Articles Atoms Fragments Newsletter Sequences Now Uses About Auto Postgres: Boundless `text` and Back Again Article Postgres: Boundless `text` and Back Again 🔗 Published Sep 10, 2021 Location San Francisco I'm on X/Twitter at @brandur . Sep 10, 2021 S3ripe varchars considered ~harm~helpful Coercible types and operations SQL domains Integrity in depth One of the major revelations for almost every new user to Postgres is that there's no technical advantage of specifying columns as varchar(n) compared to just using bound-less te

related reading