SQLite vs MySQL vs PostgreSQL: Uma Comparação dos Sistemas de Gerenciamento de Banco de Dados Relacionais

Introdução

O modelo de dados relacional, que organiza dados em tabelas de linhas e colunas, predomina nas ferramentas de gerenciamento de banco de dados. Hoje existem outros modelos de dados, incluindo NoSQL e NewSQL, mas os sistemas de gerenciamento de banco de dados relacionais (RDBMSs) continuam dominantes para armazenar e gerenciar dados em todo o mundo.

Este artigo compara e contrasta três dos RDBMSs de código aberto mais amplamente implementados: SQLite, MySQL e PostgreSQL. Especificamente, ele explorará os tipos de dados que cada RDBMS usa, suas vantagens e desvantagens, e situações onde eles são melhor otimizados.

A Bit About Database Management Systems

Bancos de dados são clusters logicamente modelados de informações, ou dados. Um sistema de gerenciamento de banco de dados (DBMS), por outro lado, é um programa de computador que interage com um banco de dados. Um DBMS permite controlar o acesso a um banco de dados, escrever dados, executar consultas e realizar qualquer outra tarefa relacionada ao gerenciamento de banco de dados.

Embora os sistemas de gerenciamento de banco de dados sejam frequentemente referidos como “bancos de dados”, os dois termos não são intercambiáveis. Um banco de dados pode ser qualquer coleção de dados, não apenas aquele armazenado em um computador. Em contraste, um SGBD refere-se especificamente ao software que permite interagir com um banco de dados.

Todos os sistemas de gerenciamento de banco de dados têm um modelo subjacente que estrutura como os dados são armazenados e acessados. Um sistema de gerenciamento de banco de dados relacional é um SGBD que emprega o modelo de dados relacional. Neste modelo relacional, os dados são organizados em tabelas. Tabelas, no contexto de SGBDRs, são formalmente referidas como relações. Uma relação é um conjunto de tuplas, que são as linhas em uma tabela, e cada tupla compartilha um conjunto de atributos, que são as colunas em uma tabela:

A maioria dos bancos de dados relacionais usa a linguagem de consulta estruturada (SQL) para gerenciar e consultar dados. No entanto, muitos SGBDRs usam seu próprio dialeto específico de SQL, que pode ter certas limitações ou extensões. Essas extensões geralmente incluem recursos extras que permitem aos usuários realizar operações mais complexas do que poderiam com o SQL padrão.

Tipos de Dados e Restrições

Cada coluna é atribuída a um tipo de dados que dita que tipo de entradas são permitidas nessa coluna. Diferentes SGBDs implementam tipos de dados diferentes, que nem sempre são diretamente intercambiáveis. Alguns tipos de dados comuns incluem datas, strings, inteiros e Booleans.

Armazenar inteiros em um banco de dados é mais complexo do que colocar números em uma tabela. Os tipos de dados numéricos podem ser assinados, significando que podem representar números positivos e negativos, ou não assinados, o que significa que podem representar apenas números positivos. Por exemplo, o tipo de dados tinyint do MySQL pode armazenar 8 bits de dados, o que equivale a 256 valores possíveis. O intervalo assinado deste tipo de dados vai de -128 a 127, enquanto o intervalo não assinado vai de 0 a 255.

Ser capaz de controlar quais dados são permitidos em um banco de dados é importante. Às vezes, um administrador de banco de dados irá impor uma restrição em uma tabela para limitar quais valores podem ser inseridos nela. Uma restrição normalmente se aplica a uma coluna específica, mas algumas restrições também podem se aplicar a uma tabela inteira. Aqui estão algumas restrições comumente usadas em SQL:

• ÚNICO: Aplicar esta restrição a uma coluna garante que não haja duas entradas idênticas nessa coluna.
• NÃO NULO: Esta restrição garante que uma coluna não tenha nenhuma entrada NULA.
• CHAVE PRIMÁRIA: Uma combinação de ÚNICO e NÃO NULO, a restrição de CHAVE PRIMÁRIA garante que nenhuma entrada na coluna seja NULA e que cada entrada seja distinta.
• CHAVE ESTRANGEIRA: Uma CHAVE ESTRANGEIRA é uma coluna em uma tabela que se refere à CHAVE PRIMÁRIA de outra tabela. Esta restrição é usada para vincular duas tabelas juntas. As entradas na coluna de CHAVE ESTRANGEIRA devem já existir na coluna CHAVE PRIMÁRIA pai para que o processo de escrita tenha sucesso.
• CHECAR: Esta restrição limita o intervalo de valores que podem ser inseridos em uma coluna. Por exemplo, se sua aplicação destina-se apenas a residentes do Alasca, você poderia adicionar uma restrição de CHECAR em uma coluna de código ZIP para permitir apenas entradas entre 99501 e 99950.

Se você gostaria de aprender mais sobre sistemas de gerenciamento de banco de dados, confira nosso artigo sobre Uma Comparação de Sistemas e Modelos de Gerenciamento de Banco de Dados NoSQL.

Agora que cobrimos os sistemas de gerenciamento de banco de dados relacionais de forma geral, vamos passar para o primeiro dos três bancos de dados relacionais de código aberto que este artigo abordará: SQLite.

SQLite

O SQLite é um sistema de gerenciamento de banco de dados relacional (RDBMS) autônomo, baseado em arquivos e totalmente de código aberto, conhecido por sua portabilidade, confiabilidade e alto desempenho, mesmo em ambientes com pouca memória. Suas transações são compatíveis com o ACID, mesmo em casos de falha do sistema ou queda de energia.

O site do projeto SQLite o descreve como um banco de dados “sem servidor”. A maioria dos motores de banco de dados relacionais é implementada como um processo de servidor, no qual os programas se comunicam com o servidor hospedeiro por meio de uma comunicação entre processos que retransmite solicitações. Em contraste, o SQLite permite que qualquer processo que acesse o banco de dados leia e escreva diretamente no arquivo de disco do banco de dados. Isso simplifica o processo de configuração do SQLite, pois elimina a necessidade de configurar um processo de servidor. Da mesma forma, não há necessidade de configuração para programas que usarão o banco de dados SQLite: tudo o que precisam é de acesso ao disco.

O SQLite é um software gratuito e de código aberto, e não é necessário nenhum tipo de licença especial para utilizá-lo. No entanto, o projeto oferece várias extensões — cada uma por uma taxa única — que ajudam com compressão e criptografia. Além disso, o projeto oferece vários pacotes de suporte comercial, cada um por uma taxa anual.

Tipos de Dados Suportados pelo SQLite

O SQLite permite uma variedade de tipos de dados, organizados nas seguintes classes de armazenamento:

No contexto do SQLite, os termos “classe de armazenamento” e “tipo de dados” são considerados intercambiáveis. Se desejar saber mais sobre os tipos de dados do SQLite e a afinidade de tipo do SQLite, consulte a documentação oficial do SQLite sobre o assunto.

Vantagens do SQLite

• Pegada pequena: Como o nome sugere, a biblioteca SQLite é muito leve. Embora o espaço que ela ocupa varie dependendo do sistema onde está instalada, pode ocupar menos de 600KiB de espaço. Além disso, é totalmente autossuficiente, o que significa que não há dependências externas que você precise instalar no seu sistema para o SQLite funcionar.
• Amigável ao usuário: O SQLite é às vezes descrito como um banco de dados “sem necessidade de configuração” que está pronto para uso assim que é instalado. O SQLite não é executado como um processo de servidor, o que significa que nunca precisa ser parado, iniciado ou reiniciado e não vem com arquivos de configuração que precisam ser gerenciados. Esses recursos ajudam a simplificar o processo desde a instalação do SQLite até a integração com um aplicativo.
• Portátil: Ao contrário de outros sistemas de gerenciamento de banco de dados, que geralmente armazenam dados como um grande lote de arquivos separados, um banco de dados inteiro do SQLite é armazenado em um único arquivo. Este arquivo pode estar em qualquer lugar em uma hierarquia de diretórios e pode ser compartilhado via mídia removível ou protocolo de transferência de arquivo.

