DEV Community: Williane Felix

MySQL vs MongoDB vs Redis: Um Estudo de Performance e Carga em Aplicações Web

Williane Felix — Sat, 14 Feb 2026 00:40:46 +0000

O Dilema da Persistência e Latência

No desenvolvimento moderno, a escolha do banco de dados não é mais uma decisão binária entre SQL e NoSQL. O desafio real de engenharia é equilibrar consistência, escalabilidade e latência.

Este estudo nasceu do projeto willyfelix/todolist-db-comparison, onde submeti uma aplicação de Todo List a testes de estresse. O objetivo? Analisar como o MySQL (integridade referencial), o MongoDB (flexibilidade documental) e o Redis (velocidade em memória) se comportam sob carga extrema.

A Aplicação: Todo List

A aplicação consiste em uma API REST desenvolvida em Python/Flask. Foram criadas duas versões idênticas: uma sobre MySQL e outra sobre MongoDB, garantindo que as métricas reflitam o banco de dados e não a lógica de negócio.

Por que uma Todo List?

É um domínio universal que permite medir o impacto real do CRUD sem complexidade adicional:

Relacional (MySQL): Testa conexões entre usuários e tarefas.
NoSQL (MongoDB): Testa a performance de objetos aninhados.
Cache (Redis): Avalia o ganho em cenários de leitura intensiva.

Arquitetura e Implementação

MySQL - Abordagem Relacional

Uso de schema fixo e tipado com índices estratégicos para otimização de busca.

CREATE TABLE todos (
    id INT PRIMARY KEY AUTO_INCREMENT,
    titulo VARCHAR(255) NOT NULL,
    concluida BOOLEAN DEFAULT FALSE,
    data_criacao TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_concluida (concluida)
);

MongoDB - Abordagem NoSQL

Documentos BSON flexíveis que favorecem a escrita rápida e escalabilidade horizontal.

{
  "_id": ObjectId("..."),
  "titulo": "Título da tarefa",
  "concluida": false,
  "data_criacao": ISODate("...")
}

Redis - O Poder da Memória

Implementamos três estratégias clássicas de cache para observar os trade-offs de cada uma:

Cache-Aside (Lazy Loading): O dado é carregado no cache apenas sob demanda.
Write-Through: Escrita simultânea no banco e no cache.
Write-Behind: Foco total em performance; escreve no cache primeiro e no banco de forma assíncrona.

Resultados e Benchmarks

Testes realizados em ambiente local.

1. Inserção de Dados (Bulk Insert)

Volume	MySQL	MongoDB	MySQL + Redis	MongoDB + Redis
10k	34.247	51.370	125.800	128.400
100k	41.025	61.537	155.900	158.700

Análise: O MongoDB superou o MySQL em 58% na escrita nativa devido ao modelo de documentos desnormalizados. Com Redis, o throughput saltou para 150k reg/s, provando que a RAM elimina o gargalo de I/O de disco.

2. Operações de Leitura (GET)

Métrica	MySQL	MongoDB	Redis (Híbrido)
Tempo Médio	2550.1ms	185.4ms	1.1ms
Throughput	3.91 req/s	5.39 req/s	925.9 req/s

Análise: O Redis reduziu a latência em mais de 2000 vezes comparado ao MySQL sob carga. O teste confirma que, para leituras repetitivas, a persistência em disco não consegue competir com a velocidade sub-milissegundo da memória.

3. Operações de Escrita (POST)

Métrica	MySQL	MongoDB	Redis (Híbrido)
Tempo Médio	2385.8ms	412.3ms	15.2ms
Throughput	4.18 req/s	24.2 req/s	657.8 req/s

Análise: O MongoDB foi 6x mais rápido que o MySQL em escritas puras, mas a arquitetura híbrida com Redis dominou com 657 req/s. Delegar a confirmação de escrita para o cache desafoga o banco principal e escala a aplicação.

4. Atualização (PUT)

Métrica	MySQL	MongoDB	Redis (Híbrido)
Tempo Médio	2476.2ms	435.1ms	16.4ms
Throughput	4.04 req/s	22.9 req/s	607.9 req/s

Análise: O combo MongoDB + Redis manteve a liderança com 16ms de resposta média. O desafio aqui reside na coerência: o cache garante velocidade, mas exige estratégias como Write-Through para sincronizar o dado no banco persistente.

5. Deleção (DELETE)

Métrica	MySQL	MongoDB	Redis (Híbrido)
Tempo Médio	2514.7ms	398.1ms	13.8ms
Throughput	3.97 req/s	2.51 req/s	72.4 req/s

Análise: O MySQL mostrou-se ligeiramente mais estável que o MongoDB puro em deleções massivas. No entanto, o Redis padronizou a performance para 13ms, garantindo que o usuário perceba a remoção de forma instantânea.

Análise Comparativa

MySQL: O Porto Seguro

Vantagem: Consistência ACID e integridade referencial absoluta.
Gargalo: O custo do disco e os locks de linha tornam a latência alta sob estresse.

MongoDB: O Atleta de Performance

Vantagem: Escrita até 6x mais rápida que o SQL e esquema flexível.
Gargalo: Consumo de RAM elevado para manter índices e working set.

