Ruby on Rails: MySQL VS. PostgreSQL

Não é novidade que o MySQL figura entre os Sistemas Gerenciadores de Banco de Dados (SGDB’s) mais utilizados. Das suas vantagens, destaca-se principalmente sua facilidade de instalação e utilização. Ainda segundo o ranking mais atualizado da DB Engines, ele fica atrás apenas do SGDB proprietário da Oracle:

Entretanto, na comunidade Ruby On Rails, o PostgreSQL continua a conquistar os desenvolvedores e há um desequilíbrio nessa preferência: Em uma pesquisa recente no ano de 2016, o PostgreSQL foi o escolhido em 84% dos casos, um aumento de 12% em relação ao ano anterior. O MySQL apareceu como opção de apenas 14% dos desenvolvedores. Mas o que causa essa disparidade no caso particular de uma aplicação desenvolvida com o Rails? Primeiro vamos a algumas especificações gerais desses SGDB’s, fora do contexto particular do framework:

PostgreSQL

O PostgreSQL é um sistema de gerenciamento de banco de dados objeto-relacional com ênfase em extensibilidade e conformidade com os padrões. O PostgreSQL utiliza constraints, triggers, roles, stored procedures e views como os principais componentes com os quais você trabalha. O PostgreSQL usa chaves primárias para identificar de forma única cada linha (registro) em uma tabela e chaves estrangeiras para assegurar a integridade referencial entre duas tabelas relacionadas. Vale ressaltar que o PostgreSQL suporta muitos recursos do NoSQL.

Quem utiliza o PostgreSQL: Apple, BioPharm, Etsy, IMDB, Macworld, Debian, Fujitsu, Red Hat, Sun Microsystem, Cisco, Skype. Veja a lista completa aqui.

MySQL

O MySQL é um SGDB também de código aberto. Assim como o PostgreSQL, e todos os outros bancos de dados relacionais, o MySQL usa tabelas como um componente principal e tem mais ou menos o mesmo conjunto de recursos que o PostgreSQL, entretanto a configuração dos usuários que acessam o SGDB (equivalente às roles do PostgreSQL) é mais intuitiva e menos trabalhosa, tornando uma opção mais trivial.

Quem utiliza o MySQL: GitHub, US Navy, NASA, Tesla, Netflix, WeChat, Facebook, Zendesk, Twitter, Zappos, YouTube, Spotify. Veja a lista completa aqui

PostgreSQL x MySQL para Ruby on Rails

Se em uma utilização de propósito geral ambos os SGDB’s se assemelham tanto, o que traz esse desequilíbrio quando utilizado em conjunto com o framework Rails? Vamos tentar enumerar algumas vantagens pontuais que podem pesar nessa escolha:

• Suporte a JSON e NoSQL: O PostgreSQL permite usar o NoSQL e armazenar arquivos JSON (JavaScript Object Notation) no banco de dados, e isso é uma adição recente ao PostgreSQL. Em versões mais novas o MySQL (5,7+) trouxe também alguns recursos para o NoSQL, mas nesse aspecto o PostgreSQL largou à frente.
• Tipos de dados avançados: Existem mais tipos de dados avançados no PostgreSQL. Dentre eles estão os arrays, documentos de hstore, chaves primárias UUID, pesquisa de texto completo armazenamento de models do Active Record do Rails com visualização do banco. Exemplos de tipos de dados avançados: money, uuid, XML, box, inet e timespan.
• Melhor integridade de dados: Precisamos definir o servidor para um modo SQL estrito (STRICT_ALL_TABLES ou STRICT_TRANS_TABLES), caso contrário, os valores serão inseridos ou atualizados. O PostgreSQL tem sido rigoroso em garantir que os dados sejam válidos antes de inseri-los ou atualizá-los com a pesquisa de texto completo adequada e outras extensões.
• Rollbacks mais rápidos: O PostgreSQL consegue revertar uma alterção na ordem de O (1). Devido às suas diferentes implementações MVCC, não importa o quanto tenha sido alterado – dados gravados ou mudanças de esquema feitas – uma reversão é instantânea com o PostgreSQL enquanto rollbacks com o MySQL demoram muito dependendo de quanto tempo estava em execução antes de ser cancelado ou revertido.
• Subqueries problemáticas: O MySQL não suporta Full Outer Joins, ao contrário do PostgreSQL.

Em suma, o PostgreSQL se apresenta como uma opção mais robusta, principalmente no quesito de integridade dos dados. Dependendo dos requisitos da sua aplicação, esses pontos podem ser críticos e a camada de aplicação do Rails pode possuir algumas armadilhas nesse aspecto, o que faz necessário transferir essa responsabilidade para o seu SGBD. Mas conforme esperado, não existe uma resposta final, apenas os pontos a serem considerados para auxiliar a sua tomada de decisão. Quaisquer dúvidas ou sugestões, utilize a área de comentários ou entre em contato!