PostgreSQL

pg_column_size is nice. I knew a bigint was 8 bytes, but I was curious to see the storage size for comparable numeric data.

If you haven't already, it'll blow your mind when you see how large composite types are to store. It's baffling, especially when you consider how nice it would be to represent a currency as a composite type (value + denomination). You're better off just having two columns instead.

Building @warpcast and @farcaster. Previously Coinbase, Brigade, Causes.

Having looked into this long ago, my best summary is because of the overhead of storing tuple metadata for _each row_. It feels like it could have been avoided, but I suppose the implementation has not yet been optimized. 

That said, being able to define your own operator overloads (e.g. to error if you accidentally try to sum two currencies of differing denominations together) might be worth the storage cost for sake of DevEx.