Q:

HDD overhead and the most efficient storage

we're thinking about moving to Postgres from some other DB backend we're currently using. From what I've really seen, it's very reliable, stable and efficient. I realized I really like Postgres - it performs very well, compared to some other trendy things. However, the use case might be odd so I'm a bit concerned about my decision.
What we want is a simple key-value storage for hundreds of millions of rows. Each row is very different in size - from 10 kb to megabytes (but not more than 10 megabytes). Keys are strings, values are binary data.
We need only the PK and the Key index, no indexes for values.
However, since we use SSDs, I'd like to keep the disk usage as low as possible. So what is the HDD overhead in Postgres? Is there any formula to estimate it?
What would be the best storage engine for that (keeping the lowest HDD usage)? We need very fast writes but it's ok to have relatively slow reads.

A:

PostgreSQL has an overhead of 24-28 bytes per row.
It's that big because the rows contain all the MVCC transaction visibility information - there's no "redo" and "undo" logs like some other MVCC database implementations have. That has some real advantages in some workloads, and some real disadvantages in others. Yours is probably one of the disadvantages.
Not only that, but I don't see that you'll really benefit from PostgreSQL's features. It does offer very robust write safety guarantees. It has reliable transaction isolation (at a variety of levels). There are lots of good things, but many of them are less useful if you're just using it as a dumb k/v store.
I suggest that if all you need is a dumb K/V store, use a dumb k/v store. There are tons of options out there to meet different requirements with different levels of isolation/transaction support, write reliability, etc, and correspondingly different overheads and consistency guarantees.
One time where PostgreSQL can be great is when you want to mix K/V like operation with other more relational workloads. In that case support for things like hstore and json can be fantastic. They're not really ideal for your use case though.