Desvantagens do SQLite

• Concorrência limitada: Embora vários processos possam acessar e consultar um banco de dados SQLite ao mesmo tempo, apenas um processo pode fazer alterações no banco de dados em determinado momento. Isso significa que, embora o SQLite suporte maior concorrência do que a maioria dos outros sistemas de gerenciamento de banco de dados incorporados, ele não pode suportar tanto quanto os SGBDs cliente/servidor como o MySQL ou o PostgreSQL.
• Sem gerenciamento de usuário: Os sistemas de banco de dados frequentemente vêm com suporte para usuários, ou conexões gerenciadas com privilégios de acesso predefinidos ao banco de dados e tabelas. Como o SQLite lê e escreve diretamente em um arquivo de disco comum, as únicas permissões de acesso aplicáveis são as típicas do sistema operacional subjacente. Isso torna o SQLite uma escolha inadequada para aplicativos que exigem vários usuários com permissões de acesso especiais.
• Segurança: Um motor de banco de dados que usa um servidor pode, em alguns casos, fornecer melhor proteção contra erros na aplicação cliente do que um banco de dados sem servidor como o SQLite. Por exemplo, ponteiros perdidos em um cliente não podem corromper a memória no servidor. Além disso, como um servidor é um único processo persistente, um banco de dados cliente-servidor pode controlar o acesso aos dados com mais precisão do que um banco de dados sem servidor. Isso permite um travamento mais refinado e melhor concorrência.

Quando usar o SQLite

• Aplicações incorporadas: O SQLite é uma ótima escolha de banco de dados para aplicativos que precisam de portabilidade e não requerem expansão futura. Exemplos incluem aplicativos locais de usuário único, aplicativos móveis ou jogos.
• Substituição de acesso ao disco: Em casos em que uma aplicação precisa ler e escrever arquivos diretamente no disco, pode ser benéfico usar o SQLite pela funcionalidade adicional e simplicidade que vem com o uso do SQL.
• Teste: Para muitas aplicações, pode ser excessivo testar sua funcionalidade com um SGBD que utiliza um processo de servidor adicional. O SQLite possui um modo de memória que pode ser usado para executar testes rapidamente sem o overhead das operações reais de banco de dados, tornando-o uma escolha ideal para testes.

Quando Não Usar o SQLite

• Trabalhando com muitos dados: O SQLite pode tecnicamente suportar um banco de dados de até 140 TB de tamanho, desde que a unidade de disco e o sistema de arquivos também suportem os requisitos de tamanho do banco de dados. No entanto, o site do SQLite recomenda que qualquer banco de dados que se aproxime de 1 TB seja hospedado em um banco de dados cliente-servidor centralizado, pois um banco de dados SQLite desse tamanho ou maior seria difícil de gerenciar.
• Altos volumes de escrita: O SQLite permite apenas uma operação de escrita ocorrer de cada vez, o que limita significativamente seu throughput. Se sua aplicação requer muitas operações de escrita ou vários escritores concorrentes, o SQLite pode não ser adequado para suas necessidades.
• O acesso à rede é necessário: Como o SQLite é um banco de dados sem servidor, ele não fornece acesso direto à rede para seus dados. Esse acesso é incorporado à aplicação. Se os dados no SQLite estiverem localizados em uma máquina separada da aplicação, será necessário um link de alto desempenho entre o mecanismo e o disco através da rede. Esta é uma solução cara e ineficiente, e em tais casos um SGBD cliente-servidor pode ser uma escolha melhor.

MySQL

De acordo com o Ranking DB-Engines, o MySQL tem sido o SGBD relacional de código aberto mais popular desde que o site começou a rastrear a popularidade do banco de dados em 2012. É um produto rico em recursos que alimenta muitos dos maiores sites e aplicativos do mundo, incluindo Twitter, Facebook, Netflix e Spotify. Começar com o MySQL é relativamente simples, em grande parte graças à sua documentação abrangente e à grande comunidade de desenvolvedores, bem como à abundância de recursos relacionados ao MySQL online.

