Po­s­t­gre­S­QL y MySQL son dos de los sistemas de gestión de bases de datos de código abierto más uti­li­za­dos. Mostramos sus si­mi­li­tu­des y di­fe­re­n­cias y ex­pli­ca­mos cuál de las dos he­rra­mie­n­tas es la más adecuada para cada caso de uso.

Un vistazo a Po­s­t­gre­S­QL vs. MySQL

Po­s­t­gre­S­QL y MySQL son sistemas de gestión de bases de datos (DBMS, por sus siglas en inglés). Para la mayoría de las apli­ca­cio­nes prácticas, los dos sistemas tienen más si­mi­li­tu­des que di­fe­re­n­cias. Sin embargo, la co­m­pa­ra­ción Po­s­t­gre­S­QL vs. MySQL muestra algunas sutiles di­fe­re­n­cias que se traducen en ventajas y de­s­ve­n­ta­jas es­pe­cí­fi­cas.

Consejo

Puedes encontrar más in­fo­r­ma­ción sobre ambos sistemas en nuestros artículos es­pe­cí­fi­cos:

En primer lugar, Po­s­t­gre­S­QL y MySQL se basan en el lenguaje de pro­gra­ma­ción SQL como interfaz central para in­ter­ac­tuar con bases de datos y los datos que estas contienen. La más conocida es pro­ba­ble­me­n­te la sentencia SELECT, que se utiliza para ejecutar consultas, la cual permite encontrar los datos y acceder a la in­fo­r­ma­ción que se necesita. Además, hay varios comandos SQL que sirven para controlar el DBMS.

El rango de funciones de SQL se define en varias normas. Las im­ple­me­n­ta­cio­nes más ha­bi­tua­les cubren más o menos bien los es­tá­n­da­res. Si co­m­pa­ra­mos Po­s­t­gre­S­QL vs. MySQL, Po­s­t­gre­S­QL es más potente y soporta una gama más amplia de funciones que MySQL.

Consejo

¿El tema de SQL es nuevo para ti? En ese caso, lo mejor es que empieces con nuestra in­tro­du­c­ción a SQL con ejemplos.

Una di­fe­re­n­cia im­po­r­ta­n­te entre Po­s­t­gre­S­QL y MySQL es su ar­qui­te­c­tu­ra básica. En primer lugar, ambos son sistemas de gestión de bases de datos re­la­cio­na­les (RDBMS). Sin embargo, Po­s­t­gre­S­QL puede hacer mucho más, ya que se trata de un DBMS re­la­cio­nal de objetos (ORDBMS). A co­n­ti­nua­ción, te ex­pli­ca­mos cuál es exac­ta­me­n­te la di­fe­re­n­cia.

Ambos DBMS parten de un motor de al­ma­ce­na­mie­n­to. Se trata de una interfaz para almacenar datos en medios físicos. Se utilizan índices que permiten re­fe­re­n­ciar entradas in­di­vi­dua­les de la base de datos para obtener un acceso de alto re­n­di­mie­n­to. Existen varios motores de al­ma­ce­na­mie­n­to y métodos de in­de­xa­ción; cada uno con sus propias ventajas e in­co­n­ve­nie­n­tes.

Consejo

Po­s­t­gre­S­QL y MySQL son sistemas de gestión de bases de datos de código abierto y, por tanto, co­n­tra­s­tan con los productos pri­va­ti­vos de grandes pro­vee­do­res como Microsoft o IBM. Además, hay muchos otros DBMS de código abierto. A co­n­ti­nua­ción, te pre­se­n­ta­mos una co­m­pa­ra­ti­va de las bases de datos de código abierto más im­po­r­ta­n­tes.

MySQL: el clásico RDBMS de código abierto

MySQL fue de­sa­rro­lla­do a mediados de los años 90 por la empresa MySQL AB en Suecia, que fue adquirida por Sun Mi­cro­s­y­s­te­ms en 2008 y por Oracle en 2010. Debido a la de­s­co­n­fia­n­za que siente la comunidad de código abierto hacia Oracle, el software de la base de datos se forkeó como “MariaDB”. De este modo, se ga­ra­n­ti­za­ba que el proyecto se ma­n­tu­vie­ra bajo una licencia de código abierto.

