You need to understand what your databases are doing so that you can tune your server environment to fit.
I/O is far more important than CPU for most databases.
If you're doing basic SELECT n1,n2,n3 FROM table_name, then this won't really tax the CPU, however if you're doing a large number of calculations on the fly whilst retrieving the data (SELECT n1 * n2 / n3 FROM table_name WHERE n1 > n4) etc..., then this may start to eat your CPU.
I'd focus first on a FAST disk IO and plenty of memory, traditionally these are the weak points in most database servers. For real speed, you want multiple RAID5/10 channels and split databases between channels, but this is not cheap :-)
Monitor the current servers and see where the bottlenecks are, then decide where to spend the money.
What I'm saying is that you need to see how YOUR system is performing. A SCSI RAID 5 will not help is you don't have an IO issue.
Most SQL engines will benefit from huge amounts of memory.
I've seen applications that do a select * from table, then only process the 1st record discard the rest of the record set, then loop back round ! No amount of database tuning will correct bad design.
Efficient indexes can dramatically alter the performance of a database with no change to the underlying hardware.
I've not pulled apart a forum to see how they are coded, but I would guess it's using decent WHERE clauses and decent indexes.
Simple solution is to throw money at the disk subsystem, add plenty of memory and have fast CPU's, but that MAY NOT achieve a huge speedup.
A simple example... I had a 3rd party web app installed on a HelpDesk system (> 40Gb MS SQL database, 4*550 PIII 4Gb RAM), one of the queries took several minutes to run, building an index tuned for that query reduced the page load time to seconds.