Benchmark Java (JDBC) contra varios gestores de bases de datos
15 de February de 2007 por 
Paco Los chicos de devloop se han trabajado un extenso y detallado benchmark de varias bases de datos accedidas desde Java vía JDBC.
Además, han probado con varias VMs y con multitud de casos posibles: tablas llenas, vacías, threads, sin threads, threads con delay…
Los claros vencedores son MySQL y PostgreSQL y no han incluido Oracle porque, según explican, tiene problemas para conseguir una instalación limpia en la Fedora x86-64 que usan.
Llaman la atención algunos casos atípicos y situaciones inexplicables que tienen muy mal rendimiento en general, como por ejemplo que un select count(*) sobre una tabla vacía es más lento que sobre una llena.
También es relevante la diferencia entre el uso de Statement y PreparedStatement y cómo algunos gestores mejoran dramáticamente su rendimiento.
Por último, las mejoras (¡por fin!) de JDBC en la versión 6 de la JDK pasan factura a la hora de evaluar el rendimiento.
De lectura obligatoria si desarrollais usando JDBC 
MySQL és d’un altre món, no se pot comparar si no li activen l’InnoDB
I sobre DB2… no han tengut en compte que des del propi DB2 (com a minim a la versió per a z/OS) hi ha moltes possibilitats d’optimització, que arriben al punt d’associar a programes concrets plans d’accés estàtics “precompilats” en funció de l’estructura de la base de dades, de les estadístiques i de determinats paràmetres de configuració. Això no se pot controlar des de fora del DB2 però marca una diferència brutal de rendiment (sobre tot de throughput global del sistema, més que de temps de resposta de peticions individuals). Bàsicament a partir de les xifres que se veuen a aquest benchmark, que indicarien el rendiment amb una configuració molt poc currada, la cosa amb DB2 pot millorar un ordre de magnitud. De vegades més. I escalant amb càrregues inimaginables que no hi ha PC que pugui soportar O:-)
Això… m’agrada el tema aquest
Ja, ja sé que se pot optimitzar molt. En tots els casos. I no ja tan sols en termes de configuració de la BD, sino, ja, en temes de programació o del diccionari de dades (ara m’enrecord de que en Ricardo explicava com havia millorat el rendiment de la BD emmagatzemant les IPs com a nombre el lloc de com a caràcter).
Fixa’t en aquesta afirmació que es fa a la plana 25:
No amaunt of database adminstrator performance tunning is going to workarround a broken architecture.
Writing good code, using proven techniques and understanding the efficient use of system resources is more important than the marketing background noise of database vendors.
Tota la raó del món (tot i que un bon hack pot fer miracles amb una broken architecture)