It seems to me your problem is that you are trying to test performance metrics that are not well supported in the underlying db. This makes it very difficult to compare performance across systems because the underlying approaches are very different. I don't think it is possible to do apples to apples comparisons just as I don't think you can do an apples to apples comparison of ORDBMS type approaches to RDBMS type approaches. The performance concerns are just too different and if Stonebraker is right that optimizing an ORDBMS for TPC-C tests misses the point, then for systems that are even further apart it is going to be impossible. (I think he is right there, however, only where ORDBMS functionality comes into play.)
I think what you need to be honest is to look at how you would use each system and build a benchmark tool based on the approach you'd take with each. Then you can say at least for that workflow that the benchmark shows something specific. I don't see how you can generalize however. You could further run it in a profiler in order to get additional information about where the time is being spent in the test run on various engines.
However db benchmarking is very difficult to make meaningful in the best of circumstances and when you are comparing dissimilar systems it becomes impossible to generalize.