PostgreSQL vs. MySQL ¿cuál es mejor?

20min

PostgreSQL y MySQL son dos de los sistemas de gestión de bases de datos relacionales de código abierto más utilizados en el momento actual. Ambos son muy conocidos así que es posible que alguna vez te hayas preguntado ¿Cuál de ellos es el mejor? La elección depende de la naturaleza de los datos, el tipo de consultas, los requisitos de integridad y la necesidad de extensiones especializadas, entre otras cosas, sin olvidarse de la propia experiencia y los conocimientos previos que tengamos.

Índice

¿Qué es PostgreSQL?

Vamos a comenzar analizando de manera breve los motores de base de datos objetivo de esta comparativa, comenzando por PostgreSQL. Este es un sistema de gestión de bases de datos relacional orientado a objetos, de código abierto y multiplataforma.

El nombre correcto es PostgreSQL, aunque en la práctica también es habitual encontrar las formas abreviadas Postgres, denominación que durante un tiempo fue también válida, aunque solo en los orígenes del proyecto. Se trata de un motor robusto, extensible y ajustado a los estándares SQL que ofrece soporte a todas las cosas básicas, como tablas, índices, claves, etc. Sin embargo, una de las características más propias de PostgreSQL es que permite trabajar con tipos de datos avanzados, aparte de otras funcionalidades avanzadas, quizás no tan usadas pero también útiles, como funciones definidas por el usuario, operadores personalizados, extensiones, procedimientos almacenados, etc.

PostgreSQL resulta especialmente atractivo cuando el modelo de datos evoluciona, las consultas se vuelven complejas o la aplicación debe combinar información estructurada con formatos más flexibles, entre otros contextos. Es sin duda una alternativa muy poderosa, aunque, toda esa potencia también implica una mayor curva de aprendizaje.

¿Qué es MySQL?

MySQL es un sistema de gestión de bases de datos relacional de código abierto más usado  en el mundo, con una amplia presencia sobre todo en el desarrollo web. Es una de las piezas centrales del stack LAMP, formado por Linux, Apache, MySQL y PHP. Esa popularidad explica su presencia en innumerables sitios web, su enorme adopción en servicios de servicios de hosting y la cantidad de aplicaciones que la usan como motor de bases de datos. Es apta también para aplicaciones empresariales, herramientas internas y proyectos de todos los tamaños.

MySQL se caracteriza por un enfoque práctico y sencillo, que lo hace ideal para desarrolladores que quieran usar el SGBD sin mayores complicaciones, tanto en el tema del  despliegue y configuración, como en el mantenimiento del día a día.

Aunque comenzó siendo un sistema más modesto que otros, las versiones modernas de MySQL también incluyen características avanzadas como tipos JSON, funciones de ventana, expresiones comunes de tabla, índices de texto completo, procedimientos almacenados, etc.

Casos de uso de PostgreSQL

PostgreSQL es un motor de bases de datos de nivel empresarial, que podría sustituir con suficiencia incluso el poderoso SGBD Oracle. Encaja especialmente bien en sistemas donde el valor principal está en la calidad del modelo de datos y donde la complejidad de las operaciones y las consultas es elevada. También es excelente por la posibilidad de ampliar el motor con capacidades especializadas, existiendo un nutrido ecosistema de soluciones mantenido por su enorme comunidad.

Sistemas financieros y transacciones bancarias con estricta integridad ACID

Igual que Oracle, el ambiente más natural para PostgreSQL son las aplicaciones empresariales y un buen ejemplo de ellas son los sistemas financieros. En este ambiente se necesitan evitar estados intermedios, saldos inconsistentes y modificaciones parciales. Una transferencia de dinero, por ejemplo, no puede descontar una cantidad de una cuenta, sin abonarla correctamente en la cuenta de destino.

PostgreSQL ofrece una base sólida para este tipo de sistemas gracias a su cumplimiento de las propiedades ACID, su soporte de transacciones, sus niveles de aislamiento y su modelo de concurrencia basado en MVCC, o control de concurrencia multiversión.

