Cada vez que vamos a iniciar el desarrollo de una nueva aplicación web, nos surge la duda de cómo trabajar con los datos. Una de las soluciones más extendidas son los sistemas relacionales. Sistemas como MySQL o PostgreSQL son bastante comunes, con tantos seguidores como detractores.
Si buscas en internet sobre las diferencias entre MySQL y PostgreSQL, en prácticamente todas las comparativas se hace referencia a que MySQL tiene mejor rendimiento y PostgreSQL es mucho más rico en cuanto a funcionalidades.
Si bien es cierto, a medida que ha ido pasando el tiempo, MySQL ha ido ganando en funcionalidades, así como PostgreSQL ha ido mejorando en rendimiento. Esto último debido también, en parte, a los avances y mejoras conseguidas en el sector del hardware.
En WATA Factory nos hemos preguntado cómo de importantes son estas diferencias a efectos prácticos, sin entrar en batallas como cuántos microsegundos de diferencia hay entre una u otra, ó la cantidad de funcionalidades avanzadas que al final nunca utilizamos en nuestro día a día.
MySQL: principales diferencias
Con MySQL podemos seleccionar diferentes motores de bases de datos para cada tabla: InnoDB y MyISAM. Éste último es el que ha acompañado a MySQL desde sus inicios, y el culpable de esa fama de “rápido”.
En gran medida la velocidad MyISAM es debida a que no tiene restricciones de integridad referencial, disparadores ni otras características. Si bien estas funcionalidades son más que útiles, pueden llegar a ralentizar las inserciones o actualizaciones al tener que comprobarse en cada operación. InnoDB, en cambio, sí incorpora este tipo de funcionalidades y por tanto ya no resultaría tan rápido en las inserciones o actualizaciones.
Otro aspecto es el tema de bloqueos. En MyISAM, al manipular los datos a través de sentencias INSERT, UPDATE o DELETE, se produce un bloqueo a nivel de tabla. En InnoDB o en PostgreSQL, los bloqueos se producen a nivel de tupla. Es por eso que si nuestra aplicación tiene grandes operaciones de INSERT, UPDATE o DELETE que afectan a un considerable número de tuplas en la tabla, MyISAM se muestra bastante más eficiente. Por el contrario si tenemos muchas pequeñas operaciones concurrentes, InnoDB funciona mejor al bloquear solo la tupla afectada, mejorando la concurrencia.
Puede que pensemos que un motor de BD que llamamos relacional y que no provee de claves foráneas sirve de bien poco, a la par que es un riesgo para la integridad de los datos. No obstante, pongámonos en el caso de una solución típica de Business Intelligence, donde tendríamos un modelo de estrella con una tabla central con pocas relaciones, y que va a ser cargada mediante procesos masivos. Es posible que contar con un motor de BD sin claves foráneas y con bloqueo de tabla sea una ventaja a tener en cuenta. Teniendo en mente que además de poder combinar los dos motores de BD en un mismo esquema, también podemos combinarlo con otras tablas transaccionales en el mismo esquema.
Una idea que algunos sugieren es usar un MySQL con InnoDB para desarrollo y luego pasar las tablas a MyISAM una vez puesto en producción. Para hacer esto, evidentemente, hay que tener muy claro lo que se está haciendo y controlar todo el proceso con mimo. La idea es controlar la integridad de los datos durante el desarrollo pero acelerar las consultas una vez puesto en producción.
En resumen, si vamos a usar MySQL en nuestro desarrollo, nos deberíamos plantear si realmente vamos a sacar partido de MyISAM. Si no es así, puede que sea mejor optar por otros motores.
PostgreSQL y sus características
Si bien MySQL ha ido incorporando, y sigue incorporando, cada vez más funcionalidades, es cierto que PostgreSQL desde un principio ha destacado por ser un sistema de gestión de bases de datos relacional más completo y libre. Para muchos es percibido como el Oracle del software libre. Salvando las distancias, claro.
Entre las funcionalidades destaca su PL/pgSQL muy similar al PL/SQL de Oracle. Mediante el uso de este lenguaje podemos añadir complejidad propia de los lenguajes procedimentales en nuestros SQL: bucles, condicionales, funciones… Los disparadores, por mencionar un ejemplo, pueden llegar a adquirir una complejidad considerable.
A nivel de SQL, PostgreSQL incorpora también la funciones de ventana que nos permiten consultas SQL complejas, más que útiles sobre todo en aplicaciones de índole estadístico. Igualmente, con su sistema de Reglas (Rules), podemos afinar bastante la ejecución de consultas y sentencias de manipulación de datos, alterando la forma en que el comando es procesado por el motor de base de datos.
Hay otros aspectos destacables como la herencia entre tablas y las vistas materializadas. Aunque entrar al detalle daría para otros muchos artículos.
En definitiva, con PostgreSQL tenemos un abanico de posibilidades más amplio a la hora de realizar el desarrollo para una nueva aplicación, por lo que estaríamos menos limitados que si usamos MySQL, algo muy interesante en aquellos proyectos en los que se prevea que un mantenimiento evolutivo a largo o medio plazo.
MySQL vs PostgreSQL en WATA Factory
En WATA Factory siempre evaluamos, para cada proyecto, qué motor de base de datos usar dependiendo de factores como si se trata de un proyecto a largo plazo, tipo de aplicación o número de usuarios concurrentes, entre otros.
A efectos prácticos, si no hay ningún requerimiento específico en cuanto a rendimiento, como ocurre en la mayoría de aplicaciones que vamos a desarrollar, preferimos PostgreSQL, que ofrece funcionalidades muy interesantes que nos podrían ser útiles a futuro, sin que haya grandes diferencias a efectos prácticos.
No obstante también hemos tenido que abordar el desarrollo de proyectos de basados en CMS como Drupal, WordPress o Joomla.
Evidentemente, en estos casos, lo mejor es siempre usar el recomendado por la comunidad que desarrolla estos CMS, que normalmente será MySQL.
Esto es así porque este tipo de desarrollos suele estar sujeto a unos requerimientos específicos en cuanto a posicionamiento o SEO, por lo que un MySQL con MyISAM puede ser una buena alternativa.
En el caso de Drupal además, aunque en la documentación se indique que soporta MySQL y PostgreSQL, hay veces que al instalar módulos de terceros, éstos han sido desarrollados y probados principalmente en MySQL. Así que, evidentemente, dependiendo de la versión Drupal y los módulos a usar en nuestra web, la elección que probablemente nos dé menos quebraderos de cabeza será MySQL.
Si somos nosotros los que estamos desarrollando ese software de terceros, es muy posible que nos pueda venir bien un motor como MySQL fácilmente adaptable y extendido. Por otra parte, si luego decidiéramos que nuestro producto soportara ambos sistemas de base de datos, sería más fácil si partimos de MySQL y lo adaptamos a PostgreSQL que al contrario.