Como escolher VPS para Metabase e BI próprio

Resposta direta

Para rodar Metabase e BI self-hosted com estabilidade, uma VPS deve ter no mínimo 2 vCPUs, 4 GB de RAM, 40 a 80 GB de SSD e banco interno separado do banco analítico sempre que possível. Para uso real em empresa, com múltiplos dashboards, agendamentos por e-mail e consultas simultâneas, o ponto de partida mais seguro costuma ser 4 vCPUs, 8 GB de RAM, disco SSD ou NVMe e backups testados. O Metabase em si não costuma ser o componente mais pesado. O maior impacto vem das consultas executadas contra PostgreSQL, MySQL, BigQuery, ClickHouse ou outro banco de dados. Por isso, a escolha da VPS precisa considerar CPU, memória, latência, política de acesso, cache, restauração e isolamento entre aplicação, banco interno e fontes de dados.

Resumo rápido

• Para laboratório ou prova de conceito, 2 vCPUs e 4 GB de RAM podem atender bem, desde que as consultas sejam leves.
• Em produção pequena, prefira 4 vCPUs, 8 GB de RAM e pelo menos 80 GB de SSD para logs, plugins, backups e crescimento.
• O banco interno do Metabase deve usar PostgreSQL em produção, não H2, que é mais indicado para testes locais.
• O gargalo mais comum vem das consultas aos bancos de dados conectados, não apenas da interface do Metabase.
• Cache, limites de consulta e modelagem das perguntas reduzem carga em dashboards acessados muitas vezes por dia.
• HTTPS, firewall, autenticação forte e rede privada são tão importantes quanto CPU e RAM.
• Backups precisam incluir banco interno, arquivos de configuração e processo de restauração validado.

Por que Metabase exige mais planejamento que um app simples

Metabase parece simples quando instalado pela primeira vez. Um contêiner Docker sobe em poucos minutos, a interface abre na porta 3000 e o time já consegue conectar um banco PostgreSQL, MySQL ou outro destino. O problema aparece quando esse ambiente sai do teste e vira ferramenta diária de diretoria, financeiro, marketing e produto. A cada dashboard aberto, o Metabase precisa autenticar o usuário, carregar metadados, renderizar gráficos e disparar consultas que podem tocar tabelas com milhões de linhas.

BI self-hosted não é só uma aplicação Java

O Metabase roda sobre a JVM, então consome memória de forma diferente de uma API Node.js pequena ou de um site WordPress básico. Em um cenário leve, a aplicação pode parecer confortável com 2 GB de RAM disponíveis. Em produção, porém, a JVM, o sistema operacional, o banco interno, o proxy reverso e os jobs agendados competem pelo mesmo espaço. Se a VPS tiver 2 GB totais e ainda rodar PostgreSQL local, Nginx, Docker e agentes de monitoramento, a margem fica curta. O resultado costuma ser swap, lentidão no painel de administração e travamentos em horários de pico.

Na prática, pense no Metabase como uma camada de orquestração de perguntas. Ele guarda usuários, permissões, coleções, dashboards, modelos e histórico. O peso das respostas depende do banco consultado. Um gráfico simples que soma vendas do dia pode responder em 200 ms se houver índice e tabela pequena. A mesma pergunta, feita sobre uma tabela transacional sem índice adequado, pode ficar 30 segundos segurando conexão, CPU e memória no banco de origem.

O gargalo costuma aparecer no banco consultado

Por isso, escolher uma VPS para Metabase sem olhar para o banco de dados é um erro comum. Se o mesmo servidor também hospeda PostgreSQL operacional, filas e API do produto, o BI passa a competir com o sistema principal. Em times que usam PostgreSQL como fonte analítica, vale revisar o guia de VPS para banco PostgreSQL antes de juntar tudo no mesmo ambiente. A pergunta central é simples: o dashboard pode disputar recurso com a aplicação que gera receita? Se a resposta for não, separe as camadas.

Um desenho comum para empresas pequenas é manter o Metabase em uma VPS dedicada e consultar um banco de leitura, réplica ou base analítica. Isso evita que uma consulta pesada derrube a aplicação principal. Também facilita aplicar regras de firewall, limitar IPs permitidos e ajustar recursos sem mexer no stack do produto. Não precisa começar complexo, mas precisa começar com separação mínima entre ferramenta de BI, banco interno e banco de produção.