Además, PostgreSQL permite reforzar reglas de negocio dentro de la base de datos mediante restricciones CHECK, aparte de otros métodos tradicionales como claves foráneas o índices de unicidad. Esto resulta útil cuando la integridad no debe depender exclusivamente de la lógica de la aplicación.

Análisis de datos geoespaciales y cartografía mediante la extensión PostGIS

Otro área especialmente relevante para PostgreSQL es el análisis de datos geoespaciales. Para ello existe una extensión llamada PostGIS que añade soporte avanzado para datos geográficos, geometrías, coordenadas, sistemas de referencia espacial, índices espaciales y funciones de análisis geográfico.

Con PostGIS se pueden almacenar datos específicos que pueden resolver fácilmente consultas sobre elementos geográficos.

Aplicaciones de Inteligencia Artificial y búsqueda vectorial con pgvector

PostgreSQL también está preparado para almacenar embeddings, respondiendo a una de las necesidades frecuentes de las aplicaciones que hacen uso de IA. La extensión pgvector añade a PostgreSQL la capacidad de almacenar vectores, los embeddings, y gracias a ellos comparar significado o similitud semántica más allá de las coincidencias literales de palabras.

Plataformas analíticas complejas y procesamiento de datos masivos

Pero aparte de las aplicaciones basadas en extensiones también es muy destacable sus capacidades nativas para realizar el análisis complejo y procesamiento de datos masivos. Es por ello que resulta ideal para aplicaciones que requieren informes complejos, agregaciones, agrupaciones, filtros dinámicos, funciones de ventana, subconsultas, etc.

También ofrece mecanismos como las vistas materializadas, que permiten precalcular y almacenar el resultado de consultas costosas, de modo que no tengas que recalcular millones de filas cada vez que un usuario realiza una consulta.

Almacenamiento híbrido de datos relacionales y documentos JSON no estructurados

PostgreSQL también destaca por ser uno de los primeros motores de bases de datos relacionales open source que ofreció soporte a JSON. Gracias a este soporte puedes almacenar y mantener entidades con una estructura cambiante.

PostgreSQL permite resolver este escenario mediante columnas tradicionales y campos JSON o JSONB, ofreciendo lo mejor de ambos mundos, el relacional y el documental. Como nota aparte, JSONB es especialmente útil cuando se necesitan consultas e índices sobre el contenido del documento JSON. Este tipo de columna almacena una representación binaria descompuesta orientada a procesar y consultar los datos con mayor eficiencia.

Casos de uso de MySQL

MySQL es una alternativa menor en capacidades pero no por ello inadecuada para contextos profesionales. Su fuerte está en el grado de soporte y en la sencillez de su mantenimiento, además de su amplia comunidad.

Sistemas de gestión de contenidos (CMS) como WordPress, Joomla y Drupal

Donde más vamos a ver MySQL es en el mundo de las aplicaciones de gestión del contenido. Es la base de datos que soporta sistemas tan populares como WordPress. Solo piensa que WordPress es el motor del 40% de las páginas web. Ese dato permite imaginar cuántas instalaciones de MySQL se requieren para soportar esa magnitud de sitios. Bien es cierto que aparte de MySQL WordPress soporta también MariaDB, pero aún así es un volumen monstruoso.

Pero WordPress no es la única herramienta construida alrededor de MySQL, existen muchas otras aplicaciones como Joomla! o Drupal. Y también otras aplicaciones de software libre como Magento o Prestashop por poner dos ejemplos más.

Aplicaciones web orientadas a un alto volumen de lecturas simples

Muchas aplicaciones web realizan un gran número de operaciones de lectura sencillas, como obtener perfiles, cargar listados paginados, consultar contenidos publicados, etc.

Estas consultas son perfectas en MySQL siempre que estén bien combinadas con índices. En este caso podemos usar MySQL incluso para sitios con un muy alto volumen de tráfico.

Servicios en la nube y arquitecturas SaaS de rápido despliegue

