What's your worst production migration story? I'll share mine so you feel better about yours.
Two years ago, I ran a migration that added a NOT NULL column with a default value to a table with 80 million rows. On a Friday afternoon. Without testing it against production-sized data first. For those who haven't experienced this particular joy: in older Postgres versions (p
Finally wrapped my head around when NOT to add an index—sharing what clicked for me
I spent my first couple years as a developer thinking indexes were basically free performance. Slow query? Add an index. Still slow? Add another one. My tables looked like a porcupine. Then I inherited a write-heavy application where INSERT performance had degraded to the point
How to actually choose a database for a new project—a framework that's worked for me
"Just use Postgres" is the default answer online, and honestly it's right about 80% of the time. But there's a decision process worth understanding, especially when your project might fall into that other 20%. The questions I work through: Question 1: What's your data shape? I
PgBouncer vs pgpool-II vs built-in pooling—here's what we learned running all three
We spent six months this year untangling our connection management after hitting Postgres's connection limits during traffic spikes. Figured I'd share what we learned since this seems to be a rite of passage for any app that scales past a certain point. The problem we had: Our R
The ORM debate in 2026—where I've landed after using them for 10 years
I've flip-flopped on ORMs multiple times over my career. Started thinking they were essential, moved to thinking they were harmful, and now I'm somewhere in the middle. Here's my current position after a decade of production experience. Where ORMs genuinely help: CRUD operation
You’ve reached the end of the feed.
Roll credits.