I'm certainly not a Riak expert, however I did find a blog post which claims that this: SELECT addresses.state, COUNT(*) FROM people JOIN addresses

I'm certainly not a Riak expert, however I did find a blog post which claims that this: SELECT addresses.state, COUNT(*) FROM people JOIN addresses ON people.id = addresses.person_id WHERE people.age < 18 GROUP BY addresses.state translates into this Raik abortion: { "input":"people", "query":[ {"map":{"language":"javascript", "name":"Riak.mapValuesJson"}}, {"map":{ "language":"javascript", "source":"function(value, keyData, arg){ var data = Riak.mapValuesJson(value); if(data.age && data.age < 18) return [[value.bucket, value.key]]; else return []; }" } }, {"map":{ "language":"javascript", "source":"function(value, keyData, arg){ var data = Riak.mapValuesJson(value); if(data.address && data.address.state) return [{data.address.state: 1}]; else return []; }" } }, {"reduce":{ "language":"javascript", "source":"function(values, arg){ return values.reduce(function(acc, item){ for(state in item){ if(acc[state]) acc[state] += item[state]; else acc[state] = item[state]; } return acc; }); }" } } ] } Can you do that same SQL query in Riak in a simpler way? Will the Riak query ever benefit from indexing, or does it map against the entire dataset every time? Also, in the Riak query (and the example SQL) there is a hardcoded 18. In SQL you can use bind parameters to ensure that there is no chance of an injection attack. How would you do this in Riak? It seems like you would have to escape the value into the JS code you are sending to the server? Code generation is a huge pain, and string concatenation isn't going to cut it, but that sad state of affairs is what I see here: https://github.com/basho/riaktant/blob/master/examples/log-hotspots-per-hour.js https://github.com/basho/riaktant/blob/master/examples/log-h... That code is linked from the Riak documentation, and is ugly as sin. Do you have to specify queries against indexes based on what was indexed? In Postgresql, the query planner will make use of whatever indexes are available if they will help performance, but the SQL will execute with our without those indexes. In Riak it appears that it will simply map-reduce all data unless you specify a 'search' something or other to narrow it down, but that 'search' functionality is on the outside of the map-reduce, so the developer has to know which fields are indexed and which are not, and there isn't much hope of more complex index enabled joins.