I don't see another obvious advantage of Redis over Tokyo Cabinet other than the nicer complex data structure support. I use Redis for several projects and for

I don't see another obvious advantage of Redis over Tokyo Cabinet other than the nicer complex data structure support. I use Redis for several projects and for me it serves well. Particularly, I know the limit of Redis and can predict how much memory it will eventually eat up with respect to the growth of site. Besides, Redis has a small code base that I can tinker around (It is c!) which would be nearly impossible for me to tinker around MySQL with confidence. Tokyo Cabinet has a nice code base too, and I liked it a lot but the limitation is: Tokyo Cabinet provides either a simple key-value db (b-tree/hashtable) or a full flee of table-like db. The former one is too simple to actual usage and the latter one is too complex (from my point of view, it is just SQL without parser, I even programmed a SQL parser on top of its table db). For my usage, a document-based db (MongoDB) or Redis which has sorted set/set data structure is enough and since MongoDB is complex in terms of code base too, Redis becomes my first choice. Although Redis is critiqued for its VM implementation, I found that it is good enough for my specific usage: I have around 2 million or so keys and the workset is about 25k keys average. Yes, Redis is not a universal solution to everything, and I am a little worried about its current proposal of disk-based system (to me, Tokyo Cabinet's disk op implementation is more mature and antirez should do more analysis on the comparison to Tokyo Cabinet and Berkeley DB since these two are only known k-v based disk DBs that tested in battle field).