PostgreSQL vs SQL Server: Comparativo de Recursos

Olá, Pessoal! Hoje vamos falar um pouco sobre PostgreSQL vs SQL Server e entender as principais diferenças entre esses dois SGBDs altamente utilizados no mercado corporativo. Mas quais são as diferenças e semelhanças entre eles? Será que é somente a questão do valor do licenciamento que pesa na hora de escolher o banco de dados ideal para sua empresa?

É importante ressaltar que, este artigo não pretende ser um guia definitivo e que ambos SGBDs estão em constante evolução.

Filosofia

Quando falamos sobre PostgreSQL vs SQL Server, uma das primeiras diferenças que podemos observar está justamente na filosofia de cada plataforma.

O PostgreSQL segue uma filosofia de software livre, ou seja, é desenvolvido e mantido pela comunidade. Por isso, quando surge alguma dúvida ou necessidade de suporte, é bem comum recorrer a fóruns, documentações e outros conteúdos criados por quem usa a ferramenta no dia a dia.

Por trás disso está o PostgreSQL Global Development Group, um grupo formado por diversas empresas e colaboradores ao redor do mundo, incluindo gigantes como Red Hat, Microsoft e Amazon. Seguindo essa mesma ideia de colaboração, existem várias extensões criadas pela própria comunidade que podem ser instaladas para adicionar novas funcionalidades ao PostgreSQL.

O Microsoft SQL Server também conta com uma comunidade grande e bastante ativa, que ajuda muito no dia a dia. É comum encontrar usuários que criam suas próprias procedures para facilitar a manutenção dos bancos de dados, além de empresas especializadas, como a CDB Data Solutions, que oferecem suporte e soluções mais avançadas.

Por outro lado, quando o assunto é adicionar novas funcionalidades, o cenário muda um pouco. Nesse caso, o SQL Server depende diretamente da Microsoft para lançar novas versões ou atualizações que incluam esses recursos.

Algumas diferenças sobre a arquitetura

Ambos podem ser instalados em sistemas operacionais Windows e Linux e podem se usados nas principais nuvens, Azure, GCP e AWS.

Processamento

Uma diferença que temos entre os dois é o modelo de processamento, que no PostgreSQL é Multi-processo, ou seja, cada conexão de cliente é um novo processo executando no ambiente. O que melhora o isolamento entre as conexões de cliente e a estabilidade do processo, pois se um processo travar as outras conexões continuam abertas e transacionando normalmente. Mas a desvantagem é que utiliza mais memória, justamente por ter vários processos abertos simultaneamente.

O SQL Server utiliza o modelo Multi-Thread, ou seja, tem somente um processo em execução no ambiente. Esse processo abre múltiplas Threads, que são gerenciadas pela engine do SQL Server. A vantagem desse modelo é que utiliza menos memória e tem maior escala para conexões massivas, a desvantagem é que se o processo travar irá impactar em toda a instância.

Gerenciamento de Memória

Ambos os SGBDs têm o objetivo de otimizar o uso de memória RAM para melhorar o desempenho, principalmente nas consultas. Mas eles gerenciam de forma diferente, até porque, cada um tem parâmetros de configuração de memória próprios.

O PostgreSQL tem um gerenciamento mais manual, exigindo que vários parâmetros sejam configurados, como por exemplo:

Shared_buffer: define a memória usada para cache das páginas de dados;

Work_Mem: define a memória disponível para operações de ordenação e outras operações intermediárias por sessão;

Maintenance_work_mem: utilizada para tarefas administrativas, como VACUUM, CREATE INDEX, etc.;

Effective_cache_size: utilizado pelo otimizador de consultas para estimar quanto de cache o Sistema Operacional (SO) possui.

O SQL Server controla e distribui a memória internamente, com áreas específicas para cada operação, como citado abaixo:

Buffer Pool (cache de páginas de dados);

Query Execution Memory;

Plan Cache;

Columnstore Object Pool;

Memória para operações internas e paralelismo.