En los años de auge de la todavía nueva World Wide Web, MySQL ganó fama como co­m­po­ne­n­te del om­ni­pre­se­n­te LAMP Stack. De esta forma, el software de la base de datos se pro­po­r­cio­na junto con Linux, Apache y PHP como parte de la mayoría de los paquetes de hosting online. Durante su expansión, MySQL se convirtió en el estándar de los proyectos web con base de datos re­la­cio­nal su­b­ya­ce­n­te.

Po­s­t­gre­S­QL: la potente al­te­r­na­ti­va re­la­cio­nal de objetos

Po­s­t­gre­S­QL se concibió ini­cia­l­me­n­te con el nombre de “Postgres”, como sucesor del DBMS Ingres. Se de­sa­rro­lló a mediados de los años 80 en la Uni­ve­r­si­dad de Ca­li­fo­r­nia, Berkeley y su código se publicó bajo la licencia “Berkeley Software Di­s­tri­bu­tion” (BSD). A mediados de los años 90, se cambió a SQL como interfaz uniforme, de la mano de un cambio de nombre a “Po­s­t­gre­S­QL”. Ambos nombres se siguen uti­li­za­n­do hoy en día.

Según el propio IBM, Po­s­t­gre­S­QL es:

Cita

“One of the most compliant, stable and mature re­la­tio­nal databases available today and can easily handle complex queries.” – Fuente: https://www.ibm.com/cloud/blog/po­s­t­gre­s­ql-vs-mysql-whats-the-di­f­fe­re­n­ce
Tra­du­c­ción: “Una de las bases de datos re­la­cio­na­les más estables y co­n­so­li­da­das que existen en la ac­tua­li­dad y que puede gestionar fá­ci­l­me­n­te consultas complejas” (traducido por IONOS)

La co­m­pa­ra­ción: Po­s­t­gre­S­QL vs. MySQL

En primer lugar, tanto Po­s­t­gre­S­QL como MySQL permiten trabajar con bases de datos re­la­cio­na­les. Ambos sistemas entienden los comandos SQL que permiten crear, modificar y llenar tablas, así como realizar consultas. Además, si se compara Po­s­t­gre­S­QL con MySQL, ob­se­r­va­mos di­fe­re­n­cias fu­n­da­me­n­ta­les en términos de fu­n­cio­na­li­dad. Estas di­fe­re­n­cias se deben a su diferente ar­qui­te­c­tu­ra.

Mientras que MySQL es un sistema de gestión de bases de datos puramente re­la­cio­nal (RDBMS), Po­s­t­gre­S­QL es un DBMS re­la­cio­nal de objetos (ORDBMS). Así pues, Po­s­t­gre­S­QL soporta una serie de conceptos conocidos de la pro­gra­ma­ción orientada a objetos. Entre ellos se en­cue­n­tran los tipos de datos definidos por el usuario, los tipos de datos co­m­pue­s­tos y la herencia. Po­s­t­gre­S­QL es más potente que MySQL, pero también más complejo.

Propiedad del DBMS Po­s­t­gre­S­QL / ORDBMS MySQL / RDBMS
Múltiples datos por campo Admitidos como arrays Requiere una tabla separada y join
relación m:n Di­re­c­ta­me­n­te moldeable Requiere tablas adi­cio­na­les y join
Herencia Di­re­c­ta­me­n­te moldeable Requiere una solución/vista compleja, múltiples tablas, etc.
Datos je­rá­r­qui­cos Mediante JSON, HStore y XML Solamente JSON
Valores booleanos Tipo de datos propios Im­ple­me­n­ta­ción como TINYINT(1)

Tipos de datos

Los tipos de datos son la base de un diseño de base de datos sólido y de su correcta apli­ca­ción. Cuando se diseñan tablas, se es­pe­ci­fi­ca para cada columna qué tipo de datos deben contener. Existen los si­guie­n­tes tipos de datos:

Tipo de datos Po­s­t­gre­S­QL MySQL
Valores booleanos Po­s­t­gre­S­QL reconoce un tipo de datos booleano propio. MySQL toma un desvío: en vez de im­ple­me­n­tar los valores booleanos como tipo de datos propio, los booleanos se almacenan como números del tipo TINYINT(1).
Ranges Po­s­t­gre­S­QL soporta un gran número de tipos de range, lo que facilita trabajar con valores ordinales. MySQL no soporta ranges de primeras. Si se necesitan, hay que tirar de al­te­r­na­ti­vas caseras.
Geodatos Po­s­t­gre­S­QL incluye la extensión de código abierto PostGIS, que vale como una de las im­ple­me­n­ta­cio­nes GIS más maduras. Desde la versión 8, MySQL soporta geodatos y sus consultas, aunque el alcance de sus funciones es más reducido que el de Po­s­t­gre­S­QL.
Arrays Po­s­t­gre­S­QL soporta arrays como un ORDBMS. Con las matrices de Po­s­t­gre­S­QL, se pueden almacenar múltiples valores en un campo. MySQL no soporta este tipo de datos.
Datos je­rá­r­qui­cos / JSON Po­s­t­gre­S­QL soporta JSON como tipo de datos. Así, se acomoda una es­tru­c­tu­ra de datos compleja e in­te­r­ca­la­da je­rá­r­qui­ca­me­n­te en un solo campo. MySQL también soporta JSON como tipo de datos pero no es tan potente como Po­s­t­gre­S­QL.

Re­n­di­mie­n­to

El re­n­di­mie­n­to de las bases de datos es una cuestión muy compleja. Ge­ne­ra­l­me­n­te, los distintos DBMS ofrecen ciertas ventajas y de­s­ve­n­ta­jas en función de su ámbito de uso. Como norma, se considera que MySQL tiene un re­n­di­mie­n­to muy alto, es­pe­cia­l­me­n­te cuando la base de datos es “read-heavy”, es decir, pri­n­ci­pa­l­me­n­te de lectura. Este suele ser el caso de los Content Ma­na­ge­me­nt Systems como WordPress, que leen el contenido de la base de datos y lo entregan a los vi­si­ta­n­tes.

A di­fe­re­n­cia de MySQL, Po­s­t­gre­S­QL suele ofrecer un mayor re­n­di­mie­n­to en las ope­ra­cio­nes “write-heavy”. Además, el ORDBMS se considera más adecuado para so­lu­cio­nes de al­ma­ce­na­mie­n­to de datos y otros sistemas de “Online Ana­l­y­ti­cal Pro­ce­s­si­ng” (OLAP). Po­s­t­gre­S­QL soporta múltiples co­ne­xio­nes con sus propios procesos, pero esto conlleva mayores re­qui­si­tos de memoria.

Seguridad y di­s­po­ni­bi­li­dad

Lo ideal es que los DBMS re­la­cio­na­les ga­ra­n­ti­cen la co­he­re­n­cia y la di­s­po­ni­bi­li­dad de los datos al­ma­ce­na­dos. Esto también se conoce como pro­pie­da­des “ACID”. Po­s­t­gre­S­QL soporta las pro­pie­da­des ACID al completo. En el caso de MySQL esto también es cierto en mayor o menor medida, de­pe­n­die­n­do del motor de al­ma­ce­na­mie­n­to utilizado.

La situación es similar en lo que respecta al “Mu­l­ti­ve­r­sion Co­n­cu­rre­n­cy Control” (MVCC), que garantiza la co­he­re­n­cia de los datos en caso de accesos si­mu­l­tá­neos a la base de datos. En el caso de Po­s­t­gre­S­QL MVCC ya viene incluido, mientras que en el caso de MySQL depende del motor de al­ma­ce­na­mie­n­to. En términos de seguridad, MySQL ofrece buenas co­n­di­cio­nes con la en­cri­p­ta­ción TLS. Po­s­t­gre­S­QL todavía utiliza el estándar SSL, que es más antiguo.

Ad­mi­ni­s­tra­ción

Un aspecto im­po­r­ta­n­te del uso de DBMS es el soporte de di­fe­re­n­tes in­te­r­fa­ces de ad­mi­ni­s­tra­ción. Tanto Po­s­t­gre­S­QL como MySQL tienen una interfaz de línea de comandos (Command Line Interface, CLI) con psql y mysql re­s­pe­c­ti­va­me­n­te. Las he­rra­mie­n­tas de la CLI pueden uti­li­zar­se para co­ne­c­tar­se a la base de datos y ejecutar el código SQL a partir de la entrada directa o de un archivo script.

Además de las in­te­r­fa­ces de línea de comandos, Po­s­t­gre­S­QL y MySQL tienen in­te­r­fa­ces gráficas de usuario (Graphical User Interface, GUI) nativas y basadas en la web. Otro punto im­po­r­ta­n­te son las he­rra­mie­n­tas es­pe­cí­fi­cas de im­po­r­ta­ción y ex­po­r­ta­ción. Permiten crear y restaurar copias de seguridad de las bases de datos. Po­s­t­gre­S­QL incorpora las he­rra­mie­n­tas pg_dump y pg_restore, que como copias de seguridad son más potentes que una copia de seguridad de MySQL hecha con la he­rra­mie­n­ta MySQL Dump.

Admin Tool Po­s­t­gre­S­QL MySQL
CLI Client psql mysql
Web GUI ph­p­P­gA­d­min ph­p­M­yA­d­min
Native GUI pgAdmin MySQL Workbench

¿En qué casos se utiliza Po­s­t­gre­S­QL y MySQL?

Como hemos visto, al comparar Po­s­t­gre­S­QL vs. MySQL existen profundas di­fe­re­n­cias. Entonces, ¿cuál de los dos sistemas de gestión de bases de datos debes utilizar en tu propio proyecto? Afo­r­tu­na­da­me­n­te, la respuesta es sencilla: El uso de Po­s­t­gre­S­QL tiene sentido si la base de datos tiene re­qui­si­tos es­pe­cia­les. Si no es el caso, MySQL suele ser su­fi­cie­n­te.

En otras palabras, se puede confiar en Po­s­t­gre­S­QL para im­ple­me­n­tar el sitio web de un banco o una in­s­ti­tu­ción de vital im­po­r­ta­n­cia, ya que en este caso, que cumpla ín­te­gra­me­n­te con ACID merece la pena y los elevados re­qui­si­tos de es­ta­bi­li­dad y co­n­si­s­te­n­cia de los datos ju­s­ti­fi­can la mayor co­m­ple­ji­dad del ORDBMS. Además, dispone de recursos su­fi­cie­n­tes para un entorno Po­s­t­gre­S­QL de alto re­n­di­mie­n­to.

Otro ámbito de uso de Po­s­t­gre­S­QL es cuando la ar­qui­te­c­tu­ra del proyecto requiere la gestión de modelos de datos so­fi­s­ti­ca­dos. Si deseas asignar je­ra­r­quías de objetos complejas o si se requiere la herencia como co­m­po­ne­n­te central del modelo de datos, conviene utilizar el potente ORDBMS. En concreto, es posible ahorrarse tener que usar el mapeo objeto-re­la­cio­nal (Object-re­la­tio­nal Mapping, ORM).

Para proyectos web de tamaño pequeño o mediano, es mejor utilizar MySQL. Este RDBMS consume menos recursos del servidor. También es más fácil encontrar un ad­mi­ni­s­tra­dor de MySQL ex­pe­ri­me­n­ta­do y eco­nó­mi­ca­me­n­te asequible. El gran re­n­di­mie­n­to en la lectura de datos de la base de datos se adapta bien a los sitios web y a las tiendas online con no de­ma­sia­das exi­ge­n­cias.

Por último, pero no por ello menos im­po­r­ta­n­te, notemos que Po­s­t­gre­S­QL y MySQL pueden sin duda uti­li­zar­se en tándem. Esto es es­pe­cia­l­me­n­te in­te­re­sa­n­te para las so­lu­cio­nes de al­ma­ce­na­mie­n­to de datos. No­r­ma­l­me­n­te, en una co­n­fi­gu­ra­ción de este tipo se utilizan una o más in­s­ta­n­cias de MySQL orie­n­ta­das al exterior. Recogen los datos y los tra­n­s­mi­ten a una in­s­ta­la­ción central de Po­s­t­gre­S­QL situada detrás de ellos, sobre la que se ejecutan las eva­lua­cio­nes y los análisis.

Consejo

Lee también nuestra co­m­pa­ra­ti­va MariaDB vs. MySQL.

Ir al menú principal