MySQL está disponible en prácticamente todos los grandes proveedores cloud y en una enorme variedad de plataformas de despliegue. Esta disponibilidad simplifica la creación de aplicaciones SaaS, que tienen como objetivo lanzar una primera versión viable en poco tiempo.

MySQL también cuenta con soporte amplio en frameworks, ORM, herramientas de migración, paneles de administración y servicios de observabilidad, por lo que resulta ideal para el desarrollo moderno.

Aplicaciones móviles y plataformas sociales con consultas ligeras concurrentes

Las aplicaciones móviles y las plataformas sociales suelen realizar muchas consultas breves y repetitivas. Nuevamente, con una política correcta de índices estas consultas se realizan muy rápido y pueden dar lugar a aplicaciones que soporten una grande carga de trabajo.

De todos modos, cuando una aplicación de este estilo crece, podemos apoyarnos en otras tecnologías como cachés, sistemas de colas, almacenamiento de archivos o gestión de eventos.

Principales diferencias entre PostgreSQL y MySQL

Como hemos dicho, PostgreSQL es una base de datos mucho más sofisticada, con mayores funcionalidades y soporte a tipos y operaciones avanzadas. MySQL afortunadamente ha crecido mucho durante las últimas décadas pero todavía no llega a ese nivel. Veamos algunas diferencias clave:

  • Sistema Objeto-Relacional frente a Relacional puro: A diferencia del modelo tradicional, PostgreSQL permite conceptos avanzados como la herencia de tablas, donde una tabla «hija» puede heredar automáticamente las columnas de una tabla «padre», acercando la base de datos al paradigma de la programación orientada a objetos.
  • MVCC avanzado frente al motor InnoDB de MySQL: Aunque ambos gestores utilizan MVCC para que las lecturas no bloqueen a las escrituras, su arquitectura interna difiere: PostgreSQL almacena las versiones de las filas en la propia tabla principal (requiriendo Autovacuum para limpiar filas muertas), mientras que InnoDB traslada las versiones antiguas a los Undo Logs, liberando la tabla principal de residuos.
  • Soporte de JSONB binario frente al tipo JSON nativo: El formato JSON está soportado por ambos sistemas pero el JSONB de PostgreSQL va un paso más allá, permitiendo operaciones avanzadas para el procesamiento, filtrado e indexado de documentos JSON.
  • Creación de funciones y tipos propios frente a plugins de motor: Mientras MySQL es más rígido con sus procedimientos almacenados estándar, PostgreSQL permite a los desarrolladores backend escribir lógica en la propia base de datos utilizando lenguajes de programación externos como Python (PL/Python), Perl, o incluso Rust.
  • Conexiones basadas en procesos frente a hilos de ejecución (threads): PostgreSQL asigna un proceso completo del sistema operativo a cada nueva conexión, lo que consume más memoria RAM por usuario. MySQL, en cambio, usa un modelo de hilos (threads) más ligero. Por esta razón, PostgreSQL necesita un mayor grado de optimización y complementos como un pooler de conexiones.
  • Rigor sintáctico y nivel de cumplimiento de los estándares oficiales de SQL: El rigor sintáctico y nivel de cumplimiento de PostgreSQL es más rígido que el de MySQL, que es más flexible.
  • Licencia de software, gobernanza comunitaria y modelo de propiedad corporativa: MySQL actualmente pertenece a Oracle y se ofrece bajo un modelo de licencia dual (lo que en su día provocó alarma por parte de la comunidad). PostgreSQL, siempre se ha regido por su propia licencia libre más cerca de la comunidad global, sin estar atado a los intereses de ninguna gran corporación tecnológica.

En los próximos apartados vamos a ver otra serie de diferencias, pero ya centrados en diversas particularidades del mundo de las bases de datos.

PostgreSQL vs. MySQL en alta disponibilidad y arquitectura de replicación