O MySQL foi projetado para velocidade e confiabilidade, às custas da adesão completa ao SQL padrão. Os desenvolvedores do MySQL trabalham continuamente para uma adesão mais próxima ao SQL padrão, mas ainda está atrás de outras implementações de SQL. No entanto, ele vem com vários modos e extensões SQL que o aproximam da conformidade.

Ao contrário de aplicações que usam SQLite, aplicações que usam um banco de dados MySQL o acessam por meio de um processo daemon separado. Como o processo do servidor fica entre o banco de dados e outras aplicações, permite um maior controle sobre quem tem acesso ao banco de dados.

O MySQL inspirou uma variedade de aplicações de terceiros, ferramentas e bibliotecas integradas que estendem sua funcionalidade e ajudam a tornar mais fácil o trabalho com ele. Algumas das ferramentas de terceiros mais amplamente utilizadas são phpMyAdmin, DBeaver e HeidiSQL.

Tipos de Dados Suportados pelo MySQL

Os tipos de dados do MySQL podem ser organizados em três categorias amplas: tipos numéricos, tipos de data e hora e tipos de string.

Tipos numéricos:

Tipos de data e hora:

Tipos de string:

Vantagens do MySQL

• Popularidade e facilidade de uso: Como um dos sistemas de banco de dados mais populares do mundo, não há escassez de administradores de banco de dados que têm experiência em trabalhar com o MySQL. Da mesma forma, há uma abundância de documentação impressa e online sobre como instalar e gerenciar um banco de dados MySQL. Isso inclui uma série de ferramentas de terceiros — como o phpMyAdmin — que visam simplificar o processo de começar com o banco de dados.
• Segurança: O MySQL vem instalado com um script que ajuda a melhorar a segurança do seu banco de dados, definindo o nível de segurança da senha da instalação, definindo uma senha para o usuário root, removendo contas anônimas e removendo bancos de dados de teste que, por padrão, são acessíveis a todos os usuários. Além disso, ao contrário do SQLite, o MySQL suporta gerenciamento de usuários e permite que você conceda privilégios de acesso em uma base de usuário por usuário.
• Velocidade: Ao optar por não implementar certas funcionalidades do SQL, os desenvolvedores do MySQL foram capazes de priorizar a velocidade. Embora testes de benchmark mais recentes mostrem que outros SGBDs como o PostgreSQL podem igualar ou pelo menos se aproximar do MySQL em termos de velocidade, o MySQL ainda mantém a reputação de ser uma solução de banco de dados extremamente rápida.
• Replicação: O MySQL suporta diversos tipos de replicação, que é a prática de compartilhar informações entre dois ou mais hosts para ajudar a melhorar a confiabilidade, disponibilidade e tolerância a falhas. Isso é útil para configurar uma solução de backup de banco de dados ou escalonar horizontalmente um banco de dados.

Desvantagens do MySQL

• Limitações conhecidas: Como o MySQL foi projetado para velocidade e facilidade de uso em vez de conformidade total com o SQL, ele vem com certas limitações funcionais. Por exemplo, ele falta de suporte para cláusulas FULL JOIN.
• Licenciamento e recursos proprietários: O MySQL é um software de licenciamento duplo, com uma edição comunitária gratuita e de código aberto licenciada sob GPLv2 e várias edições comerciais pagas lançadas sob licenças proprietárias. Devido a isso, alguns recursos e plugins estão disponíveis apenas para as edições proprietárias.
• Desenvolvimento desacelerado: Desde que o projeto MySQL foi adquirido pela Sun Microsystems em 2008 e posteriormente pela Oracle Corporation em 2009, houve reclamações dos usuários de que o processo de desenvolvimento para o SGBD desacelerou significativamente, pois a comunidade já não tem a capacidade de reagir rapidamente a problemas e implementar mudanças.

Quando usar o MySQL

