✳flâneur — a map of the web's best reading

Nine ways to shoot yourself in the foot with PostgreSQL

philbooth.me · 2,166 words · saved by 1 readers

Previously for Extreme Learning, I discussed all the ways I've broken production using healthchecks. In this post I'll do the same for PostgreSQL. The common thread linking most of these gotchas is scalability. They're things that won't affect you while your database is small. But if one day you want your database not to be small, it pays to think about them in advance. Otherwise they'll came back and bite you later, potentially when it's least convenient. Plus in many cases it's less work to do the right thing from the start, than it is to change a working system to do the right thing later on. The biggest mistake I made the first time I deployed Postgres in prod was not updating the default value for work_mem. This setting governs how much memory is available to each query operation before it must start writing data to temporary files on disk, and can have a huge impact on performance. It's an easy trap to fall into if you're not aware of it, because all your queries in local develop

Nine ways to shoot yourself in the foot with PostgreSQL 23 April 2023 Previously for Extreme Learning , I discussed all the ways I've broken production using healthchecks . In this post I'll do the same for PostgreSQL. The common thread linking most of these gotchas is scalability. They're things that won't affect you while your database is small. But if one day you want your database not to be small, it pays to think about them in advance. Otherwise they'll came back and bite you later, potentially when it's least convenient. Plus in many cases it's less work to do the right thing from the st

Explore this link on the map →

saved by

related reading