La alta disponibilidad es sin duda algo vital para muchas aplicaciones y ambas bases de datos tienen diferencias palpables. Aunque hay que advertir que no depende únicamente de elegir PostgreSQL o MySQL, en realidad requiere diseñar una arquitectura completa: redundancia de nodos, replicación, balanceo de conexiones, supervisión, copias de seguridad verificadas, procedimientos de recuperación y una estrategia clara para evitar o resolver conflictos de escritura.

En el fondo podríamos conseguir ese objetivo con ambos motores aunque el grado de flexibilidad de cada uno cambiará y también las herramientas del ecosistema varían bastante.

Replicación física y lógica

En lo que respecta replicación física y lógica PostgreSQL ofrece ambas aproximaciones de una manera bien separada, por lo que podríamos implementar cualquiera de estos tipos de replicación según nuestros objetivos.

Sin embargo, MySQL basa su replicación tradicional en el binary log, o binlog, donde un servidor origen registra los cambios y uno o más servidores réplica los reciben y aplican. Por tanto, no existe una diferencia entre ambos enfoques (físico y lógico). Esto de todos modos no quiere decir que MySQL no cuente con una infraestructura madura alrededor del binlog para hacer réplicas.

Replicación multi-primario

La replicación multi-primario permite que varios nodos acepten escrituras, lo que puede ser atractivo ya que elimina la dependencia de un único servidor principal. Sin embargo, también añade complejidad.

MySQL ofrece Group Replication, una tecnología diseñada para mantener un grupo de servidores que coordinan transacciones. Puede operar en modo single-primary, donde un nodo acepta escrituras y los demás actúan como réplicas, o en modo multi-primary, donde varios miembros pueden recibir operaciones de escritura.

PostgreSQL no incorpora en el núcleo una solución multi-primario general equivalente a Group Replication. Su patrón nativo más habitual es el de un primario que recibe escrituras y una o varias réplicas físicas o lógicas que pueden servir lecturas o asumir el rol principal tras un failover. Si queremos algo parecido en PostgreSQL tendríamos que acudir a soluciones de terceros para replicación multi-master.

Estrategias de recuperación ante desastres (PITR)

PITR significa Point-In-Time Recovery o recuperación a un instante determinado. Es una estrategia que permite restaurar una base de datos a un momento anterior, por ejemplo, justo antes de un borrado accidental, una migración defectuosa o una operación masiva ejecutada por error.

En PostgreSQL podemos conseguir el objetivo de PITR mediante una copia base completa del clúster y archivos WAL generados después de esa copia. Por su parte, MySQL ofrece una estrategia equivalente que se apoya habitualmente en copias de seguridad completas y binary logs, aunque no es tan directa.

Herramientas de conmutación por error (Failover)

El failover es el proceso mediante el que un nodo secundario asume la función de primario cuando el servidor principal deja de estar disponible, proceso que puede hacerse de forma manual, semiautomática o automática.

En PostgreSQL se utilizan herramientas de orquestación y supervisión, como Patroni, repmgr, pg_auto_failover o soluciones basadas en un gestor de consenso externo. Estas herramientas suelen encargarse de vigilar la salud de los nodos, elegir un candidato, promoverlo, actualizar la topología y facilitar la reincorporación de servidores recuperados.

En MySQL, las opciones frecuentes incluyen MySQL Router, MySQL InnoDB Cluster, Group Replication, MySQL Shell y herramientas de orquestación como Orchestrator. En configuraciones basadas en Group Replication, el grupo mantiene información sobre los miembros y puede ayudar a gestionar la disponibilidad de los nodos.

PostgreSQL vs. MySQL para Inteligencia Artificial, vectores y extensibilidad

Las aplicaciones de Inteligencia Artificial pueden usar bases de datos para hacer algunas operaciones, como el almacenamiento y búsqueda de vectores. Aquí PostgreSQL suele ofrecer más flexibilidad para concentrar estas necesidades en una misma plataforma.

Búsqueda de vectores para IA

La búsqueda vectorial permite encontrar elementos similares utilizando embeddings. Un embedding es un vector numérico que representa características semánticas de un contenido, como un fragmento de texto, una imagen, una consulta, un producto o una transcripción.