• Operações distribuídas: O suporte à replicação do MySQL o torna uma ótima escolha para configurações de banco de dados distribuídos, como arquiteturas primário-secundário ou primário-primário.
• Websites e aplicações web: O MySQL alimenta muitos sites e aplicativos na internet. Isso se deve, em grande parte, à facilidade de instalação e configuração de um banco de dados MySQL, bem como à sua velocidade geral e escalabilidade a longo prazo.
• Crescimento futuro esperado: O suporte à replicação do MySQL pode ajudar a facilitar o escalonamento horizontal. Além disso, é um processo relativamente simples atualizar para um produto MySQL comercial, como o MySQL Cluster, que suporta shard automático, outro processo de escalonamento horizontal.

Quando não usar o MySQL

• Conformidade com SQL é necessária: Como o MySQL não tenta implementar o padrão SQL completo, essa ferramenta não é totalmente compatível com SQL. Se a conformidade completa ou mesmo quase completa com SQL for essencial para o seu caso de uso, você pode querer usar um SGDB mais completamente compatível.
• Concorrência e grandes volumes de dados: Embora o MySQL geralmente tenha um bom desempenho com operações de leitura pesada, operações de leitura-escrita concorrentes podem ser problemáticas. Se sua aplicação tiver muitos usuários gravando dados nela ao mesmo tempo, outro SGDB como o PostgreSQL pode ser uma escolha melhor de banco de dados.

PostgreSQL

O PostgreSQL, também conhecido como Postgres, se autodenomina “o banco de dados relacional de código aberto mais avançado do mundo”. Foi criado com o objetivo de ser altamente extensível e compatível com padrões. O PostgreSQL é um banco de dados objeto-relacional, o que significa que, embora seja principalmente um banco de dados relacional, também inclui recursos – como herança de tabelas e sobrecarga de funções – que são mais frequentemente associados a bancos de dados de objetos.

O PostgreSQL é capaz de lidar eficientemente com várias tarefas ao mesmo tempo, uma característica conhecida como concorrência. Ele alcança isso sem travamentos de leitura graças à sua implementação do Controle de Concorrência Multiversão (MVCC), que garante a atomicidade, consistência, isolamento e durabilidade de suas transações, também conhecida como conformidade ACID.

O PostgreSQL não é tão amplamente utilizado quanto o MySQL, mas ainda existem várias ferramentas e bibliotecas de terceiros projetadas para simplificar o trabalho com o PostgreSQL, incluindo pgAdmin e Postbird.

Tipos de Dados Suportados pelo PostgreSQL

O PostgreSQL suporta tipos de dados numéricos, de string, de data e hora, assim como o MySQL. Além disso, suporta tipos de dados para formas geométricas, endereços de rede, cadeias de bits, pesquisas de texto e entradas JSON, além de vários tipos de dados idiossincráticos.

Tipos Numéricos:

Tipos de Caractere:

Tipos de Data e Hora:

Tipos Geométricos:

Tipos de Endereço de Rede:

Tipos de Cadeia de Bits:

Tipos de Pesquisa de Texto:

Tipos JSON:

Outros tipos de dados:

Vantagens do PostgreSQL

• Conformidade com SQL: Mais do que SQLite ou MySQL, o PostgreSQL visa aderir de perto aos padrões do SQL. De acordo com a documentação oficial do PostgreSQL, o PostgreSQL suporta 160 dos 179 recursos necessários para conformidade total com o SQL:2011, além de uma longa lista de recursos opcionais.
• Código aberto e comunitário: Um projeto totalmente de código aberto, o código fonte do PostgreSQL é desenvolvido por uma comunidade grande e dedicada. Da mesma forma, a comunidade do Postgres mantém e contribui para numerosos recursos online que descrevem como trabalhar com o SGBD, incluindo a documentação oficial, a wiki do PostgreSQL e vários fóruns online.
• Extensível: Os usuários podem estender o PostgreSQL de forma programática e dinâmica através de sua operação orientada por catálogo e seu uso de carregamento dinâmico. Pode-se designar um arquivo de código objeto, como uma biblioteca compartilhada, e o PostgreSQL o carregará conforme necessário.

Desvantagens do PostgreSQL