Redis: O Motor de Fórmula 1

Vantagem: Reduziu a latência em 2000x. Essencial para evitar que o banco principal sofra com picos de tráfego.

Principais Aprendizados

Latência é o Gargalo Silencioso: O I/O de disco é o maior inimigo da escala. O Redis provou que a RAM é o divisor de águas.
Trade-off de Rigidez: O MySQL garante dados limpos, mas o MongoDB entrega agilidade. A escolha depende da prioridade do projeto.
Cache exige Estratégia: Não basta "instalar". Escolher entre Cache-Aside ou Write-Through define se seu usuário verá dados obsoletos ou não.

Recomendação Final

Se você está construindo uma aplicação que pretende crescer, minha recomendação baseada nos dados é: não escolha apenas um. Este conceito de combinar diferentes tecnologias é o que a literatura técnica chama de Persistência Poliglota. Segundo Martins et al. (2024), essa abordagem é fundamental para superar as limitações de modelos únicos em cenários de alta demanda.

Para um sistema de tarefas ou similar:

Use MongoDB ou MySQL como sua "Fonte da Verdade" (Single Source of Truth), onde os dados residem com segurança.

Implemente Redis obrigatoriamente para as rotas de GET, utilizando a estratégia de Cache-Aside com um TTL (Time to Live) curto (ex: 5 a 10 minutos). Isso reduzirá a carga no seu banco principal em até 90%, permitindo que você rode em servidores mais baratos e ofereça uma interface instantânea para o usuário final.

Recursos e Referências

Código fonte no GitHub
Redis Documentation
NoSQL Databases
MySQL
Martins, L. S. S. et al. (2024). Persistência Poliglota: o armazenamento de dados e suas possibilidades. Link DOI
Martin Fowler. Patterns of Enterprise Application Architecture.

Git diff em Ação: Analisando e Compreendendo Alterações no Seu Repositório

Williane Felix — Thu, 25 Sep 2025 18:21:29 +0000

O controle eficiente de versão é um pilar fundamental no desenvolvimento de software, e o Git se destaca como uma ferramenta indispensável nesse cenário. No coração do Git, encontramos o comando git diff, uma poderosa ferramenta que possibilita analisar, compreender e gerenciar alterações no código-fonte.

Seja você um iniciante curioso, um desenvolvedor experiente ou um colaborador envolvido em revisões de código, entender como o git diff funciona é crucial para otimizar o fluxo de trabalho e manter um histórico de alterações preciso. Este breve guia abrange algumas dicas de como utilizar essa ferramenta.

Fundamentos

É importante destacar algo evidente, mas muitas vezes negligenciado: mantenha uma atenção constante nas alterações que você realiza.

Isso se torna particularmente relevante quando modificamos um código para testes ou experimentos e, posteriormente, esquecemos de desfazer a alteração. Por isso, é altamente recomendável fazer uso do comando:

$ git diff

O comando git diff, sem argumentos, permite visualizar as alterações que ainda não foram selecionadas para o commit.

Dessa forma, na linha de comando, o Git sinaliza essas mudanças como "Changes not staged for commit". Mudanças em arquivos não versionados (untracked files) ou alterações que não foram selecionadas para o commit não são consideradas pelo git diff. Entretanto, por experiência prática, revisar as alterações antes de incluí-las no commit pode ser extremamente útil.

Além disso, após realizar um commit, você ainda pode aproveitar esse comando para revisar as diferenças que ainda não foram enviadas para o repositório remoto, evitando possíveis problemas.

Comandos básicos do git diff

O git diff oferece parâmetros que permitem comparações entre versões, incluindo referências por commit, branches e tags.

Aqui estão alguns exemplos:

· Para exibir alterações no índice, basta por git diff e o caminho do arquivo:

Obs.: Antes do comando git diff você deve executar o comando git status para identificar o path do arquivo que você quiser ver as alterações, caso você execute o git diff sem nenhum caminho, ele retornará todos arquivos modificados.

$ git diff src/pages/App.svelte

· Para analisar as diferenças entre seu código atual e uma branch local chamada master:

$ git diff master

· Para verificar as diferenças entre seu código atual e uma branch remota chamada development:

$ git diff origin/development

· Visualizando modificações na árvore de trabalho em relação a um commit específico:

$ git diff 568e80b62218db68043f388300896a9b6db77c5d

· Para revisar as diferenças entre dois commits específicos:

Obs: para saber o identificador do commit execute o comando “git log”.

$ git diff f8b95c57d46052e612b0d9c504d97fe052eec185 674068c36accd9c1f5a6350bc9eb9c83f7058474

Dica: Você também pode usar uma parte do SHA1, que é o identificador do commit, desde que não seja uma referência ambígua:

$ git diff f8b95c5 674068c

· Para verificar as diferenças entre seu código atual e um commit nomeado com uma tag chamada 1.0:

$ git diff 1.0

Conclusão

Essas diversas formas, dentre outras, de utilizar o git diff fornecem flexibilidade para analisar e comparar alterações em diferentes contextos, desde a preparação de commits até análises mais avançadas de históricos de código.