You can do it in an even easier way. For example: article450 = {'title': 'This Awesome Thread!', 'text': 'Blargh!', 'comment_ids': [17, 18, 19]} So, you can

You can do it in an even easier way. For example: article450 = {'title': 'This Awesome Thread!', 'text': 'Blargh!', 'comment_ids': [17, 18, 19]} So, you can embed it right in the object just as easily as setting up another object in the store just for the ids. That helps with foreign-key type situations, but it doesn't help for a lot of other things. I guess my perspective on it is that the restrictions are fine for small apps with few features, but for small (size of data) apps you don't need 20,000 operations per second. MySQL handles it easily. Likewise, if you're dealing with a bigger app, you're going to want to be able to query data in more ways. MemcacheDB is great for what it is: a key-value store. It's not a replacement for a RDBMS. In fact, you really can't create such a database as you propose. The issue is that there are problems in computer science that grow at certain rates. For example, sorting is an n * log(n) problem. You simply can't do better than that. That's how indexes work (very simplistically). If you limit yourself to operations that you can do in constant time, you have hash tables. You can't query a hash table except by key. Distributed hash tables are decently well known systems, but they don't replace databases in most applications and you can't make them more database like unless you eliminate the property that makes them scale so well.