• Desempenho de memória: Para cada nova conexão de cliente, o PostgreSQL cria um novo processo. Cada novo processo é alocado cerca de 10MB de memória, o que pode somar rapidamente para bancos de dados com muitas conexões. Consequentemente, para operações simples com muita leitura, o PostgreSQL geralmente é menos eficiente do que outros SGBDRs, como o MySQL.
• Popularidade: Embora mais amplamente utilizado nos últimos anos, o PostgreSQL historicamente ficou atrás do MySQL em termos de popularidade. Uma consequência disso é que ainda existem menos ferramentas de terceiros que podem ajudar a gerenciar um banco de dados PostgreSQL. Da mesma forma, não há tantos administradores de banco de dados com experiência em gerenciar um banco de dados Postgres em comparação com aqueles com experiência em MySQL.

Quando usar o PostgreSQL

• A integridade dos dados é importante: O PostgreSQL é totalmente compatível com ACID desde 2001 e implementa controle de concorrência de várias versões para garantir que os dados permaneçam consistentes, tornando-o uma escolha sólida de SGBDR quando a integridade dos dados é crítica.
• Integração com outras ferramentas: O PostgreSQL é compatível com uma ampla variedade de linguagens de programação e plataformas. Isso significa que, se você precisar migrar seu banco de dados para outro sistema operacional ou integrá-lo com uma ferramenta específica, provavelmente será mais fácil com um banco de dados PostgreSQL do que com outro SGBD.
• Operações complexas: O Postgres suporta planos de consulta que podem aproveitar vários CPUs para responder consultas com maior velocidade. Isso, juntamente com seu forte suporte para vários escritores simultâneos, o torna uma ótima escolha para operações complexas como armazenamento de dados e processamento de transações online.

Quando não usar o PostgreSQL

• A velocidade é imperativa: Em detrimento da velocidade, o PostgreSQL foi projetado com extensibilidade e compatibilidade em mente. Se seu projeto exigir as operações de leitura mais rápidas possíveis, o PostgreSQL pode não ser a melhor escolha de SGBD.
• Configurações simples: Devido ao seu amplo conjunto de recursos e forte aderência ao SQL padrão, o Postgres pode ser excessivo para configurações simples de banco de dados. Para operações com foco na leitura e onde a velocidade é necessária, o MySQL é geralmente uma escolha mais prática.
• Replicação complexa: Embora o PostgreSQL forneça um suporte sólido para replicação, ainda é um recurso relativamente novo. Algumas configurações — como uma arquitetura primária-primária — só são possíveis com extensões. A replicação é um recurso mais maduro no MySQL e muitos usuários consideram a replicação do MySQL mais fácil de implementar, especialmente para aqueles que não têm experiência necessária em administração de banco de dados e sistemas.

Conclusão

Hoje, SQLite, MySQL e PostgreSQL são os três sistemas de gerenciamento de banco de dados relacionais de código aberto mais populares do mundo. Cada um tem suas próprias características e limitações exclusivas, e se destaca em cenários específicos. Existem várias variáveis em jogo ao decidir sobre um SGBD, e a escolha raramente é tão simples quanto escolher o mais rápido ou aquele com mais recursos. Da próxima vez que precisar de uma solução de banco de dados relacional, certifique-se de pesquisar a fundo essas e outras ferramentas para encontrar aquela que melhor atenda às suas necessidades.

Se desejar aprender mais sobre SQL e como usá-lo para gerenciar um banco de dados relacional, recomendamos que consulte nosso Como Gerenciar um Banco de Dados SQL. Por outro lado, se quiser aprender sobre bancos de dados não relacionais (ou NoSQL), confira nossa Comparação de Sistemas de Gerenciamento de Banco de Dados NoSQL.

Referências

• Classificações DB-Engines
• Documentação Oficial do SQLite
• O SQLite é sem servidor
• Usos Adequados para o SQLite
• Documentação Oficial do MySQL
• Comparando a Replicação do MySQL e Postgres 9.0
• Documentação Oficial do PostgreSQL
• Finalmente Chegou a Hora do PostgreSQL?