If you have lots of RAM, and your data is big, too, memcached will outperform MySQL because you can run several daemons and circumvent the process size limit problem. (Talking 32-bit here.)

I've run benchmarks -- I wouldn't make statements like that without trying it. BerkeleyDB is insanely fast. You can run Rob Mueller's benchmark yourself and see what you think, although it doesn't currently include a memcached comparison. It makes sense that it would be faster than Memcached, since it has no network overhead or separate server process and can cache things in shared memory.

Striping your data across multiple machines is an advantage of memcached, although it doesn't seem relevant to this particular person's needs.

Thanks for the very interesting benchmarks. I didn't realize BerkeleyDB was so fast.

If you mentioned striping in response to my point about huge data, then note that you can get the benefits even on a single machine. If, for example, you have 8GB of RAM, you can run several memcached instances on the same machine, all under 2GB in size, but still have an effective cache size that is close to your potential maximum. Of course in a few years when 64-bit machines become common this advantage goes away, but in the meanwhile memcached works around it pretty much transparently.

But yes, this is not necessarily as useful for the OP's needs as it was for the designers of memcached.