Guatewireless.org

Elegir entre MySQL vs 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 versión 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 comparación de velocidad es 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 de MySQL vs PostgreSQL

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 así 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 soporte a las transacciones, < strong > llaves foráneas, </strong > 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 < strong > datos comprimidos </strong >, 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 versión 5.1 de MySQL sus motores de almacenamiento de alto rendimiento no soportan compresión sobre la marcha.

La versión de MySQL 6.0 tendrá soporte de compresión sobre la marcha con su nuevo motor de almacenamiento Falcón:

Los datos almacenados en las tablas de Falcón 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 desde 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 soporta í­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 tecnología de procesadores con múltiples núcleos 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 enfrentará contra un servidor PostgreSQL con la configuración por defecto y sin afinar.
• Al comparar los benchmarks a menudo agrupaban transacciones modales poco realistas que no reflejan el comportamiento 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, también involucra sistemas de pruebas haciendo cosas muy diferentes.
• Si la integridad transaccional es de suma importancia para usted, mayor rendimiento sin garantía 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 utilización 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 transacciones 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

íACID (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 estándar 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 (version 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 de MySQL vs PostgreSQL

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 pueden 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.

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 soporta Not-Null, Unique, Llave primaria y llaves foráneas. Sin embargo MySQL no soporta comprobación 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 soporta 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 soporta 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 árbol 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 sencilla como en MySQL. En PostgreSQL es necesario una definición de una función con la devolución del tipo de datos especí­fico.

Replicación y Alta Disponibilidad (HA)

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

PostgreSQL

PostgreSQL es modular por su diseño, y la replicación 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 núcleo 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 núcleo de PostgreSQL anunció que la replicación básica 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 Falcón 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 básico nativo o definidos, tipo enum, o tipo compuestos se pueden crear. Los arrays de dominios no son soportados todaví­a [8].

Subconsultas

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

Indexación avanzada

Mí©todos avanzados de indexació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 árbol-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 Índices: MySQL viene con búsqueda de texto completo, pero sólo se puede ejecutar sobre él (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 módulo 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].
• Índices 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 sí utilizan el í­ndice. Así mismo, acelerará 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. íindices

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).

• Índices Multi-columna: MySQL está limitado a 16 columnas por í­ndice [13]. PostgreSQL tiene un límite 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 serán introducidos con el motor Falcón.

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

• índices de Expresiones: Los Índices 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 del motor de almacenamiento. Algunos motores (tales como MySQL Cluster y InnoDB Plugin) soporta índices add/drop en lí­nea (no se bloquean). 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 se 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 transacciones. 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 estándar 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 definiciones 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 destinado 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 un 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ítica 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 soporte 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 diversos 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 DBM es 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)
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
6. http://www.sitepoint.com/article/site-mysql-postgresql-1
8. – 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 | MySQL: Como buscar y reemplazar texto en todas las tablas de una base de datos.