Okay, this may seem strange to some of you, since I'm recommending that you move work from one process to another, without gain of performance. But if you have a computationally intensive task that you need to do over and over again, and especially if you're doing it yourself in a language such as Python or Ruby, this would probably make your life a little bit easier.
Basically, when you saturate one CPU core to the max, you're going to want to put the other cores to work; and when you saturate all the cores on one server, you're going to want to add more servers. It can be difficult to design good concurrency in your application, but your database server is probably already capable of doing things in parallel. By converting your logic into a databasing problem, you essentially gain parallel processing "for free," and all you need to do is throw more hardware at the database server.
For example, I have been writing a little game where I need to compute a field of view (or fog of war) for every character/monster in the game. I can run the computation almost 2000 times a second on my netbook, and a bit faster on my VPS. This is a good start, but I'll probably be keeping track of a lot more creatures than can be handled using one CPU core. Then I realized that I was essentially doing a query (given the set of tiles and shadows within the sight radius, select all tiles that do not overlap with the shadows) that most database engines should handle with ease.
Of course, the way you would transform your logic depends on your application; but if the problem is CPU-bound rather than network-bound, it might be a good idea to put that database server to work...
