The following issue was raised on Stack Overflow in this question. The data has been set up like this: db.posts.insert({sents: [ {uni:[ 'a' , 'b' , 'c' ],bi:[[ 'a' , 'b' ],[ 'b' , 'c' ]]}, {uni:[ 'x' , 'y' , 'z' ],bi:[[ 'x' , 'y' ],[ 'y' , 'z' ]]} ]}) The following query when issued in 2.4 versions returns the desired result: db.posts.find({ 'sents.bi' :{ '$elemMatch' :{ '$ in ' :[ 'a' ]}}}) and result: { "_id" : ObjectId( "537595f254bae6dfabddf0c9" ), "sents" : [ { "uni" : [ "a" , "b" , "c" ], "bi" : [[ "a" , "b" ], [ "b" , "c" ] ] }, { "uni" : [ "x" , "y" , "z" ], "bi" : [ [ "x" , "y" ], [ "y" , "z" ] ] } ] } The same query issued in 2.6 does not return any result. This is questionable as I believe the correct form of the query should be: db.posts.find({ 'sents.bi' :{ '$elemMatch' : {$elemMatch: {$ in : [ 'a' ]}}}}) Which will return the desired result in both versions. So not sure if the selection is a bug that was present in earlier releases or whether there is something causing that statement to fail in 2.6 releases. As a side note the question itself refers to creating an index on the collection: db.posts.ensureIndex({ 'sents.bi' }) Which causes the query to fail in earlier versions. This I believe to be correct due to the nested array than cannot be used as in index value. The second form of the query will not directly select an index unless that has been hinted in some way. In 2.6 a hint to that index will produce an error and a sort simply ignores the index. In 2.4 the index will be shown as selected in the explain output, but there will be no bounds selected.