> 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.
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.