December 4, 2025
Database drama, now with extra enums
What is better: a lookup table or an enum type?
Team Lookup vs Team Enum: tiny database choice, giant comment brawl
TLDR: A PostgreSQL guide compared enums (fixed lists) to lookup tables for storing allowed values and showed how plain text can bloat data. The comments erupted: pragmatists push app-level checks, purists demand “everything as a table,” and most builders back lookup tables for easier change later.
PostgreSQL expert Laurenz Albe lit the fuse with a simple question: should your “allowed values” live in an enum (a fixed list inside the database) or a lookup table (a tiny table of allowed choices)? After showing how storing full words like Austrian state names can bloat a table (think millions of rows ballooning in size), he weighed the pros and cons. Sounds calm—until the comments turned it into a tech soap opera.
One camp threw their hands up: “Basically ugly no matter what.” These pragmatists say skip the database rules and validate in app code or config files for speed. On the other side, the database purists marched in chanting theory: everything should be a relation, one true way to model the world. Meanwhile, a crowd of realists argued lookup tables are easier to change over time, while enums are comfy for developers but can hurt later when requirements shift—DX (developer experience) vs maintainability.
Then came the hybrids: use a table plus a smart cache in code, and only use enums when values are deeply part of your app’s identity. The memes wrote themselves: “Enum enjoyer vs Lookup stan,” “not my enum, not my problem,” and “two kinds of devs—purists and people who ship.”
Key Points
- •The article compares implementations for constrained-value columns in PostgreSQL, focusing on enum types and lookup tables.
- •A baseline example uses a text column with a CHECK constraint listing nine Austrian states in an UNLOGGED table.
- •8 million rows are inserted using generate_series and a CASE with hashint4 to approximate realistic state distribution, then a primary key and index are added and VACUUM (ANALYZE) is run.
- •Measured storage shows the table at 392 MB; pg_stats reports an avg_width of 11 bytes for the state column and lists most common values and frequencies.
- •The article signals sections that outline advantages and disadvantages of enum types and lookup tables, leading to a conclusion.