Além disso o SQL Server monitora a “pressão” de memória do SO e, se necessário, pode liberar recursos para “desafogar” o SO, isso reduz a necessidade de ajustes manuais simplificando a administração do ambiente.

MVCC no PostgreSQL vs SQL Server

Ambos utilizam o MVCC (Multi-Version Concurrency control), porém, de formas diferentes.

O PostgreSQL implementa o MVCC diretamente nas tabelas, cada linha da tabela tem metadados que indicam qual transação criou a linha e qual a invalidou. Esse sistema ajuda a evitar bloqueios no ambiente tanto para leitura quanto para escrita. Sua desvantagem é que as linhas inválidas continuam fisicamente na tabela, aumentando o tamanho do banco e obrigando a execução do VACUUM periodicamente.

O SQL Server utiliza o padrão de Locking pessimista, ou seja, o registro é bloqueado quando uma transação lê ou altera o registro, claro que há vários tipos de bloqueio e cada tipo é usado conforme a transação do usuário. Com esse padrão as versões antigas dos registros ficam no TempDB, que é limpo automaticamente pela engine. Sendo assim, a desvantagem é que há uma dependência do banco de dados TempDB.

Recursos avançados

Alta Disponibilidade

Claro que, quando falamos de banco de dados, não dá pra deixar de lado temas como replicação e alta disponibilidade. No fim das contas, toda empresa precisa garantir que seus dados estejam seguros, mesmo em situações inesperadas ou desastres.

Ambos SGBDs oferecem diversos recursos para replicar dados entre ambientes e garantir essa segurança. Existem várias formas de fazer isso, e como o assunto é bem amplo, não vou entrar em detalhes aqui pra não deixar o artigo muito longo, mas fica como ideia pra gente explorar melhor em um próximo post.

Segurança

Tanto o PostgreSQL quanto o SQL Server contam com vários recursos para garantir a segurança dos dados, ambos têm controle de usuários, Roles e permissões, Auditoria e Criptografia dos dados.

Aqui vou focar apenas em alguns desses pontos pra manter o texto mais direto, mas é importante saber que as possibilidades vão bem além disso.

O PostgreSQL tem recursos de controle de linhas:

Row-Level Security: este recurso permite controlar quais linhas cada usuário pode ver ou manipular, diretamente no Banco de Dados.

O SQL Server possui alguns recursos de criptografia, como por exemplo:

TDE (Transparent Data Encryption): que é uma criptografia aplicada diretamente nos arquivos (.mdf, .ldf, e de backup) esta criptografia evita que os arquivos sejam atachados em outro servidor e sejam lidos.

Always Encrypted: este recurso aplica a criptografia à nível de coluna, garantindo que aquela determinada coluna não mostre o texto limpo.

Dynamic Data Masking: Este não é uma criptografia. Ele máscara os dados sensíveis na hora da consulta, mostrando um valor diferente do valor real que está gravado no banco de dados.

Administração

O PostgreSQL é mais flexível, pois possui uma grande variedade de configurações que podem ser ajustadas pelo DBA diretamente nos arquivos de configuração. Isso exige um conhecimento mais aprofundado de cada parâmetro para extrair o melhor desempenho e adaptar o ambiente conforme a necessidade da aplicação.

O SQL Server também possui diversos parâmetros de configuração, porém, por contar com ferramentas mais amigáveis e automatizadas, sua administração acaba se tornando mais simples em muitos cenários. Ainda assim, exige um alto nível de conhecimento tanto da plataforma quanto do ambiente em que está sendo utilizado.

Conclusão

Pessoal, a ideia deste artigo sobre PostgreSQL vs SQL Server não é dizer que um é melhor que o outro, até porque, na prática, eles costumam coexistir em muitas empresas.

O objetivo aqui foi só destacar algumas particularidades de cada um. No fim das contas, tanto o PostgreSQL quanto o Microsoft SQL Server são ferramentas maduras e que performam muito bem, mesmo em cenários com alta concorrência.

Claro que ficou muita coisa de fora, então quem sabe em um próximo artigo eu aprofundo mais essas diferenças.