That part I don't understand. Why does your proposal require varchars everywhere?
That's what Persistent generates (using derivePersistField) for the second table. For example, the Haskell value MyText "foo" where MyText is newtype MyText = MyText Text deriving (Show, Read) derivePersistField "MyText" will be stored in PostgreSQL as a varchar 'MyText "foo"' I assume that Persistent (or its PostgreSQL backend) has a predefined mapping from a commonly used Haskell types to the database types. And everything else is represented as a varchar. So there are two choices, corresponding to the two tables shown in the original message: 1. Design tables with the (basic) database types in mind (integer, boolean, timestamp, varchar, etc.) then wrap and unwrap values each time you interact with the database. 2. Use Haskell types like MyText or something more complex directly and end up with varchar everywhere. I wonder how bad is the second option in practice because wrapping/unwrapping is error-prone. Of course, the varchar thing makes the alarm bells ring in my head, but when does it significantly affect performance? For example, maybe it's okay for a small shop, or is it a no go for everyone?