CPU e RAM para Metabase em produção

O dimensionamento de CPU e RAM deve partir de três perguntas: quantas pessoas acessam dashboards ao mesmo tempo, quantas consultas agendadas rodam por hora e qual é o peso médio das perguntas. Um time com 5 usuários, 10 dashboards e bases pequenas tem uma necessidade bem diferente de uma operação com 80 usuários, relatórios por e-mail a cada manhã e consultas em tabelas históricas.

Como começar sem superdimensionar

Para prova de conceito, 2 vCPUs e 4 GB de RAM são um ponto de partida honesto. Essa configuração permite rodar Metabase em Docker, Nginx como proxy reverso e PostgreSQL interno pequeno, desde que o banco interno não seja usado como data warehouse. Um arquivo docker-compose.yml simples pode reservar variáveis como MB_DB_TYPE=postgres, MB_DB_HOST=metabase-db e MB_JETTY_PORT=3000, mas sem expor senhas no repositório. Use arquivo .env fora do Git, permissões restritas e secret manager quando a plataforma oferecer esse recurso.

Em produção pequena, 4 vCPUs e 8 GB de RAM deixam o ambiente mais confortável. A JVM pode trabalhar com limite explícito, por exemplo JAVA_TOOL_OPTIONS=-Xmx3g, enquanto o restante fica para sistema operacional, proxy, PostgreSQL interno e processos auxiliares. Essa configuração suporta dezenas de dashboards leves, principalmente se as consultas estiverem bem indexadas no banco de origem. O ganho não vem só de ter mais memória. Vem de reduzir swap e manter a aplicação previsível quando vários usuários abrem relatórios ao mesmo tempo.

Quando subir para 4 vCPUs ou mais

CPU pesa em renderização, serialização de resultados, cálculos intermediários, jobs de sincronização de metadados e múltiplas requisições simultâneas. Se o time agenda envios de relatórios às 8h, por exemplo, o Metabase pode executar dezenas de consultas em uma janela curta. Nesse caso, 2 vCPUs viram gargalo rápido. Um servidor com 4 vCPUs entrega folga para a aplicação, enquanto 8 vCPUs começam a fazer sentido quando há muitos usuários simultâneos, dashboards públicos, múltiplas fontes de dados e volume alto de perguntas salvas.

Um sinal claro de subdimensionamento é CPU acima de 80 por cento por vários minutos durante aberturas de dashboards, junto com aumento de tempo de resposta. Outro sinal é memória livre quase zerada e uso constante de swap. Swap pode salvar o processo de cair, mas destrói a experiência do usuário. Dashboard que abre em 3 segundos passa para 20 segundos, o navegador parece travado e o time perde confiança na ferramenta.

A melhor abordagem é começar com uma configuração que tenha margem e medir. Use métricas de CPU, RAM, I/O, tempo de resposta HTTP e duração das consultas. Se o provedor permitir upgrade vertical rápido, uma VPS ou Cloud Server inicial com 4 vCPUs e 8 GB pode crescer para 8 vCPUs e 16 GB quando o BI vira parte da rotina. Só não use upgrade de hardware para esconder consulta mal escrita. Índices, filtros de data, materialização de tabelas e cache costumam resolver mais do que dobrar RAM sem critério.

Banco de dados, cache e disco: onde o BI pesa de verdade

O Metabase precisa de um banco interno para guardar configuração, usuários, permissões, coleções, perguntas e dashboards. Em ambiente de teste, muita gente usa o H2 embutido porque é rápido de iniciar. Em produção, a recomendação prática é migrar para PostgreSQL ou outro banco suportado para metadados. Isso simplifica backup, restauração, manutenção e crescimento. Se o arquivo H2 corromper ou ficar preso em um volume mal montado, a recuperação pode virar um problema desnecessário.

Separar o banco interno do Metabase

Uma instalação enxuta pode rodar Metabase e PostgreSQL interno na mesma VPS, principalmente em times pequenos. Mesmo assim, separe volumes, defina rotina de dump e monitore espaço em disco. Um servidor com 80 GB de SSD costuma ser suficiente para a aplicação, banco interno, logs e backups locais temporários. Se os dumps forem retidos por muitos dias no mesmo disco, essa folga desaparece rápido. Um backup diário de 1 GB mantido por 30 dias já consome 30 GB, sem contar logs e snapshots.

