--- title: "Como escolher VPS para banco de dados: RAM, CPU e NVMe" description: "Dimensione a VPS do seu banco de dados pelo tamanho dos dados, pelas conexões e pela escrita: RAM, CPU, NVMe, IOPS, rede e planos reais lado a lado." url: "https://streethosting.com.br/guias/vps/escolher-vps-banco-de-dados" category: "vps" slug: "escolher-vps-banco-de-dados" datePublished: "2026-09-28" dateModified: "2026-09-28" author: "Equipe StreetHosting" difficulty: "intermediario" language: "pt-BR" keywords: - "vps para banco de dados" - "escolher vps banco de dados" - "vps postgresql mysql mongodb" - "ram para banco de dados" - "iops nvme banco de dados" --- # VPS para banco de dados: como dimensionar sem pagar a mais Banco de dados lento raramente se resolve com mais vCPU: quase sempre falta RAM para os dados mais usados ou sobra latência no disco. Veja como medir o que o seu banco consome e escolher o plano pelo número certo. > **Resposta rápida** > > Para escolher uma **VPS para banco de dados**, comece pela RAM: índices e dados consultados com frequência precisam caber na memória. Depois olhe a latência de escrita do disco, que NVMe resolve bem, e só então a CPU. Xeon entrega mais RAM e vCPU por real para muitas conexões; Ryzen 9 9950X acelera consultas pesadas. Um banco de até 10 GB roda bem com 8 GB de RAM, a partir de R$ 74,00 por mês na linha Xeon. ## O que um banco de dados consome Uma aplicação web típica passa a maior parte do tempo esperando o banco, e o banco passa a maior parte do tempo esperando o disco quando a memória não basta. Por isso a ordem de prioridade para bancos transacionais, como PostgreSQL, MySQL, MariaDB e MongoDB, costuma ser esta: - **RAM:** define quanto do banco é servido sem tocar no disco. Falta de memória é a causa mais comum de lentidão. - **Latência do disco:** cada transação confirmada espera a gravação no log. Disco lento limita quantos commits por segundo o banco aguenta. - **CPU:** pesa em consultas complexas, ordenações, agregações e em muitas conexões ao mesmo tempo. - **Rede:** quase nunca é gargalo de banda, mas a distância entre aplicação e banco se multiplica pelo número de consultas de cada requisição. Redis é a exceção: todo o conjunto de dados vive na memória, então a conta dele é quase só RAM. O dimensionamento genérico de um projeto serve de ponto de partida; aqui o foco é o que muda quando o protagonista é o banco. ## RAM: o conjunto de dados quente Nenhum banco precisa do arquivo inteiro na memória. Ele precisa do conjunto quente: os índices e as linhas que são lidas o tempo todo. Uma loja com 20 GB de histórico de pedidos pode ter só 2 GB de dados consultados todo dia. Se esses 2 GB e os índices cabem na RAM, o banco responde rápido; se não cabem, cada consulta vira leitura de disco. Cada motor usa a memória de um jeito: | Banco | Onde fica o cache | Ponto de partida em VPS dedicada ao banco | | --- | --- | --- | | PostgreSQL | shared_buffers mais o cache de arquivos do sistema | shared_buffers em 25% da RAM, o resto fica para o sistema | | MySQL e MariaDB | innodb_buffer_pool_size | 50% a 70% da RAM, deixando folga para conexões | | MongoDB | Cache do WiredTiger mais o cache do sistema | Por padrão, metade do que sobra da RAM depois de descontar 1 GB | | Redis | Todo o conjunto de dados | maxmemory abaixo da RAM, com folga para o processo de persistência | Para estimar, meça o tamanho atual dos dados e dos índices. Os comandos abaixo mostram isso em cada banco: ``` -- PostgreSQL SELECT pg_size_pretty(pg_database_size('meu_banco')); -- MySQL e MariaDB (em MB, por banco) SELECT table_schema, ROUND(SUM(data_length + index_length) / 1024 / 1024) AS mb FROM information_schema.tables GROUP BY table_schema; // MongoDB, no mongosh (em MB) db.stats(1024 * 1024) ``` Some à memória do cache a das conexões. No PostgreSQL, cada conexão é um processo que consome alguns MB parado e mais memória quando ordena ou agrupa resultados. Cem conexões abertas por uma aplicação mal configurada ocupam uma fatia real da RAM, e é por isso que um pooler como o PgBouncer entra em cena, como mostra o guia de [PostgreSQL na VPS](https://streethosting.com.br/guias/vps/instalar-postgresql-vps-ubuntu). > **Atenção** > > Banco de dados e swap não combinam. Quando o sistema começa a jogar páginas do banco para o disco, a latência explode sem erro visível. Uma swap pequena serve como rede de segurança contra o OOM killer, mas se ela é usada o tempo todo, falta RAM. ## NVMe, IOPS e latência de escrita Dois números definem o disco para banco de dados. O primeiro é IOPS em leitura e escrita aleatória de blocos pequenos, que é o padrão de acesso de um banco quando os dados não estão na memória. O segundo, mais importante e menos lembrado, é a latência de sincronização: cada commit só é confirmado depois que o log de transações é gravado de forma durável. É esse tempo que limita quantas transações por segundo o banco confirma. Todas as VPS da StreetHosting usam NVMe, que tem latência muito menor que SSD SATA ou HDD. Em vez de confiar em número de catálogo, meça na sua VPS com o `fio`: ``` sudo apt install -y fio # leitura e escrita aleatória em blocos de 4 KB, 70% leitura fio --name=aleatorio --filename=/var/tmp/fio.teste --size=2G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --ioengine=libaio --direct=1 --runtime=60 --time_based --group_reporting # latência de gravação com sincronização a cada bloco, parecida com um commit fio --name=commit --filename=/var/tmp/fio.sync --size=256M --rw=write --bs=8k --ioengine=sync --fdatasync=1 --runtime=30 --time_based rm /var/tmp/fio.teste /var/tmp/fio.sync ``` No primeiro teste, olhe as IOPS de leitura e escrita. No segundo, olhe os percentis de latência da sincronização: quanto menor e mais estável, mais commits por segundo. Quem usa PostgreSQL tem ainda o `pg_test_fsync`, que compara os métodos de sincronização disponíveis. Rode os testes em horários diferentes: a estabilidade ao longo do dia diz tanto quanto o número máximo. Para o espaço em disco, some dados, índices, o log de transações, as cópias locais de backup e o crescimento de um ano, e mantenha pelo menos 30% livre. Operações como `VACUUM FULL` no PostgreSQL ou alterações de tabela no MySQL reescrevem a tabela inteira e precisam de espaço temporário do tamanho dela. ## CPU: Xeon ou Ryzen para banco Uma consulta, na maioria dos bancos, roda principalmente em um núcleo. O PostgreSQL consegue paralelizar varreduras grandes, mas o caso comum de uma aplicação web é muita consulta curta de muitas conexões ao mesmo tempo. Isso cria duas situações diferentes: - **Muitas conexões, consultas simples:** o que importa é ter núcleos para atender todas em paralelo. A linha Xeon E5-2680 v4 entrega mais vCPU por real e casa com esse perfil. - **Poucas consultas pesadas:** relatórios, agregações, buscas em JSON e junções grandes dependem da velocidade de cada núcleo. O Ryzen 9 9950X, com até 5,7 GHz e DDR5, reduz o tempo de cada uma. A diferença entre os dois perfis está detalhada no comparativo [VPS Ryzen ou Xeon](https://streethosting.com.br/guias/vps/vps-ryzen-vs-vps-xeon). Antes de trocar de CPU, confira se o problema não é uma consulta sem índice: um índice certo costuma render mais que qualquer upgrade. ## Rede, localização e estabilidade Uma requisição que faz 30 consultas ao banco paga 30 vezes a latência de ida e volta. Com banco e aplicação na mesma VPS, essa latência é de microssegundos. Com o banco em outro país, cada consulta custa dezenas de milissegundos, e a página que carregava em 50 ms passa a levar mais de um segundo. Por isso o banco deve ficar perto da aplicação, e a aplicação perto dos usuários: para público brasileiro, as duas em São Paulo. Estabilidade em VPS significa receber a CPU contratada quando o banco precisa dela. O indicador é o tempo de steal, que mostra quanto a sua VM esperou pelo processador físico. Acompanhe com `vmstat 1 10`, nas colunas *st* (steal) e *wa* (espera por disco). O que é normal e o que é sinal de problema está em [o que é CPU steal](https://streethosting.com.br/guias/vps/o-que-e-cpu-steal-vps). - [ ] Porta do banco fechada para a internet, acessível só pela aplicação ou por VPN - [ ] Backup agendado e copiado para fora da VPS - [ ] Restauração testada pelo menos uma vez por trimestre - [ ] Alerta de disco acima de 80% e de swap em uso contínuo - [ ] Monitoramento de conexões abertas e consultas lentas O backup merece destaque: a VPS não inclui serviço de backup nem snapshot automático, então a cópia dos dados é responsabilidade sua. O guia de [backup automático com restic e cron](https://streethosting.com.br/guias/vps/automatizar-backup-vps-restic-cron) mostra como enviar os dumps para um destino externo. ## Tabela de dimensionamento A tabela parte do tamanho do banco em disco e do volume de conexões e sugere um plano de cada linha. Considere como ponto de partida: meça o uso real nas primeiras semanas e ajuste. | Cenário | Dados e conexões | VPS Xeon | VPS Ryzen 9 9950X | | --- | --- | --- | --- | | MVP, bot ou site pequeno com o banco junto | Até 2 GB, poucas dezenas de conexões | 3 vCPU, 4 GB, 40 GB: R$ 40,00 | 2 vCPU, 4 GB, 40 GB: R$ 64,00 | | Loja virtual ou SaaS inicial | Até 10 GB, até 100 conexões | 6 vCPU, 8 GB, 80 GB: R$ 74,00 | 4 vCPU, 8 GB, 80 GB: R$ 114,00 | | Banco de SaaS em crescimento | 10 a 40 GB | 9 vCPU, 16 GB, 160 GB: R$ 142,00 | 6 vCPU, 16 GB, 160 GB: R$ 214,00 | | Muitos clientes simultâneos e relatórios | 40 a 120 GB | 15 vCPU, 32 GB, 320 GB: R$ 278,00 | 10 vCPU, 32 GB, 320 GB: R$ 414,00 | | Base grande com índices pesados | 120 a 400 GB | 24 vCPU, 64 GB, 640 GB: R$ 550,00 | 14 vCPU, 64 GB, 640 GB: R$ 814,00 | | Acima de 640 GB ou mais de 64 GB de RAM | Dados e cache além do limite da VPS | Dedicado AMD Budget LG, 128 GB, NVMe 2 TB: R$ 1.679,00 | Dedicado AMD Extreme SM, 128 GB DDR5: R$ 2.199,00 | As faixas deixam espaço em disco para índices, log de transações e uma cópia local do backup. Se o conjunto quente for pequeno em relação ao total, como em históricos que quase nunca são lidos, um plano abaixo pode bastar. A linha Budget com Ryzen 9 5900XT aparece na mesma página da Ryzen, mas está sem estoque no momento. ## Banco na mesma VPS ou separado Começar com aplicação e banco na mesma VPS é a escolha certa para a maioria dos projetos: menos latência, menos custo e menos peças para administrar. A separação passa a fazer sentido em situações concretas: - **Disputa de memória:** picos da aplicação empurram o cache do banco para fora e as consultas ficam lentas justo na hora de maior tráfego. - **Várias aplicações no mesmo banco:** um servidor de banco central evita dados duplicados e simplifica o backup. - **Aplicação em mais de um servidor:** para distribuir a aplicação atrás de um balanceador de carga, o banco precisa estar fora das instâncias. - **Isolamento:** uma falha de segurança na aplicação não dá acesso direto ao sistema onde estão os dados. > **Dica** > > Ao separar, ligue as duas VPS por um túnel [WireGuard](https://streethosting.com.br/guias/vps/proteger-vps-wireguard-vpn) e faça o banco escutar só no endereço da VPN. A porta do banco continua fechada para a internet e o tráfego entre os servidores viaja criptografado. ## Qual plano contratar Para a maior parte dos bancos de dados, a [VPS Xeon](https://streethosting.com.br/vps/xeon) é o ponto de partida: Xeon E5-2680 v4 com DDR4 e NVMe, de R$ 23,00 (2 vCPU, 2 GB, 20 GB) a R$ 550,00 (24 vCPU, 64 GB, 640 GB). Ela dá mais RAM e vCPU por real, exatamente os dois recursos que um banco com muitas conexões consome. Quando o gargalo é o tempo de consultas pesadas, a [VPS Ryzen 9 9950X](https://streethosting.com.br/vps/ryzen), com DDR5 e até 5,7 GHz, vai de R$ 39,00 a R$ 814,00. As duas linhas ficam em São Paulo, com AntiDDoS, acesso root e virtualização KVM. O upgrade é feito pelo painel, cobra só a diferença proporcional do ciclo e exige reiniciar a VM, então agende para um horário de pouco movimento. Depois do upgrade, ajuste os parâmetros de memória do banco, porque a maioria deles não acompanha a RAM nova sozinha. O disco cresce com o plano, mas diminuir nem sempre é possível: compre espaço para o próximo ano, não para os próximos cinco. Acima de 640 GB ou de 64 GB de RAM, os [servidores dedicados](https://streethosting.com.br/dedicated) em São Paulo trazem NVMe de 2 TB e de 64 a 192 GB de memória na linha AMD. ## Perguntas frequentes ### Quanto de RAM uma VPS para banco de dados precisa? O ideal é que caibam na memória os índices e a parte dos dados consultada com frequência, mais a memória das conexões e do sistema. Para bancos de até alguns GB, 4 a 8 GB resolvem; bancos de dezenas de GB costumam pedir 16 a 32 GB. ### Xeon ou Ryzen é melhor para banco de dados? Xeon entrega mais vCPU e mais RAM por real, o que favorece muitas conexões simultâneas e bancos que precisam de memória. Ryzen 9 9950X tem clock bem maior e reduz o tempo de consultas pesadas individuais, como relatórios e agregações. ### NVMe faz diferença para banco de dados? Faz, principalmente na gravação. Cada transação confirmada espera o disco garantir os dados, e o NVMe responde muito mais rápido que SSD SATA ou HDD. Quando os dados não cabem na RAM, as leituras também passam a depender do disco. ### É melhor deixar o banco na mesma VPS da aplicação? Para projetos pequenos e médios, sim: a latência entre aplicação e banco fica mínima e o custo cai. Separe quando os dois disputarem RAM, quando várias aplicações usarem o mesmo banco ou quando a aplicação precisar escalar em mais de um servidor. ### A VPS da StreetHosting faz backup do meu banco? Não. A VPS não inclui serviço de backup nem snapshot automático, então o backup é responsabilidade de quem administra o servidor. Agende pg_dump, mysqldump ou mongodump e envie as cópias para fora da VPS. ## Guias relacionados - [Como instalar PostgreSQL na VPS Ubuntu com segurança](https://streethosting.com.br/guias/vps/instalar-postgresql-vps-ubuntu.md) - [Como instalar MongoDB na VPS Ubuntu com autenticação](https://streethosting.com.br/guias/vps/instalar-mongodb-vps-ubuntu.md) - [Como instalar e configurar Redis na VPS Ubuntu](https://streethosting.com.br/guias/vps/configurar-redis-vps-ubuntu.md) - [VPS Ryzen vs VPS Xeon: qual CPU escolher para o servidor](https://streethosting.com.br/guias/vps/vps-ryzen-vs-vps-xeon.md) - [CPU steal na VPS: o que é, como medir e o que fazer](https://streethosting.com.br/guias/vps/o-que-e-cpu-steal-vps.md) ## Produtos citados - https://streethosting.com.br/vps/xeon - https://streethosting.com.br/vps - https://streethosting.com.br/vps/ryzen - https://streethosting.com.br/dedicated ## Dados estruturados ```json [ { "@context": "https://schema.org", "@type": [ "Article", "TechArticle" ], "headline": "VPS para banco de dados: como dimensionar sem pagar a mais", "name": "Como escolher VPS para banco de dados: RAM, CPU e NVMe", "abstract": "Banco de dados lento raramente se resolve com mais vCPU: quase sempre falta RAM para os dados mais usados ou sobra latência no disco. Veja como medir o que o seu banco consome e escolher o plano pelo número certo.", "description": "Dimensione a VPS do seu banco de dados pelo tamanho dos dados, pelas conexões e pela escrita: RAM, CPU, NVMe, IOPS, rede e planos reais lado a lado.", "datePublished": "2026-09-28", "dateModified": "2026-09-28", "author": { "@type": "Organization", "name": "Equipe StreetHosting" }, "publisher": { "@type": "Organization", "name": "StreetHosting", "url": "https://streethosting.com.br" }, "inLanguage": "pt-BR", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://streethosting.com.br/guias/vps/escolher-vps-banco-de-dados" } }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Quanto de RAM uma VPS para banco de dados precisa?", "acceptedAnswer": { "@type": "Answer", "text": "O ideal é que caibam na memória os índices e a parte dos dados consultada com frequência, mais a memória das conexões e do sistema. Para bancos de até alguns GB, 4 a 8 GB resolvem; bancos de dezenas de GB costumam pedir 16 a 32 GB." } }, { "@type": "Question", "name": "Xeon ou Ryzen é melhor para banco de dados?", "acceptedAnswer": { "@type": "Answer", "text": "Xeon entrega mais vCPU e mais RAM por real, o que favorece muitas conexões simultâneas e bancos que precisam de memória. Ryzen 9 9950X tem clock bem maior e reduz o tempo de consultas pesadas individuais, como relatórios e agregações." } }, { "@type": "Question", "name": "NVMe faz diferença para banco de dados?", "acceptedAnswer": { "@type": "Answer", "text": "Faz, principalmente na gravação. Cada transação confirmada espera o disco garantir os dados, e o NVMe responde muito mais rápido que SSD SATA ou HDD. Quando os dados não cabem na RAM, as leituras também passam a depender do disco." } }, { "@type": "Question", "name": "É melhor deixar o banco na mesma VPS da aplicação?", "acceptedAnswer": { "@type": "Answer", "text": "Para projetos pequenos e médios, sim: a latência entre aplicação e banco fica mínima e o custo cai. Separe quando os dois disputarem RAM, quando várias aplicações usarem o mesmo banco ou quando a aplicação precisar escalar em mais de um servidor." } }, { "@type": "Question", "name": "A VPS da StreetHosting faz backup do meu banco?", "acceptedAnswer": { "@type": "Answer", "text": "Não. A VPS não inclui serviço de backup nem snapshot automático, então o backup é responsabilidade de quem administra o servidor. Agende pg_dump, mysqldump ou mongodump e envie as cópias para fora da VPS." } } ] } ] ```