The persistence mechanism should be based on the needs of your application. A related issue is fault tolerance / availability.
Speaking exclusively about the speed of persistence of messages, KahaDB will be the fastest; it is specially configured for the patterns surrounding the messaging (write / read / drop). If you used something like MSSQL, even with logging turned on, you decrease the efficiency (in mg / s) by an order of magnitude. This setting works well if you are interested in publishing large volumes of messages and are ready to leave a recovery message to the administrator or some kind of “invented here” process.
So why did you choose a different save mechanism? High availability.
Re: Something like a relational database, maybe something already in your enterprise, which means that someone (hopefully) went through clustering and testing for disaster recovery. This means that you must have a master / slave setting, and your messages will be restored if the master was to go down. The slave will detect a loss of lock and begin to use the same message store. This setting is ideal if your performance threshold is much lower, but you are very worried about the time and guarantee that you can always post / sign messages.
Regardless, on a well-tuned system, we say> = hundreds of msgs / sec, so performance considerations are not likely to be your first concern. If performance is really important, I would think of something like RabbitMQ , which, of course, has proven itself to be extremely effective due to the increased availability of the configuration complex.
Here's a discussion of some failover options using ActiveMQ . I decided to use the general master / slave file command when KahaDB will be shared with the SAN. This seems to be a good solution for medium-sized groups.