That's ~15gb per billion contacts. There's an estimated ~2 billion gmail users, so we're talking 30gb just to have one guid per user, and you're suggesting multiple guids per user (unbounded). So, let's assume each user has at least two services, we're now at a 60gb table, and that doesn't even include a mapping between users and guids, which will probably double the table size even more.

At scale, you're probably looking at a multiple-terabyte table, right from the start, and spending compute-days, or even compute-weeks, just running migrations; just to get some dubious returns and a lot of additional end-user complexity.

> So, let's assume each user has at least two services, we're now at a 60gb table, and that doesn't even include a mapping between users and guids, which will probably double the table size even more.

That's literally nothing. As I said, each user gets 10x more spam than that daily.

> and spending compute-days, or even compute-weeks, just running migrations

Migrations for what?

> just to get some dubious returns and a lot of additional end-user complexity.

There is no additional user complexity.

Supposing your math is correct, each user has a relatively fixed but larger than normal storage overhead for their address book and a inbox that that grows slowly because there's no spam, rather than a a small but fixed storage overhead for their address book and an inbox that grows 10x-100x faster due to mountains of spam.

I just really don't think you're comparing the storage requirements correctly.

Here's the magical thing about bulk emails ... you only have to store the body once.