Em produção mais séria, o banco interno pode ficar em uma instância separada ou serviço gerenciado. Isso reduz risco operacional. A VPS do Metabase fica responsável pela aplicação, enquanto o PostgreSQL interno recebe backups próprios, parâmetros ajustados e controle de acesso mais rígido. Para empresas que já usam PostgreSQL como fonte de dados, a separação também evita confusão entre banco administrativo do Metabase e banco analítico. Essa distinção parece detalhe, mas ajuda muito em incidentes.

Cache, Redis e consultas repetidas

BI sofre com repetição. O mesmo dashboard de receita pode ser aberto 40 vezes por dia por pessoas diferentes. Se cada acesso recalcula tudo em tempo real, o banco de origem paga a conta. O Metabase tem recursos de cache conforme configuração e edição, mas a estratégia de dados também importa. Tabelas agregadas, views materializadas, filtros obrigatórios por período e limites de linhas reduzem pressão. Quando há camada de cache na arquitetura do produto, o conteúdo sobre VPS para Redis e cache ajuda a pensar em memória, persistência e isolamento para workloads repetitivos.

O disco entra no jogo por três motivos: banco interno, logs e backups. SSD é o mínimo razoável. NVMe pode trazer ganho em I/O, principalmente quando a VPS também roda banco local, mas não corrige consulta sem índice. Em provedores como DigitalOcean, Vultr, Linode, AWS Lightsail, Hetzner, Contabo e LetsCloud, tipo de armazenamento, região, snapshots e limites de transferência variam por plano e localidade. Esses dados precisam ser conferidos nas páginas oficiais antes de qualquer decisão, especialmente quando a contratação envolve produção.

Um exemplo prático: um time com 25 usuários, 50 dashboards e PostgreSQL analítico separado pode rodar bem com Metabase em 4 vCPUs, 8 GB de RAM e 100 GB de SSD. O PostgreSQL analítico, por sua vez, pode precisar de 4 a 8 vCPUs, 16 GB de RAM e disco mais rápido, dependendo do volume. Separar essas contas evita culpar o Metabase por uma lentidão que nasce no banco consultado.

Rede, acesso seguro e exposição dos dashboards

Dashboards carregam dados sensíveis. Receita, churn, margem, ticket médio, folha, funil comercial e indicadores operacionais não devem ficar expostos como uma página qualquer. Em uma VPS para Metabase, segurança de rede e controle de acesso precisam entrar no desenho desde o primeiro deploy, não depois do primeiro incidente. O básico inclui HTTPS, proxy reverso, firewall, autenticação forte, atualização regular e bloqueio de portas desnecessárias.

HTTPS, firewall e portas mínimas

Uma configuração comum usa Nginx ou Caddy na porta 443, com certificado TLS via Let’s Encrypt, encaminhando tráfego para o Metabase na porta interna 3000. A porta 3000 não deve ficar aberta para a internet. No firewall, libere 80 e 443 para web, 22 apenas para IPs administrativos ou via VPN, e conexões de banco somente entre origens conhecidas. Se o banco de dados analítico estiver em outra VPS, prefira rede privada do provedor quando disponível. Caso contrário, use regras por IP, TLS no banco e credenciais com permissão de leitura.

Acesso SSH também merece cuidado. Desative login por senha, use chaves, aplique PermitRootLogin no quando fizer sentido para sua operação e mantenha um usuário administrativo com sudo. Ferramentas como Fail2ban ajudam contra tentativas automatizadas, mas não substituem firewall bem configurado. Em ambientes empresariais, uma VPN ou bastion host reduz muito a exposição. O painel do Metabase deve ter autenticação com senha forte e, quando disponível, SSO ou integração com provedor de identidade.

Usuários externos e latência no Brasil

Latência importa quando usuários acessam dashboards muitas vezes ao dia. Para equipes no Brasil, datacenter local pode reduzir tempo de resposta de ida e volta, principalmente na interface e em dashboards com muitos componentes. Isso não significa que todo BI precise estar no Brasil. Se o banco analítico está nos Estados Unidos e o Metabase no Brasil, as consultas podem cruzar fronteiras a cada atualização. O ideal é aproximar Metabase e fonte de dados, ou pelo menos medir a latência entre eles.

