OK, so we were getting nervous about spam growth, and so someone suggested that we just try a different architecture.
I was worried about this, but it turns out the redesign was really simple...
Instead of one great big Pg or SQL Server database indexing all the spam for a user, we give each user a database of their own. We go from 9 billion rows in 1 table to about 100 rows.
Step in SQLite.
We simply have /a/b/c/d/user.db for every user, where /a/b/c/d is a split hash structure of the email address. Stick it all on a big fat NetApp storage system and you have perhaps the world's most scalable spam storage system.
Now the clever bit was that because all my database calls are abstracted, but not *too* abstracted (a-la Alzabo or Class::DBI), I simply changed all my bits of code that accessed the spam database to do:
local $self->{dbi} = $self->sqlite_db($email);
And then like magic all the original code still works. And because all this was in a single abstraction layer it was about 2 hours work, with about another hour to fix up all the tests.