Oracle solo es gratis para desarrolladores, dentro de su entorno de desarrollo.

Las bases de datos no suelen compararse por rendimiento sino por funcionalidad. Todos los fabricantes te dicen "mi sistema de bases de datos es mas rápido!!!" pero eso no es más que publicidad, todas están optimizadas a muerte y las diferencias de rendimiento son muy relativas. Si quieres mejorar el rendimiento de una aplicación en mysql, compras una máquina nueva, no licencias de oracle. Y si aun comprando la máquina nueva te queda dinero para licencias, te lo gastas en otra máquina y montas un cluster, que se comerá a cualquier máquina con oracle.

La verdadera diferencia como digo está en la funcionalidad que te da cada una. Por ejemplo, mysql ofrece más tipos de datos que oracle o MsSql, mientras q oracle tiene un sistema de formularios compartidos envidiable, y MsSql es más facil de gestionar que cualquiera de las otras. La mejor será la que mejor se adapte a tus necesidades.
Oracle es para sistemas muy grandes, con cientos o miles de tablas y usuarios. Usarlo para Pandereta es matar moscas a cañonazos. Y aun hay más, Oracle lo compran todas las empresas que no pueden permitirse decir "uso una base de datos gratuita", aunque les bastara con mysql. En el mundo empresarial a veces se compran los productos más caros, solo por el hecho de ser los más caros y poder decir "usamos el producto más caro!". Además de esa forma, el día que falle nadie podrá burlarse de que les falló por ser un producto barato, y que de haber sido el más caro no habría fallado. Pero esto es otra historia para otro rato...

2 cuestiones:

1º. Creo que la opcion mas sencilla seria externalizar la gestion de las reservas a un hosting ajeno con potencia de equipo suficiente durante esa semana (no tiene cambiar de hosting o de equipo para solamente la saturacion producida durante 3 horas durante un 1 al año).


2º. Respecto a cambiar de base de datos, aparte de las complicaciones en la programacion que ello tendria implicito, creo que el problema no esta ahi, mas bien el problema reside en la capacidad o no del equipo que soporta la base de datos, todos sabemos que una implementacion sql php es una gran consumidora de recursos (sobre todo memoria, y si las consultas son minimamente complicadas de CPU), hoy por hoy es infinitamente mas barato la amplicion hardware que la modificacion software (es triste pero es asi, y en cierto modo es logico), desconozco cual es la base hard y soft sobre la que se esta trabajando, pero imagino que una opcion sería colocar durante esa semana un equipo de refuerzo (en cluster con el primero) o en su defecto ampliar (o cambiar) el antiguo equipo.

3º. Si definitivamente se quiere cambiar la base de datos, no creo que oracle sea la opcion mas interesante (como ya sabemos los requerimientos de equipo son bastante importantes) hay otras opciones como postgresql que son perfectamente viables (aunque reconozco que mis conocimientos sobre bases de datos son mas bien teoricos que practicos, por lo que creo que seria mejor que nos informara alguien que haya trabajado profesionalmente tanto con mysql como con postgresql)...

En esto de las bases de datos pasa como con los equipos hardware hoy en dia, todo el mundo te saca benchmarks de rendimientos punta, pero yo no quiero un equipo con un 30% mas de rendimiento , quiero un equipo que con un 40% menos rendimiento que otro me de una estabilidad del 99.99999% (estoy cansado de ver placas con los condensadores supurando, con soldaduras en mal estado, con fallos aleatorios...., lo mismo con las memorias y procesadores... no quiero rendimiento.... quiero fiabilidad (porque con el rendimiento del procesador actual mas pequeño ya me sobra equipo).

Con lo bien que viene de vez en cuando un unset() he.

A ver entonces al final el fallo fue, que se conecto todo dios a la vez y la CPU se puso al 200% y mysql no daba a mas pro saturacion de CPU?
O fue cosa de que mysql no soportaba tantas peticiones simultaneas?