Qual plano de banco de dados escolher
O plano do banco define a CPU e a memória de cada instância. Em banco de dados, a memória pesa mais do que em aplicações: quanto mais dados e índices cabem na memória, menos o banco depende do disco e mais rápido ele responde.
Esta página explica o foco de cada plano. Os preços por instância, as engines e as regras de storage estão em Planos de Banco de Dados.
Resumo rápido: PostgreSQL, MariaDB e Valkey Chave-Valor
| Plano | vCPU | RAM | Foco | Exemplos típicos |
|---|---|---|---|---|
db-free | 0,1 | 128 MB | Desenvolvimento e estudo, sem custo | Banco de um protótipo, projeto de faculdade, ambiente de testes |
db-starter | 0,3 | 256 MB | Primeiro banco em produção | Site ou API pequena, SaaS no início, aplicação interna com poucos usuários |
db-basic | 1 | 1 GB | Produção com tráfego constante | API com milhares de usuários, e-commerce pequeno, WordPress |
db-premium | 2 | 2 GB | Bancos maiores, com métricas | SaaS em crescimento, muitas consultas simultâneas, relatórios |
db-enterprise | 8 | 8 GB | Alta carga e grandes volumes | Plataformas com muitos usuários, bases com dezenas de GB em uso frequente |
db-free
Foco: aprender, prototipar e testar sem custo.
O db-free é um PostgreSQL com 1 instância e 1 GB de armazenamento fixo. Ele é ótimo para começar, mas tem pouca memória e CPU: aguenta bem poucas conexões e consultas simples.
- Faz sentido para: desenvolvimento local apontando para um banco na nuvem, projetos de estudo, protótipos e demonstrações, ambiente de testes.
- Dica: configure o pool de conexões da aplicação com poucas conexões (por exemplo, 2 a 5) e evite manter conexões abertas sem uso.
- Não é o ideal para: produção. O plano não tem réplicas, o storage não cresce e o desempenho cai rápido com mais acessos. Quando o projeto ganhar usuários, migre para o
db-starterou superior.
Cada organização pode ter 1 PostgreSQL db-free. MariaDB e Valkey Chave-Valor não têm plano gratuito para organizações novas.
db-starter
Foco: o primeiro banco em produção, com custo baixo.
Com 0,3 vCPU e 256 MB, o db-starter atende aplicações pequenas que já têm usuários reais. O PostgreSQL pode ter de 1 a 3 instâncias, e MariaDB e Valkey sempre usam uma primária e duas réplicas.
- Faz sentido para: sites e APIs com poucos milhares de acessos por dia, SaaS no começo, aplicações internas, banco de um projeto HTTP Basic.
db-basic
Foco: produção com tráfego constante.
Com 1 vCPU e 1 GB, o db-basic mantém mais dados e índices em memória e responde bem a consultas mais complexas.
- Faz sentido para: APIs com milhares de usuários, e-commerces pequenos e médios, WordPress com MariaDB, back-ends de aplicativos móveis.
db-premium
Foco: bancos maiores e visibilidade do desempenho.
Com 2 vCPU e 2 GB, o db-premium é o primeiro plano com métricas de banco: CPU, memória, armazenamento, conexões, cache de leitura, locks, latência e replicação.
- Faz sentido para: SaaS em crescimento, aplicações com muitas consultas simultâneas, bancos usados também por relatórios e ferramentas de BI, como o Metabase.
db-enterprise
Foco: alta carga e grandes volumes de dados em uso frequente.
Com 8 vCPU e 8 GB por instância, o db-enterprise atende plataformas com muitos usuários simultâneos e bases grandes que precisam de bastante memória para manter o desempenho.
Planos de Analytics
Os planos de Analytics são para consultas analíticas sobre grandes volumes de dados, como eventos, logs e métricas de produto. Eles não substituem o banco principal da aplicação.
| Plano | Recursos | Foco |
|---|---|---|
analytics-sandbox | 1 vCPU, 2 GiB, 1 instância | Testes, estudos e protótipos; até 2 consultas simultâneas e consultas de até 5 minutos |
analytics-starter | 4 vCPU, 16 GiB, 1 instância | Primeiras cargas analíticas reais, sem alta disponibilidade |
analytics-production | 2 vCPU e 8 GiB por instância, 3 instâncias | Analytics em produção com alta disponibilidade |
analytics-enterprise | 4 vCPU e 16 GiB por instância, 3 instâncias | Grandes volumes e muitas consultas simultâneas |
Como saber se o plano está certo
| Sinal | O que fazer |
|---|---|
| A aplicação recebe erros de "too many connections" | Reduza o pool de conexões ou suba de plano |
| Consultas que eram rápidas ficam lentas conforme os dados crescem | Revise os índices; se continuar, suba para um plano com mais memória |
| Uso de memória ou CPU sempre alto nas métricas | Suba de plano antes de o banco ficar lento nos horários de pico |
Perguntas frequentes
Posso começar no db-free e migrar depois?
Sim. Crie um banco no plano desejado e migre os dados com pg_dump e pg_restore. Veja Migração.
O plano do banco precisa ser igual ao da aplicação?
Não. Uma aplicação Basic pode usar um banco db-basic, por exemplo. Dimensione cada um pelo que ele faz: a aplicação pelo tráfego e o banco pelo volume de dados e consultas.
Próximos passos
Última atualização em
Qual plano escolher para Jobs agendados
Para que serve cada plano de Job agendado da Zenifra (job-starter, job-basic e job-premium), com exemplos de tarefas que rodam bem em cada um.
Qual plano escolher para Cache e Filas
Para que serve cada plano de Cache e de Filas da Zenifra, do gratuito ao enterprise, com exemplos de uso que fazem sentido em cada um.