PostgreSQL puede incorporar esta capacidad mediante pgvector, una extensión que permite almacenar vectores en columnas, calcular distancia o similitud y crear índices aproximados para acelerar las búsquedas a gran escala.

MySQL no ofrece en su núcleo una extensión equivalente a pgvector, por lo que tendrías que delegar operaciones en tecnologías externas.

Búsqueda de texto completo (Full-Text Search)

La búsqueda de texto completo permite localizar documentos según las palabras y expresiones que contienen, aplicando mecanismos como tokenización, normalización, relevancia, operadores booleanos y ranking de resultados.

En este caso ambas bases de datos incluyen esta característica, por lo que la elección de una u otra es indiferente.

Ecosistema de extensiones y plugins de desarrollo

En este caso PostgreSQL es un claro ganador, primero porque fue concebido como un sistema extensible pero también porque tiene un background mucho más amplio de creadores de extensiones, que lo usan como motor para la más variada gama de operaciones.

En MySQL también existe un ecosistema importante de herramientas externas para backup, observabilidad, proxy, gestión de clústeres, análisis de rendimiento y administración, pero al tratarse de un motor de base de datos de licencia dual no tiene una comunidad tan fuerte creando este tipo de complementos.

Procedimientos almacenados y lenguajes soportados

Los procedimientos almacenados también son importantes para algunos tipos de aplicaciones. Ambos sistemas los soportan pero PostgreSQL, nuevamente, es mucho más versátil en este sentido. De casa incluye PL/pgSQL como lenguaje procedimental principal, pero puedes ampliar los lenguajes disponibles mediante extensiones

PostgreSQL vs. MySQL en seguridad, cifrado y control de accesos

La seguridad de una base de datos tiene muchas facetas y tanto PostgreSQL como MySQL pueden utilizarse en entornos con requisitos de seguridad elevados. Sin embargo, como ya venimos explicando, PostgreSQL incorpora generalmente más funcionalidades o variantes más potentes.

Seguridad a nivel de fila (Row-Level Security – RLS)

La seguridad a nivel de fila, o RLS, permite definir políticas que limitan qué registros puede leer, insertar, actualizar o eliminar cada usuario o rol. Por ejemplo esta característica es muy interesante en sistemas «multi-tenant», por ejemplo para que un usuario de un SaaS no pueda ver facturas de otro usuario del SaaS.

PostgreSQL integra RLS de forma nativa y permite definir políticas específicas para selección, inserción, actualización y borrado. Infelizmente para los usuarios de MySQL no existe de un mecanismo RLS nativo equivalente, basado en políticas de fila aplicadas de forma general por el motor.

Cifrado de datos en reposo y en tránsito

El cifrado en tránsito protege los datos mientras viajan entre la aplicación, la base de datos, las réplicas y otros servicios. Ambos motores implementan sus mecanismos. PostgreSQL admite conexiones TLS y permite definir reglas de acceso donde se puede controlar qué usuarios, bases de datos, redes y métodos de autenticación están permitidos. Por su parte, MySQL ofrece soporte para conexiones cifradas y dispone de mecanismos de cifrado para InnoDB, tablespaces, redo logs y binary logs, según la versión, edición y configuración utilizada.

Auditoría de consultas y cumplimiento de GDPR/HIPAA

El cumplimiento de normativas como GDPR, HIPAA u otras regulaciones sectoriales no depende de una base de datos que usemos por lo que ambas son perfectamente usables en este sentido.

De todos modos, para comprobaciones más en detalle PostgreSQL puede complementarse con extensiones y herramientas de auditoría que registran operaciones SQL, accesos, cambios de esquema y actividad de usuarios. En MySQL podemos hacer estas operaciones un poco más a bajo nivel, a través de registros como el general query log, el slow query log, el error log y el binary log.

Gestión de roles, usuarios y permisos avanzados

