PostgreSQL vs MySQL: qual usar na VPS?

PostgreSQL e MySQL são os dois bancos relacionais open source mais usados no mundo. A escolha correta depende do seu caso de uso: MySQL (MariaDB) é mais simples de operar e amplamente suportado por apps PHP/CMS; PostgreSQL tem tipos de dados mais ricos, melhor conformidade com SQL padrão e features avançadas como JSONB, CTEs e window functions. Para a maioria dos novos projetos em 2025, PostgreSQL é a escolha padrão.

Comparativo direto: PostgreSQL vs MySQL

As diferenças práticas que importam no dia a dia:

bash
# PostgreSQL — pontos fortes
✓ Conformidade SQL completa (CTEs, window functions, arrays, JSONB)
✓ JSONB com índices GIN (NoSQL-like dentro do relacional)
✓ Tipos avançados: arrays, ranges, enums, UUID nativo, tsvector (full-text)
✓ Melhor para queries analíticas complexas
✓ MVCC mais completo (leituras nunca bloqueiam escritas)
✓ Transações DDL (ALTER TABLE em transação com rollback)
✓ Extensões: PostGIS, TimescaleDB, pg_vector, pgcrypto

# MySQL/MariaDB — pontos fortes
✓ Mais leve em RAM (MariaDB parte de ~100 MB vs 150 MB do PG)
✓ Suporte nativo de WordPress, phpMyAdmin, Joomla, Magento
✓ Replicação master-slave mais fácil de configurar
✓ Mais familiar para devs vindos de hospedagem compartilhada
✓ MariaDB é drop-in replacement com features extras

Quando escolher MySQL/MariaDB

MySQL é a escolha natural em alguns contextos específicos:

bash
# Use MySQL/MariaDB quando:

# 1. Stack WordPress / PHP clássico
# WordPress, Joomla, Drupal, Magento são otimizados para MySQL
# Plugins e themes assumem MySQL — suporte PostgreSQL é parcial

# 2. App legado que já usa MySQL
# Custo de migração > benefício de mudança de banco

# 3. Replicação simples master-slave
# MySQL tem binlog replication mais simples de configurar
# Útil para read replicas em apps de alto tráfego de leitura

# 4. Equipe familiarizada com MySQL
# Sem necessidade das features avançadas do PostgreSQL

# docker-compose.yml para MariaDB
services:
  db:
    image: mariadb:11
    environment:
      MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
      MYSQL_DATABASE: ${DB_NAME}
      MYSQL_USER: ${DB_USER}
      MYSQL_PASSWORD: ${DB_PASSWORD}

Quando escolher PostgreSQL

PostgreSQL é a escolha padrão para projetos novos e apps modernas:

bash
# Use PostgreSQL quando:

# 1. App moderna (Node.js, Python, Go, Ruby on Rails)
# Prisma, SQLAlchemy, GORM, ActiveRecord têm suporte primeiro-classe
# Supabase, Neon, Render, Railway usam PostgreSQL como padrão

# 2. Dados semiestruturados (JSONB)
# Coluna JSONB com índice GIN é comparável ao MongoDB
# Sem precisar de segundo banco

# 3. Queries analíticas
# CTEs recursivas, window functions, LATERAL JOINs
# Mais expressivo que MySQL para SQL complexo

# 4. Apps que precisam de UUIDs, arrays, ranges
# PostgreSQL tem esses tipos nativos — MySQL usa VARCHAR/JSON

# 5. PostGIS para dados geográficos
# Único banco relacional com suporte geoespacial completo

# 6. Integrações AI/vector search
# pgvector (extensão) adiciona busca por similaridade de vetores
# Usado por LangChain, LlamaIndex, Supabase Vector

Performance: quem é mais rápido?

Não existe resposta única, depende do workload. Benchmarks gerais para orientação:

bash
# Leitura simples (SELECT por PK):
# MySQL: ligeiramente mais rápido em cenários simples com InnoDB
# PostgreSQL: equivalente, melhor em concorrência alta

# Escritas simultâneas (OLTP):
# PostgreSQL: melhor MVCC — leituras nunca bloqueiam escritas
# MySQL: pode ter contenção com locks em cargas mistas

# Queries analíticas complexas (GROUP BY, JOINs múltiplos):
# PostgreSQL: significativamente melhor (planner mais sofisticado)

# Full-text search:
# PostgreSQL: tsvector nativo com ranking e stemming
# MySQL: FULLTEXT index (funcional mas menos flexível)

# Teste de benchmark rápido (pgbench):
docker compose exec postgres pgbench -U postgres -i -s 50 meu_banco
docker compose exec postgres pgbench -U postgres -c 10 -j 2 -T 60 meu_banco

Migrar de MySQL para PostgreSQL

Para apps que querem migrar, pgloader automatiza boa parte do processo:

bash
# Instalar pgloader
docker run --rm dimitri/pgloader:latest pgloader --version

# Migrar banco MySQL para PostgreSQL
docker run --rm dimitri/pgloader:latest pgloader \
  mysql://usuario:senha@host_mysql/banco_mysql \
  postgresql://postgres:senha@host_postgres/banco_postgres

# pgloader converte automaticamente:
# - tipos de dados (TINYINT → boolean, DATETIME → timestamp, etc.)
# - AUTO_INCREMENT → SERIAL ou BIGSERIAL
# - Índices e foreign keys

# Verificar após migração
docker compose exec postgres psql -U postgres -d banco_postgres \
  -c "SELECT tablename, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC;"

Não quer configurar manualmente?

Implante o PostgreSQL em menos de 5 minutos com a Runstack. Infraestrutura da OPEN Datacenter, com servidores em São Paulo.

Perguntas frequentes

Na maioria dos casos sim, MariaDB é um fork do MySQL com API compatível. Apps que declaram suporte a MySQL 5.7+ geralmente funcionam com MariaDB 10.x sem mudanças. Exceções: algumas features específicas do MySQL 8+ (como window functions com sintaxe diferente) podem ter comportamento distinto. Para WordPress e PHP clássico, MariaDB é preferível ao MySQL pela licença mais liberal e manutenção ativa.

Sim, para aplicações com baixo volume de escritas e sem acesso concorrente pesado. SQLite é excelente para: apps de usuário único, prototipagem, apps de linha de comando, e cenários onde simplicidade > escala. Não é adequado para: múltiplas aplicações acessando o banco simultaneamente, replicação, ou mais de ~1000 writes/segundo.

Marginalmente no baseline. PostgreSQL usa ~150 MB de RAM em idle; MariaDB ~100 MB. A diferença fica pequena comparada ao shared_buffers configurado. Em produção, ambos podem usar GBs de RAM dependendo da configuração de buffer pool. A diferença de baseline raramente é decisiva na escolha.

Supabase é PostgreSQL com camadas extras: autenticação, storage, realtime e API REST gerada automaticamente. Para apps que precisam dessas features (especialmente auth + realtime), Supabase self-hosted economiza meses de desenvolvimento. Para apps que só precisam do banco, PostgreSQL puro é mais simples e leve.

n8n: PostgreSQL recomendado (melhor suporte, mais estável em produção). Chatwoot: PostgreSQL obrigatório (Rails com ActiveRecord e migrações específicas para PG). Flowise: SQLite (padrão) ou PostgreSQL. A maioria das ferramentas modernas self-hosted escolheu PostgreSQL como banco primário, seguir esse padrão simplifica a operação.