I wish you could add more Servers, that should solve all the problems, I think!
Not in many cases. While you can load balance the front-end, as HTTP is rather simplistic, the SQL distribution is more complex.
I have to assume LAMP (Linux, Apache, MySQL, PHP) is in use here. The fastest performing deployment of MySQL in a multi-server farm is many read-only replicas, and one write-only master. In fact, that's the staple web approach that made MySQL very popular -- because it solves that common, web design (write one, full record to one instance, read many, many times from other instances), instead of full, traditional, ACID approaches where most implementations have legacy to Ingres/Postgres (e.g., MS SQL, Oracle, Sybase, etc...). Multi-master replication is far, far more difficult, and requires more complex software and administration.
I would assume the messages are due because of too many commits -- i.e., transactions that actually write to the master databaes. So adding more Apache with read-only MySQL replicas in a round-round option wouldn't solve that, because the commits/writes go to the single, master server. Records are created for vBB for many things, including searches.
If anything about the only tunable you could do is cap the number of posts, searches and other things that cause a commit, and favor dynamic content generation of pages/threads that are read-only. But people who still cause a commit would still see the message.
Another, general option is to throttle the number of requests from the same client with the same cookie/session (IP won't cut it). E.g., I use Firefox and can regularly found guilty of middle-clicking countless links -- 10, 20 even 30+ sometimes. I'm causing the server to dynamically generate content when I do.
There are other options that could be looked at. Just throwing more hardware is not the solution here. I regularly have to smack Java developers with a stick on Wall Street who keep pointing the finger at infrastructure when it's their implementation and open-ended attitude to capacity and performance.