Have you considered Redis for persistence in place of MongoDB? It's excellent for stats applications.

There are companies doing stats applications using MongoDB too. It's supposedly one of its strengths. I'll look into Redis too, though.

I've seen people using MongoDB in memory only as a cache, so that they can mapreduce it. Even without that, it's writes to disk are async so it's fast.

What's the point of map reduce if data can be held in memory ?

why do you think it's better than MongoDB for stats?

> I implemented a heartbeat-based web stats service but it's too resource-intensive to run affordably on Apache/MySQL.

I don't buy that. Maybe with the default configs, but apache+mysql are incredibly tunable.

It's being added to an existing service, so when I turn it on, it needs to be able to handle 10-20,000 concurrent visitors from the start. I tested that with two Amazon EC2 Medium instances as load balanced web servers, running Apache with only the minimum necessary modules enabled and tuned parameters, and the load (and resulting response times) was too high. More servers than that would be too expensive to support rolling out the feature to the current user base, so I need to try what I can to handle it with the resources I can afford.

If I can handle that concurrency with node.js without overloading the same number of servers, then it would become viable. With 1000+ requests per second that just need to dump some data and leave with empty responses, a non-blocking server that just queues up the database writes and gets rid of the connection fast could do that. Apache's got to load up and tear down the whole PHP environment and wait for the database query to run before it can finish with each connection.