Why We Stopped Putting Enums in Postgres

Mon, 25 May 2026 10:00:00 +0530

Reach for a Postgres ENUM and it feels like the responsible choice. You’ve got a column that can only be pending, sent, or failed, so you encode that at the database level, get a compact type, readable \d output, and a hard guarantee that no garbage value ever lands in the column. Textbook. I’ve shipped plenty of them.

Then I spent about fifteen months embedded in a multi-tenant AI voice and texting platform for home-services contractors — an AI receptionist that answers calls, books jobs into the CRMs those contractors already run on, and drives outbound campaigns. The codebase moved fast: on the order of six thousand PRs in eleven months, a migration runner with per-environment concurrency locks, and enough accumulated schema churn that the team eventually re-baselined the whole migration history from a production schema dump. In that environment, native enums quietly became a tax. So on new columns we stopped using them — plain text, with the value set validated in the application layer. Here’s the reasoning, because the tradeoff is real and it cuts both ways.

Database on Kuldeep Pisda

Why We Stopped Putting Enums in Postgres