PostgreSQL ou MySQL para um sistema novo?

PostgreSQL, na maioria dos casos. Ele traz JSON com índice, busca textual, tipos avançados, Row Level Security e extensões como PostGIS e pgvector sem precisar de outro banco. MySQL continua sendo uma opção sólida quando a equipe já domina e a infraestrutura já existe.

Quando usar MongoDB ou outro NoSQL?

Quando o dado é realmente sem esquema fixo e o volume de escrita é muito alto, como registros de eventos, telemetria ou catálogos com atributos muito variáveis. Para dados de negócio com relacionamentos, transações e relatórios, o relacional continua sendo mais simples e mais confiável.

Preciso de um banco pago como SQL Server ou Oracle?

Só quando existe dependência real do ecossistema, como integração profunda com aplicações .NET legadas ou exigência do cliente. A licença representa um custo recorrente relevante, e os bancos livres atendem o que a grande maioria dos sistemas corporativos precisa.

Qual banco de dados escolher para o sistema da empresa

Para quase todo sistema de empresa, a resposta é PostgreSQL. É gratuito, maduro, roda em qualquer provedor, resolve dado relacional e JSON no mesmo lugar e traz recursos que em outros bancos exigem componentes extras. As exceções existem e são específicas: MySQL em ambientes que já o adotaram, SQL Server quando há dependência do ecossistema Microsoft, e bancos não relacionais como complemento, não como substituto.

O critério de escolha, em ordem

Antes de comparar produtos, responda três perguntas:

O dado tem relacionamentos e precisa de consistência? Pedido pertence a cliente, item pertence a pedido, o estoque não pode ficar negativo. Se sim, você quer um banco relacional. Isso cobre a esmagadora maioria dos sistemas corporativos.
Alguém vai tirar relatório cruzando entidades? Se sim, SQL resolve em uma consulta o que em banco de documentos vira código de aplicação.
A equipe conhece qual? Um banco que o time domina e opera com segurança vale mais que uma escolha teoricamente superior que ninguém sabe ajustar às 3h da manhã.

Comparativo entre as opções

Banco	Licença	Melhor para	Ponto fraco
PostgreSQL	Livre	Padrão para sistemas de negócio, JSON, busca, geoespacial, IA	Ajuste fino exige mais estudo
MySQL / MariaDB	Livre	Aplicações web tradicionais, ecossistema PHP	Menos recursos avançados nativos
SQL Server	Paga	Ambientes .NET com integração corporativa existente	Custo de licença recorrente
SQLite	Livre	Aplicação desktop, mobile, protótipo, testes	Não serve para escrita concorrente na web
MongoDB	Livre / paga	Documentos sem esquema fixo, catálogos muito variáveis	Relatório cruzado e consistência dão mais trabalho
Redis	Livre	Cache, fila, sessão, contador em tempo real	Não é banco principal, é memória

Por que PostgreSQL costuma ganhar

O argumento não é ideológico, é de escopo. Muita coisa que exigiria um segundo sistema já vem dentro:

JSONB com índice. Guarde documento sem esquema fixo em uma coluna e consulte com desempenho. Resolve boa parte dos casos em que alguém cogitaria MongoDB, sem abrir mão de transação.
Busca textual nativa. Para catálogos e bases de conteúdo de porte médio, dispensa um mecanismo de busca separado.
Row Level Security. Isolamento por cliente garantido pelo banco, essencial em multi-tenant.
pgvector. Busca por similaridade para RAG e recomendação, no mesmo banco onde já estão os dados. Evita sincronizar duas bases.
PostGIS. Consulta geográfica de nível profissional.
Extensões e tipos, intervalos, arrays, tipos próprios, que reduzem código de aplicação.

Menos peças significa menos coisas para monitorar, atualizar, fazer backup e sincronizar. Em equipe pequena, isso vale mais que qualquer benchmark.

Quando MySQL ainda é a escolha certa

Se a empresa já roda MySQL, a equipe conhece, os backups funcionam e o sistema novo não precisa de nada que só o PostgreSQL oferece, manter MySQL é uma decisão sensata. Ele é rápido, estável e tem ferramental maduro.

O que costuma faltar: JSON com o mesmo nível de indexação, Row Level Security nativo e o ecossistema de extensões. Se o roadmap inclui multi-tenant com isolamento no banco ou busca vetorial, o PostgreSQL evita retrabalho.

Quando NoSQL realmente se justifica

Bancos não relacionais resolvem problemas específicos muito bem. O erro é adotá-los como banco principal de um sistema de negócio, e depois reimplementar transação, integridade e relatório na aplicação.

Casos em que fazem sentido:

Registro de eventos e telemetria. Volume enorme de escrita, leitura por intervalo de tempo, sem relacionamento. Bancos de séries temporais ou de documentos brilham aqui.
Cache e sessão. Redis, sem discussão. É complemento, não substituto.
Catálogo com atributos radicalmente variáveis entre categorias, com milhões de itens.
Documento realmente sem forma, vindo de fonte externa, guardado como está para processamento posterior.

Em todos esses casos, o padrão saudável é relacional como fonte da verdade e o não relacional como camada especializada ao lado.

Decisões que importam mais que a marca do banco

Trocar de banco raramente é o que resolve um problema de desempenho ou de confiabilidade. Estes itens pesam mais:

Modelagem. Chaves estrangeiras declaradas, restrições de unicidade, NOT NULL onde faz sentido, tipos corretos. Deixar a integridade só na aplicação é como não ter integridade: um script de importação passa por cima.

Índices. A causa mais comum de sistema lento é consulta sem índice adequado, não banco fraco. Índice se define olhando as consultas reais, não chutando.

Migrações versionadas. Alteração de estrutura precisa estar em arquivo no repositório, aplicada de forma automática e repetível. Mudança feita à mão em produção é dívida garantida.

Backup testado. Um banco excelente com backup nunca restaurado protege tanto quanto banco nenhum.

Fuso e codificação. Guarde data e hora em UTC com fuso, e use UTF-8 em tudo. Corrigir isso depois, com anos de dados dentro, é caro e chato.

Recomendação prática

Sistema novo de empresa, sem restrição externa: PostgreSQL, com Redis ao lado quando surgir necessidade de cache ou fila. Se aparecer demanda de busca por similaridade para IA, use pgvector no mesmo banco antes de adotar um serviço separado.

Ambiente com MySQL consolidado: siga com MySQL, mas avalie o PostgreSQL para o próximo sistema que exigir multi-tenant, busca ou vetores.

Ecossistema Microsoft com integrações existentes: SQL Server pode compensar, desde que o custo de licença entre no orçamento de operação desde o primeiro dia.

Em qualquer cenário, dedique mais atenção à modelagem, aos índices e ao backup do que à escolha do produto. É ali que os sistemas quebram.