The following provide some hardware provisioning guidelines for 25 / 50 / 100k mailbox.
Our rule of thumb is that 1 mailbox counts for 20-30 messages a day, so you're looking at 750k - 3M messages / day.
For hardware a rule of thumb is that a single server can handle around 150k messages a day. For installations handling around 500k a day or less, we can go with simpler math and say that <150k, 1 server, 150k-300k, 2 servers, 300k-500k, 3 servers.
(Where "server" means a modern quad-core processor with 8 GB of RAM and sufficient storage, e.g. 1TB or so. There is more specific guidance on disk sizing in the Installation Guide, sections 6.2.1 Disk Space for Archiving.)
However, when you get into larger installations then there are a bunch of optimizations that our devel. team are aware of. In these larger cases these details become more significant and it's more important to tune our recommendations to fit the customer specific needs. (see Hardware Specifications Hosted)
For example, what kind of disks to buy, how to configure them (e.g. RAID10 using software RAID (most h/w RAID controllers are terrible compared to linux software RAID), divvying up certain partitions on certain partitions to maximize disk IO throughput (our hosted systems use 3 pairs of disks, I think, for this reason), whether or not to use PGBouncer which optimizes database connections... and a bunch of other optimizing stuff that our devel. team gurus are aware of.
So for smaller installations < 500k mesgs/day I'm pretty okay with recommending "general" hardware (quad-core processor, 8GB RAM, 1TB hard disk, 3x servers) but for larger installations I want to let the devel. team provide more specific details as the details can make a big difference.
Otherwise a client could end up wasting money by buying too many servers, or maybe two servers like the dbservers should have had a different hard drive configuration than the others, or maybe the dbservers should have had 32GB of RAM and the others could get away with 16, etc.
So hopefully the above is kind a a good ballpark for understanding the basics and also realizing that for a large installation like this it's best to let our devel. team come up with specifics to meet their needs so they don't over-provision or under-provision or misconfigure.