I'm also wondering about that. But maybe this could be it? > Surprisingly, the table is just as big as with the enum type above, even though an enum uses four

I'm also wondering about that. But maybe this could be it? > Surprisingly, the table is just as big as with the enum type above, even though an enum uses four bytes. The reason is that each table row is aligned at a memory address divisible by eight, so PostgreSQL will add six padding bytes after the smallint. If we had more columns and could arrange them carefully, we could see a difference. This could be the explanation. If the row is padded to 8, bigint is 8, then smallint or enum also use 8. The entries in the string table will be 8 or 16 due to the string length. So one row in person_e and person_l is 16, one row in person_s could be about 20 on average, that is a bit closer to the reality than my intuition, although the storage savings are still less than what I would have expected. edit: I did also try out the test and dropped the primary key on the table to compare only enum and string size: SELECT PG_SIZE_PRETTY(PG_RELATION_SIZE('person_e')), PG_SIZE_PRETTY(PG_RELATION_SIZE('person_s')) 277 MB,330 MB Does not look like an amazing saving either.