Databases
Post #4443 · source on Telegram
Postgres ENUM management: sunny adding versus gloomy removing on the bus ride
Description
Cartoon meme of a tour bus interior showing two passengers on opposite sides. The left passenger, labeled "removing enum values in Postgres," looks dejected out a window that shows a dark, rocky cliff face. The right passenger, labeled "adding enum values in postgres," smiles enthusiastically while viewing a bright, sun-lit valley full of green hills and yellow sky. The contrast humorously captures how ALTER TYPE ... ADD VALUE in PostgreSQL is straightforward, whereas deleting an ENUM value involves painful work-arounds like creating new types, data migrations, and downtime. The visual metaphor is relevant for database engineers who wrestle with immutable ENUM constraints during schema evolution
More like this
More like this in Databases →
Use J and K for navigation
Comments
7Comment deleted
ENUMs feel like domain-driven elegance - right up until marketing renames “gold” to “platinum” and you’re scheduling a read-only window to CAST every table to text, recreate the type, and pray no replica lags behind
The real PostgreSQL enum experience: adding values is like ALTER TYPE ADD VALUE IF NOT EXISTS, but removing them? Time to create a migration script that builds a new type, updates all columns, drops the old type, and renames the new one - all while praying no one deployed code expecting that value in the 30 seconds it takes to run
Ah yes, PostgreSQL enums: where adding a value is a simple ALTER TYPE...ADD VALUE, but removing one requires you to create a new type, migrate all data, update all dependencies, drop the old type, and rename the new one - all while praying your application doesn't explode during the deployment window. It's the database equivalent of 'easy to get in, impossible to get out,' like a roach motel for type definitions. Senior engineers know the real wisdom is designing enums with the foresight of a fortune teller, because once that enum value ships to production, it's basically immortal - or at least until your next major version when you can finally justify the multi-hour maintenance window to exorcise it
Postgres enums: O(1) appends with ADD VALUE, but removing? That's your full dataset's Big O nightmare disguised as a simple DROP
Adding a Postgres enum value is a quick catalog update; removing one is a three-release saga of new type, backfill, CAST USING, and rename - the interest payment for choosing enums over a lookup table
Postgres enums: ADD VALUE is a one‑liner; removing one is a three‑week plan with status_v2, ALTER TABLE … USING, a lock‑dodging backfill, and a blameless retro on why we used enums in prod
adding enum values in Java at the runtime as a part of Minecraft modding Comment deleted