Aquí nuevamente veremos que PostgreSQL es más poderoso, ya que aparte de usuarios implementa también un modelo de roles. Un rol puede actuar como usuario con capacidad de inicio de sesión, como grupo de permisos o como ambas cosas. Los privilegios pueden concederse sobre bases de datos, esquemas, tablas, columnas, secuencias, funciones y otros objetos.

MySQL gestiona usuarios y privilegios pero no tiene la versatilidad que te ofrecen los roles de PostgreSQL.

PostgreSQL vs. MySQL en tareas de administración y mantenimiento DBA

La administración de bases de datos también varía bastante, no solo en lo que respecta a posibilidades, sino en curva de aprendizaje. PostgreSQL y MySQL tienen necesidades de mantenimiento muy distintas en este sentido.

VACUUM en PostgreSQL vs. OPTIMIZE TABLE en MySQL

PostgreSQL usa MVCC para gestionar la concurrencia. Cuando una fila se actualiza o elimina, la versión anterior no desaparece inmediatamente en todos los casos. Permanece durante un tiempo para que transacciones concurrentes puedan mantener una visión consistente de los datos. Es por ello que requiere un procedimiento de VACUUM, que limpia versiones de filas que ya no son necesarias y ayuda a evitar el crecimiento excesivo de tablas e índices. Si lo deseas, PostgreSQL incluye autovacuum, un mecanismo automático que supervisa las tablas y ejecuta tareas de limpieza y análisis según determinados umbrales.

En MySQL con InnoDB, las operaciones de actualización y borrado también pueden generar fragmentación o espacio no aprovechado según el patrón de uso. En estos casos podemos usar comandos de OPTIMIZE TABLE, que permiten reorganizar tablas y recuperar espacio en determinadas circunstancias, aunque su comportamiento depende del motor de almacenamiento y de la versión.

De todos modos, no quiere decir que OPTIMIZE TABLE se deba incluir como una tarea periódica automática aplicable a todas las tablas. Por eso no creemos que exista una comparación directa entre VACUUM y OPTIMIZE, son mecanismos distintos que tienen requisitos de funcionamiento dispares.

Herramientas gráficas de gestión

Las herramientas con interfaz gráfica simplifican la vida del día a día para la administración y el diagnóstico, sobre todo cuando estamos desarrollando. Ambos motores tienen herramientas diversas, incluyendo muchas que son capaces de funcionar con ambos motores.

Para PostgreSQL, pgAdmin es una de las herramientas más populares. Es una herramienta de escritorio muy madura que incluye una cantidad enorme de funcionalidades específicas para este motor. Por su parte en el ecosistema MySQL se usa mucho las herramientas web donde PhpMyAdmin es el mayor exponente.

De todos modos, hay muchas herramientas que puedes usar para acceder a ambos motores (de hecho, soportan muchos motores de bases de datos, aparte de MySQL y PostgreSQL). Algunas alternativas populares son DBeaver, DbGate, DataGrip, TablePlus, etc.

Análisis de rendimiento y monitorización de Slow Queries

Ambos sistemas cuentan con la herramienta EXPLAIN para inspeccionar los planes de ejecución de las consultas, pero no son igual de potentes. PostgreSQL ofrece un nivel de detalle, métricas de rendimiento y profundidad técnica sensiblemente superior al que te aporta MySQL.

Estrategias de migración de datos sin tiempo de inactividad

Este es otro punto donde PostgreSQL está mucho más evolucionado, gracias a su soporte nativo para transacciones DDL y la capacidad de construir o reestructurar objetos sin bloquear operaciones de escritura (CREATE INDEX CONCURRENTLY o restricciones NOT VALID). Por su parte, MySQL depende de la replicación por registros binarios (binlog/GTID) para mantener sincronizadas las instancias en tiempo real.

En fin, como puedes ver, PostgreSQL suele estar siempre un poco por delante, pero no todos los tipos de proyecto sacarán ventaja por ello. Si pensamos en la complejidad de administración y optimización, además de los recursos extra que requiere PostgreSQL, entenderemos que decidirse por MySQL puede ser también un acierto en muchas ocasiones.

Fernán García de Zúñiga

Productos relacionados: