MySQL vs PostgreSQL 12

Elegir entre MySQL y PostgreSQL es una decisión la cual muchos deben hacer cuando a bases de datos relacionales de fuente abierta se refiere. Ambos servidores son soluciones comprobadas al paso del tiempo y que compiten fuertemente con la base de datos de software propietario. MySQL ha sido durante mucho tiempo la más rápida pero es la que cuenta con menos funciones de los dos sistemas de bases de datos, mientras que PostgreSQL se supone que es un sistema de base de datos más denso, la cual a menudo se describe como la version de código abierto de Oracle.

MySQL ha sido popular entre diversos proyectos de software debido a su velocidad y facilidad de uso, mientras que PostgreSQL es utilizada mayormente por desarrolladores que provienen de un Oracle u otro SQL Server.

Estas hipótesis, sin embargo, son en su mayorí­a obsoletas e incorrectas. MySQL ha recorrido un largo camino en la adición de funcionalidades avanzadas, mientras que PostgreSQL ha mejorado enormemente su velocidad en los últimos lanzamientos.

Muchos, sin embargo, no son conscientes de la convergencia y todaví­a se aferran a los estereotipos basados en MySQL 4.1 y PostgreSQL 7.4.

Además, la comparacion de velocidad son principalmente entre los motores de MyISAM y PostgreSQL. Si la comparación se realiza entre las últimas versiones de InnoDB y PostgreSQL, PostgreSQL es a menudo más rápido.

Rendimiento

Los Sistemas de bases de datos pueden ser optimizados de acuerdo con el entorno en el que corren. Por lo tanto, es muy difí­cil dar una comparación precisa en el rendimiento, sin prestar atención a la configuración y el medio ambiente. PostgreSQL asi como MySQL emplean diversas tecnologí­as para mejorar el rendimiento en el nivel básico:

Comienzos

MySQL comenzó su desarrollo con un enfoque en la velocidad, mientras que PostgreSQL comenzó a desarrollar con un enfoque sobre las caracterí­sticas y normas. Por lo tanto, MySQL es a menudo considerado como el más rápido de los dos. La configuración por defecto de PostgreSQL fue diseñada para ejecutarse en sistemas con poca memoria.

Raw Speed

El motor MyISAM de MySQL funciona más rápido que PostgreSQL sobre los queries simples y cuando la concurrencia es baja o sigue ciertos patrones (por ejemplo, los inserts se realizan en tablas optimizadas y sin bloqueos, count (*) es muy rápido).

El costo de la velocidad del motor MyISAM viene de no brindar soporta a las transacciones, llaves foráneas, y no ofrece durabilidad garantizada en los datos.

Compresión de datos

PostgreSQL puede comprimir y descomprimir sus datos sobre la marcha con un rápido sistema de compresión para encajar más datos en un espacio de disco asignado. La ventaja de los datos comprimidos, además de ahorrar espacio en disco, es que la lectura de datos tarda menos IO, por lo que lee datos con mayor rapidez.

Hasta la version 5.1 de MySQL sus motores de almacenamiento de alto rendimiento no soportan compresión sobre la marcha.

La verion de MySQL 6.0 tendra soporte de compresión sobre la marcha con su nuevo motor de almacenamiento Falcon:

Los datos almacenados en las tablas de Falcon están comprimidos en el disco, pero se almacena en un formato sin comprimir en la memoria. La compresión se produce automáticamente cuando los datos se guardan al disco.

— MySQL AB , 12.6.6.6. – Compresión de datos

Con InnoDB instalado a traví©s del plug-in, MySQL 5.1 soporta compresión sobre la marcha de tablas InnoDB:

A partir de esta versión del plug-in de InnoDB, se puede utilizar los atributos ROW_FORMAT=COMPRESSED o KEY_BLOCK_SIZE en los comandos CREATE TABLE y ALTER TABLE para solicitar a InnoDB comprimir cada página a 1K, 2K, 4K, 8K, o de 16K bytes.
— InnoBASE OY , 3.2. Especificación de compresión

El motor MyISAM de MySQL soporta compresión del í­ndice el cual utiliza por defecto en cierta medida. Una mejor compresión puede ser adquirida mediante el uso de la opción PACK_KEYS. Otros motores de almacenamiento estables en MySQL al momento no tienen esta caracterí­stica, por lo que sus í­ndices utilizan más espacio.

Las tablas en el motor MyISAM pueden ser empacados con myisampack lo que las convierte en solo lectura, pero ahorra mucho espacio. MySQL tambií©n soporta compresión a nivel de protocolo de red la cual es una opción que puede ser activada por el cliente si el servidor lo permite. Esto comprime todo dese y hacia el servidor.

MySQL soporta compresión sobre la marcha desde la versión 5.0 con el motor de almacenamiento ARCHIVE. Archive es un motor de almacenamiento de escribir una vez, leer muchas, diseñado para los datos históricos. Comprime los datos hasta un 90%. No soprota í­ndices. Sin embargo, en la versión 5.1 puede ser utilizado con particionado.

Multi-procesador

La ventaja en velocidad de PostgreSQL sobre MySQL se puede ver drásticamente en un ambiente de grandes procesadores multi-core.
[1] Incluso los desarrolladores de MySQL han admitido que el uso actual de tecnologia de procesadores con multiples nucleos de MySQL no está a la par.
[2] Los recientes parches de Google y Percona son una promesa para cerrar la brecha.

Velocidad Configurada

PostgreSQL proporciona caracterí­sticas que pueden conducir a un rendimiento más rápido en algunos queries:

  • Indexación parcial
  • TOAST de compresión de datos
  • Una mayor asignación de memoria de forma predeterminada en las últimas versiones de sistemas capaces
  • Mejora de la gestión de cachí© en las versiones 8.1 y 8.2

MySQL tambií©n soporta la indexación parcial utilizando el motor InnoDB, pero no con el motor MyISAM. Incluso cuando se utiliza el motor InnoDB, sin embargo, las tablas del sistema utiliza el motor MyISAM.

Si bien es cierto que con una instalación por defecto de MySQL, este por lo regular le gana a PostgreSQL en muchos parámetros de rendimiento, benchmarks pasados mostrando un mayor rendimiento de MySQL ante PostgreSQL tienden a sufrir una serie de problemas:

  • No era raro ver a un servidor MySQL afinado para rendimiento el cual se enfrentara contra un servidor PostgreSQL con la configuracion por defecto y sin afinar.
  • Al comparar los benchmarks a menudo agrupaban transacciones modales poco realistas que no reflejan el comportamiendo de las aplicaciones en el mundo real, lo que lleva a un desajuste en el número de operaciones discretas se están llevando a cabo en un tiempo y las relaciones entre ellos de una base de datos a la siguiente.
  • Las “transacciones” de MyISAM que no cumplen con el estandar ACID a menudo son comparadas contra PostgreSQL ejecutando transacciones compatibles con ACID.
  • Si bien esto resultaba a menudo en un mayor rendimiento en los benchmarks, tambien involucraba sistemas de pruebas haciendo cosas muy diferentes.
  • Si la integridad transaccional es de suma importancia para usted, mayor rendimiento sin garantia en la integridad transaccional no son una opción en absoluto.
  • El rendimiento de MyISAM ha sido optimizado para un solo un usuario. Esto significó una victoria para MySQL usando MyISAM en muchos puntos de referencia.
  • En virtud del uso, sin embargo, con muchos usuarios concurrentes, la utilizacion del control de bloqueos de tablas de MyISAM he mostrado un dramático efecto negativo en el rendimiento como el número de usuarios creció – lo cual no se ha abordado a menudo por los benchmarks de comparativos.

Concurrencia

PostgreSQL escala mucho mejor, tanto en tí©rminos de la utilización de un hardware de alto rendimiento, y al hacer frente a la concurrencia. MySQL, por otra parte, se centra en tecnologí­as comunes de bajo rendimiento y el uso de hardware básico.

Así­ncrona I/O

PostgreSQL soporta una completa API asincrónica para el uso de las aplicaciones cliente. Según se informa, aumenta el rendimiento hasta en un 40% en algunos casos. MySQL carece de soporte Async, aunque algunos controladores se han creado para tratar de superar esta deficiencia (perl ruby).

COUNT(*)

PostgreSQL COUNT(*) es muy lento porque en lugar de contar las filas utilizando un í­ndice de exploración, debe de recorrer toda la tabla secuencialmente. PostgreSQL implementa COUNT(*) de esta manera debido a la forma en la cual el MVCC (sistema de concurrencia del PostgreSQL) almacena la visibilidad de las transacciónes en la fila de datos y no en el í­ndice.

El motor MyISAM en MySQL utiliza un í­ndice para COUNT(*) y tambií©n un cache de la cuenta y por lo tanto, es mucho más rápido:

La razón MySQL tiene cuenta rápidamente, es porque, están en cachí©. Esto funciona porque en MySQL se utilizan INSERTs con número de serie, pero las DBs de grado superior son transaccionales, y PostgreSQL utiliza MVCC, por lo que el almacenamiento en cachí© de la cuenta de filas produce resultados inexactos.

— Bad CTK , PostgreSQL Count() lento Solución

El motor InnoDB en MySQL funciona de modo similar a PostgreSQL y comparable con la velocidad [3].

Cumplimiento de ACID

íCID (Atomicidad, Coherencia, Aislamiento y Durabilidad), este modelo se utiliza para evaluar la integridad de los datos a traví©s de los sistemas de gestión de bases de datos. La mayorí­a de sistemas de bases de datos cumplen con el estandar ACID mediante el uso de las transacciones.

PostgreSQL es plenamente compatible con ACID, mientras que el motor de almacenamiento InnoDB de MySQL proporciona cumplimento de ACID a nivel del motor:

MySQL Server (versión 3.23-max y todas las versiones 4.0 y superiores) soportan las transacciones con los motores de almacenamiento transaccionales InnoDB y BDB.

InnoDB proporciona pleno cumplimiento de ACID.

MySQL Cluster tambií©n es un motor de almacenamiento de transacciones seguro.

– MySQL AB, MySQL 5.0 Manuel de Referencia :: 1.8.5.2 Transacciones y operaciones atómicas

Para utilizar el motor compatible con ACID en MySQL por defecto, basta con establecer default-storage-engine=innodb en su archivo de configuración.

Innobase Oy, la empresa que desarrolló InnoDB, fue adquirida por Oracle en octubre de 2005. Oracle y MySQL AB firmaron un contrato para extender la concesión de licencias para el motor InnoDB en 2006, pero algunos temen que esa licencia cuando finaliza el perí­odo la competencia comercial entre Oracle (propietario del motor de almacenamiento InnoDB) y Sun (que compró MySQL AB en febrero de 2008) puede conducir a la futura concesión de licencias y costos para los usuarios de MySQL.

Caracterí­sticas

MySQL y PostgreSQL tienen un impresionante conjunto de caracterí­sticas que aumentan la integridad de los datos, funcionalidad y rendimiento. Las caracterí­sticas incluidas en una base de datos puede ayudar a mejorar el rendimiento, la facilidad de uso, la funcionalidad, o la estabilidad.

Facilidad de uso

Un “gotcha” es una caracterí­stica o función que funciona como se ha publicado – pero no como se esperaba.
— http://sql-info.de/mysql/gotchas.html

MySQL tiene más “gotchas”[4] que PostgreSQL [5].

Insert Ignore/Replace

MySQL soporta declaraciones INSERT IGNORE y REPLACE las cuales insertan si una fila existe de lo contrario no hace nada o reemplaza la fila actual, respectivamente. PostgreSQL no soporta ninguna de estas declaraciones y sugiere el uso de procedimientos almacenados para evitar la falta de estas declaraciones. Sin embargo, existen grandes deficiencias:

Sólo puede insertar un valor único a la vez. Esta es una limitación importante de rendimiento, y tambií©n sufre problemas de concurrencia. INSERT IGNORE y REPLACE manejan varios valores e inserta mucho mejor.

Limitaciones

Tanto MySQL y PostgreSQL soportan Not-Null, Unique, Llave primaria y llaves foráneas. Sin embargo MySQL no soporta comprobacion de limitación (Check constraint) mientras que PostgreSQL lo ha soportado durante mucho tiempo.

Tablas InnoDB soportan la comprobación de llaves foráneas … Para otros motores de almacenamiento, MySQL Server analiza y hace caso omiso de FOREIGN KEY y REFERENCES en la sintaxis de CREATE TABLE.

Procedimientos almacenados

Tanto MySQL y PostgreSQL soportan procedimientos almacenados. El primer lenguaje de consulta para PostgreSQL, PL/PgSQL, es similar a la de Oracle PL/SQL. PostgreSQL tambií©n soporta procedimientos almacenados en muchos otros lenguajes, entre ellos Python, Perl, TCL, Java y C – en particular la norma ISO SQL:2003 PSM.

MySQL sigue el SQL:2003 para la sintaxis de rutinas almacenadas, que tambií©n es utilizado por IBM DB2.

Triggers

Tanto MySQL y PostgreSQL soportan triggers. Un disparador PostgreSQL puede ejecutar cualquier función definida por el usuario desde cualquiera de sus lenguajes de procedimiento, no sólo PL/pgsql.

Los triggers de MySQL son activados solamente por comandos SQL. Estos no son activados por cambios en las tablas realizados por APIs que no transmiten las declaraciones de SQL al servidor MySQL, en particular, no son activadas por las actualizaciones hechas utilizando el NDB API.

— MySQL AB , MySQL 5.1 Reference Manual :: 19 Triggers

PostgreSQL tambií©n soporta las “reglas”, que permiten operar en el arbol de sintaxis de la consulta, y puede hacer algunas operaciones más simplificadas que tradicionalmente son realizadas por disparadores.

La sintaxis para la definición de los disparadores en PostgreSQL no es tan sencillo como en MySQL. En PostgreSQL es necesario una definición de una función con la devolucion del tipo de datos especí­fico.

Replicación y Alta Disponibilidad (HA)

La replicación es la capacidad de un sistema de gestion de base de datos de duplicar sus datos almacenados a efectos de brindar copias de seguridad y una manera de prevenir la inactividd de la base de datos de inactividad. Ambos PostgreSQL y MySQL soportan replicación:

PostgreSQL

PostgreSQL es modular por su diseño, y la replicacion no está en el núcleo. Hay varios paquetes que permiten la replicación en PostgreSQL:

  • PGCluster
  • Slony-I
  • DBBalancer
  • pgpool
  • PostgreSQL table comparator
  • SkyTools
  • Sequoia
  • Bucardo

Es un error común pensar que estos “paquetes de terceros” de alguna manera son menos bien integrados. Slony, por ejemplo, fue diseñado y construido por Jan Weick, un miembro del equipo del nuclero de PostgreSQL, y tiene otros miembros de la comunidad PostgreSQL que participan en su diseño continuo y mantenimiento.

Sin embargo, Slony es considerablemente más lento y utiliza más recursos que MySQL y su replicación incorporada, ya que utiliza SQL y triggers en lugar de un registro binario de enví­o para replicar los datos a traví©s de los servidores.

Lo cual lo puede hacer menos adecuado para grandes instalaciones de clusters con necesidades de alto rendimiento. Recientemente, el equipo del nucleo de PostgreSQL anuncio que la replicación basica se ha previsto como parte de la liberación 8.4.

MySQL

MySQL brinda soporte para replicación [6]. A partir de la versión 5.1, MySQL soporta dos formas de replicación; replicación basada en declaración (SBR) y replicación basada en la fila (RBR). SBR recolecta las consultas SQL que realizan cambios a la base de datos en un registro binario a los cuales los servidores esclavos se conectan para copiar sus cambios.

A diferencia RBR registra los cambios incrementales a las filas en el registro binario que luego son aplicados a los esclavos. Algunos motores de almacenamiento, tales como NDB y Falcon sólo soportan la replicación usando este nuevo formato basado en la fila [7].

Tipos de datos

PostgreSQL no tiene un tipo de dato entero sin signo, pero tiene mucho más soporte de tipos de datos en varios aspectos: el cumplimiento de las normas, la lógica fundamental del tipo de datos BOOLEAN, mecanismos de tipo de datos definidos por el usuario, tipo nativos y contribuidos.

Arrays de cualquier tipo basico nativo o definidos, tipo enum, o tipo compuestos se pueden crear. Arrays de dominios no son soportados todaví­a [8].

Subconsultas

Tanto MySQL y PostgreSQL soportan subconsultas, pero en MySQL algunas formas puede ser un gran impacto en el rendimiento. Esto será corregido en la versión 6.0 [9]

Indexación avanzada

Mí©todos avanzados de indezación permiten a los sistemas de bases de datos optimizar las consultas para lograr un mayor rendimiento.

  • índices hash: Sólo InnoDB y MEMORY soporta í­ndices hash. PostgreSQL soporta í­ndices hash, aunque nunca son más rápido que los í­ndices de arbol-B[10]
  • índices múltiples: MySQL soporta múltiples í­ndices por tabla y consultas desde 5.0. PostgreSQL soporta múltiples í­ndices por consulta.
  • Full-Text Indices: MySQL viene con búsqueda de texto completo, pero sólo se puede ejecutar sobre el (transacción no segura) motor de almacenamiento MyISAM [11].
  • Un agregado de terceros para MySQL, Sphinx Fulltext Search Engine permite el soporte a búsquedas de texto completo sobre tablas InnoDB. El texto de la indexación integrada no puede ser más de 255 caracteres.
  • Esto significa que usted no puede garantizar una única columna de texto de más de 255 caracteres. PostgreSQL 8.2 tiene búsqueda de texto completo en el modulo tsearch2.
  • PostgreSQL 8.3 integra tsearch2 en el núcleo: “TSearch2, nuestra herramienta de búsqueda texto completo de vanguardia, se ha integrado plenamente en el núcleo de código, y tambií©n tiene un API más limpia” [12].
  • Indices parciales: MySQL no es compatible con los í­ndices parciales. PostgreSQL soporta í­ndices parciales:

Un í­ndice parcial es un í­ndice construido sobre un subconjunto de una tabla, el subconjunto se define por una expresión condicional (llamado el predicado del í­ndice parcial). El í­ndice contiene entradas de la tabla sólo aquellos registros que satisfacen el predicado. Los índices parciales son una función especializada, pero hay varias situaciones en las que son útiles.

Una de las principales razones para la utilización de un í­ndice parcial es evitar la indexación de los valores comunes. Ya que una consulta en busca de un valor común (uno que representa más de unos pocos por ciento de todas las filas de tabla) no utilizara el í­ndice de todos modos, no hay ningún motivo para mantener esas filas en el í­ndice en absoluto.

Esto reduce el tamaño del í­ndice, lo que acelerará las consultas que si utilizan el í­ndice. Asi mismo, acelerara muchas de las operaciones de actualización de la tabla porque el í­ndice no necesita ser actualizado en todos los casos.

— PostgreSQL , PostgreSQL 8.2.6 Documentación: Capí­tulo 11. índices

Prefijo de í­ndices:

MySQL soporta prefijo de í­ndices: El prefijo de los í­ndices cubre los primeros N caracteres de una cadena de la columna, con lo que el í­ndice se vuelve mucho menor en tamaño que una que abarca toda la anchura de la columna, y aún así­ proporcionar un buen desempeño.

Con PostgreSQL, el prefijo de los í­ndices son un caso particular de los í­ndices de Expresión (ví©ase más adelante).

  • Indices Multi-columna: MySQL está limitado a 16 columnas por í­ndice [13]. PostgreSQL tiene un limitade de 32 columnas por í­ndice [14].
  • índices de mapa de bits: MySQL no tiene í­ndices de mapa de bits, pero logra una funcionalidad similar utilizando su caracterí­stica “index_merge”. índices de mapa de bits seran introducidos con el motor Falcon.

PostgreSQL soporta la capacidad de combinar varios í­ndices en el tiempo de consulta utilizando los í­ndices de mapa de bits.

  • índices de Expresiones: Los Indices de expresión pueden ser emulados en MySQL mediante la adición de una columna precomputada y el uso de un disparador que la mantenga.

PostgreSQL le permite crear í­ndices basados en las expresiones (que pueden incluir llamadas a funciones inmutables). Esto es muy útil cuando usted tiene una tabla con datos relativamente estables (no una gran cantidad de inserciones / actualizaciones) y a menudo se ejecuta una consulta que implica una costosa operación.

  • CREATE INDEX sin bloqueo: Depende de el motor de almacenamiento. Algunos motores (tales como MySQL Cluster y InnoDB Plugin) soporta indices add/drop en lí­nea (no se bloquea). Si el motor no admite add/drop en lí­nea del í­ndice, un bloqueo exclusivo de escribir es necesario y el copiado de la tabla.

PostgreSQL soporta la capacidad de crear í­ndices sin bloqueo de la tabla para escritura.

Particionado

MySQL soporta varios tipos de particionamiento horizontal.

  • RANGE
  • LIST
  • HASH
  • KEY
  • Particionado Compuesto utilizando una combinación de RANGO o LISTA con subparticiones HASH o KEY.

PostgreSQL sólo es compatible con particionado RANGE y LIST. Particionamiento HASH es soportado a traví©s de funciones inmutable. Particionado Compuesto tambií©n es soportado.

Motores de almacenamiento de datos

Motores de almacenamiento de datos tienen en cuenta el medio que está utilizando (para la mayorí­a de los propósitos, las bases de datos se almacenan en los discos para proporcionar la persistencia de datos) para maximizar el rendimiento de lectura/escritura.

PostgreSQL

PostgreSQL soporta un motor, por defecto su sistema de almacenamiento Postgres (Postgres Storage System). Hay una serie de formas de aumentar el rendimiento de PostgreSQL.

Para los datos no crí­ticos, puede poner su directorio de almacenamiento en un disco RAM LINK. [15] Esto, por supuesto, plantea la pregunta, de por quí© usted quiere ponerlo en una base de datos de todos modos. Hay DSMSes (Sistemas de Gestión de flujo de datos – Data Stream Management Systems) diseñados especí­ficamente para manejar los datos transitorios en una forma muy eficiente.

MySQL

MySQL 5.1 soporta nativamente 9 motores de almacenamiento [16]:

  • MyISAM
  • InnoDB
  • NDB Cluster
  • MERGE
  • MEMORY (HEAP)
  • FEDERATED
  • ARCHIVE
  • CSV
  • BLACKHOLE

Sin embargo, los motores federated y blackhole no son realmente motores de “almacenamiento”, (por ejemplo, “blackhole” no almacena nada).

InnoDB es desarrollado por la empresa externa InnoBase, que ha sido adquirida por Oracle. Conserva su lugar en las distribuciones estándar de MySQL como el principal motor transaccional. MySQL tiene previsto introducir nuevos motores de nombre Marí­a y Falcon en una próxima versión 6.x. [17] [18]

Entre las nuevas caracterí­sticas figuran la recuperación. Se espera reemplazar y completar los motores MyISAM y InnoDB, respectivamente.

There are several externally-developed storage engines, some of the most popular are:
Hay varios motores de almacenamiento desarrollados externamente, algunos de los más populares son:

  • SolidDB
  • NitroEDB
  • BrightHouse

MySQL tiene motores de almacenamiento a la medida y de la comunidad en desarrollo:

  • PrimeBase XT
  • FederatedODBC
  • FederatedX
  • IBM DB2
  • memcached

En algunas distribuciones, el motor de almacenamiento por defecto es MyISAM, que no es seguro para las transacciónes. Ajustar los valores para configurar el motor transaccional como InnoDB, es sin embargo, trivial.

Licencias

PostgreSQL viene con un estilo de licencia BSD, que se inscribe en la definición de Software Libre y Open Source, y se ajusta tanto a la Debian Free Software Guidelines y al estandar Copyfree.

El código fuente de MySQL está disponible bajo los tí©rminos de la Licencia Pública General de GNU, que tambií©n se inscribe en las definicioens de Software Libre y Open Source y se ajusta a la Debian Free Software Guidelines (pero no a la Copyfree Standard).

Tambií©n está disponible bajo un acuerdo de licencia de propietaria, que es normalmente destinados a ser utilizados por aquellos que desean incorporar código de MySQL sin tener que liberar el código fuente para toda la aplicación.

En tí©rminos prácticos, esto significa que MySQL se puede distribuir con o sin código fuente, como PostgreSQL, pero para no distribuir el código fuente en el caso de MySQL se requiere el pago de MySQL AB para una licencia comercial de MySQL.

Incluso la biblioteca cliente de MySQL es GPL (no LGPL), lo que significa que el uso (y, por tanto, enlace a) la biblioteca cliente de MySQL el programa en sí­ debe ser GPL o debe tener una licencia comercial de MySQL AB.

Desarrollo

PostgreSQL no es controlada por una sola empresa, sino que se basa en una comunidad global de desarrolladores y empresas para desarrollarlo.

MySQL es propiedad y está patrocinado por una sola empresa con fines de lucro, la empresa sueca MySQL AB, que posee los derechos de autor a la mayorí­a del código.

El 16 de enero de 2008 MySQL AB anunció un acuerdo para ser adquirida por Sun Microsystems, por aproximadamente US $1 mil millones. [La adquisición (se espera que) cierre en el tercer o cuarto trimestre del año fiscal de Sun que terminó el 30 de junio de 2008.]

MySQL es PRODUCTO open-source.

Postgres es proyecto de código abierto.
— Greg Sabino Mullane , Postgres no esta a la venta

Cultura

Comunidad

La comunidad de MySQL es apoyada en parte por el Community Relations Team de la empresa. MySQL AB ha patrocinado una Conferencia y Expo anual de usuarios desde el año 2003.

El hecho de que el modelo de negocios de MySQL AB se basa en el suministro de la instalación, configuración, migración, y la concesión de licencias especiales de soporte a la DBMS MySQL probablemente contribuye a la falta de enlaces a terceros y recursos de la comunidad en la página de soporte oficial.

Algunos creen que esto crea una relación polí©mica entre la empresa y la comunidad de usuarios del software de fuente abierta, aunque la evidencia parece sugerir que la relación es casi inexistente, más que hostil.

Con una mayor proporción de los desarrolladores a los usuarios, la comunidad PostgreSQL tiende a compensar un menor número de usuarios con una mayor densidad de los conocimientos en el soporte a la comunidad.

La falta de apoyo institucional de una empresa como MySQL AB (ahora una subsidiaria de Sun), PostgreSQL se beneficia de una serie de empresas independientes en todo el mundo cuyos modelos de negocio giran alrededor del suministro de la instalación, configuración, migración y soprote a la base de datos de código abierto.

Nombre

Cuando el estándar ANSI SQL fue escrito, su autor explicó que la pronunciación adecuada de SQL es “ess queue ell” (ell proceso de colas). Los nombres de ambos MySQL y PostgreSQL reflejan la pronunciación especificada por el autor del estándar SQL.

MySQL se pronuncia “my ess queue ell”.

Dado que MySQL es un proyecto de software propiedad de una empresa, MySQL AB tiene un control completo sobre el nombre del proyecto. Como resultado de esto, y el deseo de una identidad de marca, el nombre MySQL es probable que se mantenga intacto.

PostgreSQL se pronuncia “post gress queue ell”, formada por la combinación de Postgres (el nombre original del sistema de gestión de bases de datos a partir de la cual PostgreSQL es descendiente) con SQL. PostgreSQL es un verdadero portmanteau, en el sentido de que no sólo combina la ortografí­a y la pronunciación de dos palabras, sino tambií©n su significado: es el DBMS Postgres actualizado para el uso de SQL.

Popularidad

MySQL es muy popular entre los diverso paquetes de desarrollo de código abierto.

El motor MyISAM es a menudo el único motor de base de datos incluidos con los proveedores de hospedaje. Muchos desarrolladores web utilizan MySQL. Por lo tanto, MySQL se hizo muy popular en el desarrollo web, MySQL se llama a sí­ mismo “La base de datos de fuente abierta más popular del mundo “, una reclamación que pueden ser falsa dado el amplio despliegue de otros DBMSes de fuente abierta tales como SQLite.

Por lo tanto, MySQL es estereotipada como “más fácil” para el uso que PostgreSQL, debido a su popularidad.

Enlaces

  1. MySQL vs. PostgreSQL (2006-October)
  2. Open Source Database Software Comparison
  3. ¿Quí© considerar al pasar de MySQL a PostgreSQL
  4. Matriz de comparación (incluye Apache Derby y One$DB)
  5. http://www.jonathanboutelle.com/mt/archives/2005/08/mysql_vs_postgr.html
  6. http://www-css.fnal.gov/dsg/external/freeware/pgsql-vs-mysql.html
  7. http://www.devx.com/dbzone/Article/20743
  8. Critical comparison as wiki from PhiloVivero (2005)

Pro PostgreSQL

  1. Why PostgreSQL Instead of MySQL: Comparing Reliability and Speed in 2007
  2. Transactional DDL in PostgreSQL: A Competitive Analysis
  3. PostgreSQL vs MySQL with Rails
  4. http://www.vitavoom.com/postgresql.html
  5. http://article.gmane.org/gmane.comp.lang.ruby.rails/12576
  6. http://www.sitepoint.com/article/site-mysql-postgresql-1
  7. http://feedlounge.com/blog/2005/11/20/switched-to-postgresql/
  8. http://www.postgresrocks.com/ – Testimonials including database size and performance

Pro MySQL

  1. http://technically.us/code/x/my-postgresql-foray-is-over/ (Discusses the installation and speed of an obsolete version of tsearch2)
  2. Elefante vs Delfines. Death Match. El terreno determina el ganador.

Via | Wiki VS

Terminos de busqueda

  • mysql vs postgresql
  • postgresql vs mysql
  • mysql vs postgres
  • postgres vs mysql
  • mysql vs postgresql 2009
  • diferencias rendimiento oracle sqlserver mysql postgresql
  • capacidad de almacenamiento de mysql
  • deficiencias de MySQL
  • postgres vs mysql 2009
  • postgresql o mysql
  • 12 thoughts on “MySQL vs PostgreSQL

    1. Reply cowgaR Jan 28,2009 02:38

      This is one GREAT and sane comparison, I wonder why there aren’t any comments as this is the best one I found so far.

      What did I miss was the approximate price a company have to pay for MySql AB licences in average. There aren’t many applications released with source code under GPL so the cost pays significant role in choosing a database.

      Great achievement of writing such an article, Thank you very much.

    2. Reply Myke Feb 21,2009 15:18

      In one phrase… if you are thinking in your future, PosgreSQL is the best option…

    3. Reply Ambigel Mar 29,2009 09:09

      Excelente artículo

      necesito crear una aplicación web, donde constantemente estén escribiendo datos 12 personas, con un promedio de 550 nuevos registros por día, con cual me iría mejor MySQL o POSTGRES?

      • Reply fher98 Mar 30,2009 08:41

        Con 12 personas conectadas no tendras problema con ninguno de los dos motores. Estas optimizaciones son para cuando hablamos de miles de usuarios.

    4. Reply Arnold63 Oct 22,2009 06:37

      Now that Greenpeace has come clean on their statement, maybe Dr. ,

    5. Reply Santiago Nov 3,2010 10:31

      Es la primera vez que veo una comparativa sin fanatismos, me parece excelente, pero excelente el articulo, mis felicitaciones al autor.

      Lo voy a imprimir y lo voy a leer tranca. Llegue a esta comparativa por que estaba en la duda de que usar para mi próximo desarrollo y como en la empresa donde ahora estoy usan postgres y me he dado cuenta que es muy muy groso entre en la duda.

      Casi me decido por postgres 9 cuando googleando vi que twitter arranco con mysql y luego salto a casandra. Esta desicion la tomo el ingeniero de twitter. Ojala mi aplicación llegue a algo tan grande pero si twitter no tomo como ideal a postgres para ese tipo de segmento de trabajo por algo habrá sido.

      Por lo tanto sigo con mysql que para lo que yo quiero lo veo mejor, pero…. jamas diría que postgres es malo , no en lo absoluto es terrible nada mas que lo usaría para datos mas sensibles.

      Ese fue mi humilde aporte, cada DB es para cada cosa y son para segmentos distintos, un saludo a todos

    6. Reply willy Jul 18,2011 09:13

      Hola, he creado un sistema en internet que recaba informacion, en 3 años de actividad tengo al menos apuntado informacion de 30000 personas, obviamente sin contar sus actividades y seguimiento, lo que multiplicaria por 10. Mi primera duda es: Mysql o Postgress tienen un limite que no sea el fisico?
      Mi otra duda es, si quisiera migrar mi sistema a postrgress, existe algun sitema que me facilite dicha labor?…estoy hablando de un sistema PHP. gracias

      • Reply fher98 Jul 18,2011 14:54

        Con ambos motores tu limite es del sistema operativo. ES decir el tamaño maximo de un archivo en el sistema de artivos ext3 o ext4 en linux es lo que te limita el tamaño de tus bases de datos.
        Personalmente he trabajado con bases en postgresql de mas de 100GB y cero problemas.

    7. Reply Wilfo Aug 7,2012 23:02

      Woao..100GB ..

    8. Reply Wilfo Aug 7,2012 23:05

      Hola amigos,
      Tengo un proyecto sobre facturación con contabilidad online y es multiempresas y quisiera saber a las personas experimentadas,¿ cual de los dos gestores no me dará problemas a la larga?
      Estamos hablando de grandes volumenes de información.

    Comentario, Preguntas o agradecimientos?

    %d bloggers like this: