>I am always telling people to *measure* performance if there is an issue, but the trick is to measure something relevant to your app. For a web app that means measure the edxpected no. of connections hitting at the same time and measuring n-fold hits as well to approximate scalability. For a desktop app you might compare reading all data with one connection or opening additional connections and reading in background/parallell if massive amounts of data are read. But - how often do you plan to use select * whithout where-clause in your app ?

If you are comparing the basic performace of different databases, then isn't this the first thing to check? another would be speed of making a connection. Anyway mine is a C/s app and such a test is relevant because I am changing the database.
And I agree with you on this that there are a million things further than that including app. architecture, design, platform, etc. which are best considered before selecting your tools.
The sad thing is that there is no clear cut guidlines or benchmarks available for databases to make your decision easy.:(