Empresas que atendem clientes brasileiros e transformam dashboards em área logada de produto precisam pensar como SaaS. Nesse cenário, o guia sobre VPS para SaaS no Brasil ajuda a avaliar latência, disponibilidade, suporte operacional e arquitetura com múltiplos componentes. Dashboards embutidos em produto exigem ainda mais cuidado com permissões por cliente, isolamento lógico e limites de consulta. Um erro de configuração pode expor dados de um cliente para outro.

Também existe a camada de governança. Usuários não devem receber acesso direto ao banco de produção se precisam apenas visualizar indicadores. Crie usuários de leitura, limite schemas, esconda tabelas sensíveis e revise permissões no Metabase. A segurança não depende apenas da VPS, mas a infraestrutura precisa permitir esse desenho sem gambiarra.

Comparativo de configurações para Metabase

Não existe uma configuração única que sirva para todo BI self-hosted. O mesmo Metabase pode ser usado por um fundador olhando métricas semanais ou por uma empresa com dezenas de áreas acompanhando indicadores em tempo real. A tabela abaixo organiza perfis técnicos para orientar a escolha inicial. Ela não substitui teste de carga, análise das consultas nem revisão humana de custos, mas ajuda a evitar os dois extremos: servidor pequeno demais para produção ou infraestrutura cara antes de haver uso real.

Perfis de VPS por volume de uso

Perfil de uso	Configuração inicial sugerida	Banco interno	Fonte de dados	Quando faz sentido
Prova de conceito	2 vCPUs, 4 GB RAM, 40 GB SSD	PostgreSQL local pequeno	Banco de teste ou réplica pequena	Validação com 1 a 5 usuários e poucos dashboards
Produção pequena	4 vCPUs, 8 GB RAM, 80 a 100 GB SSD	PostgreSQL local ou separado	PostgreSQL, MySQL ou warehouse externo	10 a 40 usuários, relatórios diários e agendamentos leves
BI crítico	8 vCPUs, 16 GB RAM, 160 GB SSD ou NVMe	PostgreSQL separado	Réplica, warehouse ou banco analítico dedicado	Muitas áreas, dashboards recorrentes e necessidade de alta previsibilidade
Dashboards embutidos	8 vCPUs ou mais, 16 a 32 GB RAM, rede privada	Banco separado com backup próprio	Base analítica por cliente ou modelo multi-tenant	Produto SaaS com clientes acessando relatórios na aplicação

Como ler a tabela sem cair em promessa de performance

A configuração sugerida é ponto de partida, não garantia. Um Metabase com 4 vCPUs e 8 GB pode parecer lento se consultar uma tabela de 80 milhões de linhas sem índice por data. Ao mesmo tempo, um ambiente com 2 vCPUs pode responder bem quando os dashboards usam tabelas agregadas atualizadas a cada hora. A pergunta correta não é apenas quanta RAM o Metabase precisa. A pergunta é quanto trabalho cada visualização exige do conjunto Metabase, rede e banco.

Em provedores de VPS tradicional, Cloud Server e cloud instances, compare recursos além do rótulo comercial. vCPU pode variar em geração de processador, política de compartilhamento e limite sustentado. Disco pode ser SSD, NVMe ou rede distribuída. Transferência mensal, snapshots, backups, rede privada, firewall gerenciado e regiões disponíveis mudam bastante entre Hostinger, HostGator, Locaweb, DigitalOcean, Vultr, Linode ou Akamai, AWS Lightsail, Google Cloud, Azure, Oracle Cloud, Contabo, Hetzner e LetsCloud. Dados de preço, localidade, bandwidth e armazenamento devem ser validados diretamente no site oficial antes da publicação de qualquer comparativo.

LetsCloud pode entrar na análise quando a empresa quer avaliar datacenter no Brasil, contratação local ou menor latência para usuários brasileiros, mas isso precisa ser confirmado por plano e região. NVMe, snapshots, backups automáticos e suporte variam conforme oferta vigente. A recomendação editorial mais segura é testar latência, tempo de resposta do painel e duração das consultas com dados reais antes de migrar o BI da equipe.

Operação diária: backups, updates e observabilidade

Depois que o Metabase vira fonte de decisão, operação passa a importar tanto quanto instalação. Um dashboard fora do ar às 9h pode atrasar reunião comercial, fechamento financeiro ou acompanhamento de campanha. Por isso, o plano de VPS deve incluir rotina de backup, atualização, monitoramento e restauração. Sem isso, a empresa tem uma ferramenta bonita, mas frágil.

Rotina mínima de backup

