I dumped the data from postgres and loaded into a similar (same name, same columns, in the same order, same columns indexed) it works in much the same way. e

I dumped the data from postgres and loaded into a similar (same name, same columns, in the same order, same columns indexed) it works in much the same way. explain query plan select * from foo where organization_id = 1 order by updated_at limit 10; QUERY PLAN |--SEARCH foo USING INDEX foo_organization_id_idx (organization_id=?) `--USE TEMP B-TREE FOR ORDER BY Just as with Postgres, it starts by ordering the data, though in this case it uses a TEMP B-TREE rather than the index on updated_at (not sure why it's doing that). Then, it filters on organization_id=1, though in this case it uses the index to filter on organization_id. That takes 3.8s on my machine (postgres took ~260ms for the same operation). If I drop the index on organization_id, this is the query plan QUERY PLAN `--SCAN foo USING INDEX foo_updated_at_idx It's back to scanning the foo_updated_at_idx index, just like Postgres does. Interestingly, this takes mere milliseconds. Dropping the index on organization_id actually improves the performance. Finally, just for good measure, if I also drop the foo_updated_at_idx index, this is the query plan QUERY PLAN |--SCAN foo `--USE TEMP B-TREE FOR ORDER BY Running the query in this case takes 4.2s. It's back to using a TEMP B-TREE index for ORDER BY clause, but it has to scan the table. For me, it's hard to draw any hard-and-fast lessons from this. In my experience, database performance is highly context dependent. It depends on the volume and distribution of data, the hardware, its current load, the indexes in place, and how the query is written. These little experiments to me just serve to confirm that. I guess the one hard-and-fast lesson I personally take from this is not to be so certain that there is "a correct query plan" and that I or really anyone knows better than the database what that is. Sometimes in certain circumstances that may be true, but usually it's not.