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.

Ambarsthan Bookings: Let the Database Win the Race

Sat, 07 Mar 2026 10:00:00 +0530

In the last chapter I poured the walls between our Celery workloads so a slow transcode could never delay a donor’s payment — isolation by named queue, one worker per latency class. That was about fairness under load: making sure nobody waits behind the wrong thing. This chapter is about the harder cousin of that problem — correctness under load. Not “who goes first,” but “what happens when two people try to take the exact same thing at the exact same instant, and both of them are right to think it’s available.”

postgresql on Kuldeep Pisda

Why We Stopped Putting Enums in Postgres

Ambarsthan Bookings: Let the Database Win the Race