O backup precisa cobrir o banco interno do Metabase, variáveis de ambiente, arquivos de composição, configurações do proxy e documentação do processo de restore. Se o banco interno for PostgreSQL, um pg_dump diário com retenção de 7 a 30 dias é um começo. Para produção, combine dump lógico com snapshot da instância ou volume, quando o provedor oferecer esse recurso. O ponto mais esquecido é testar a restauração. Backup que nunca foi restaurado é apenas uma hipótese otimista.

Um fluxo simples pode rodar de madrugada: gerar dump, compactar, criptografar, enviar para armazenamento externo e registrar sucesso ou falha em uma ferramenta de alerta. Não guarde a única cópia no mesmo disco da VPS. Se o volume corromper ou a instância for apagada por erro humano, o backup local some junto. Também vale documentar a versão do Metabase, a imagem Docker usada e o comando de inicialização. Em incidentes, detalhes pequenos economizam horas.

Logs e métricas que denunciam gargalos

Observabilidade não precisa começar sofisticada. Monitore CPU, RAM, swap, disco livre, I/O, tempo de resposta HTTP, reinícios do contêiner e tamanho do banco interno. No Metabase, acompanhe duração de consultas, dashboards mais acessados e erros de conexão com fontes de dados. Se a aplicação reinicia sem explicação, verifique OOM killer no sistema operacional. Se dashboards ficam lentos só em horários específicos, cruze logs com jobs agendados, envios de e-mail e sincronização de metadados.

Atualizações também precisam de método. Antes de subir versão, leia notas de release, faça backup, teste em ambiente separado quando possível e planeje janela curta de manutenção. Em Docker, não use a tag latest de forma cega em produção. Prefira versão fixa, como uma tag estável específica, para evitar atualização inesperada. O mesmo cuidado vale para PostgreSQL interno. Atualizar banco sem plano de rollback pode transformar manutenção simples em parada longa.

Um detalhe operacional pouco glamouroso é limpeza. Logs sem rotação, dumps antigos e volumes esquecidos enchem disco. Quando o disco chega perto de 100 por cento, PostgreSQL pode falhar, Metabase pode perder gravações e o sistema fica instável. Configure logrotate, retenção de backups e alertas de 70, 85 e 95 por cento de uso. É simples e evita incidentes previsíveis.

Recomendações por perfil

Dev solo ou analista técnico

Para um dev solo, analista de dados ou fundador validando BI interno, comece simples, mas não improvisado. Uma VPS com 2 vCPUs, 4 GB de RAM e 40 GB de SSD permite testar Metabase com Docker, PostgreSQL interno e proxy HTTPS. Use banco de leitura ou base de teste, nunca credenciais amplas de produção. Limite acesso por IP quando possível e configure backup diário do banco interno. Esse perfil deve priorizar aprendizado, organização das perguntas e boas práticas mínimas de segurança. Se o Metabase virar rotina semanal de decisão, planeje upgrade para 4 vCPUs e 8 GB antes de adicionar muitos usuários.

Time de dados pequeno

Um time pequeno, com 10 a 40 usuários, precisa de mais previsibilidade. A configuração recomendada fica em 4 vCPUs, 8 GB de RAM e 80 a 100 GB de SSD, com PostgreSQL interno bem backupado e fontes de dados separadas. Dashboards usados pela diretoria devem consultar tabelas agregadas, views materializadas ou réplicas de leitura. Evite deixar analistas dispararem consultas pesadas diretamente no banco transacional. Também faz sentido criar coleções por área, revisar permissões mensalmente e monitorar tempo das perguntas mais usadas. Aqui, o custo de uma VPS um pouco maior costuma ser menor que o custo de BI lento em reuniões importantes.

Produção empresarial com BI crítico

Para produção empresarial, trate o Metabase como sistema interno crítico. Use pelo menos 8 vCPUs, 16 GB de RAM, disco SSD ou NVMe conforme disponibilidade do plano, PostgreSQL interno separado e backups externos testados. Coloque o Metabase perto das fontes de dados principais, use rede privada quando disponível e mantenha autenticação centralizada. Se houver dashboards embutidos para clientes, revise multi-tenancy, permissões e limites de consulta com muito cuidado. Empresas nesse estágio devem ter ambiente de homologação, atualização planejada, alertas e documentação de restore. A VPS não é só servidor, é parte da governança de dados da empresa.