Como escolher VPS para SQL Server no Brasil

Resposta direta

Uma VPS para SQL Server no Brasil deve combinar Windows Server compatível, licenciamento validado, processador com bom desempenho por núcleo, memória suficiente para o buffer pool e armazenamento com latência previsível. Um ambiente pequeno costuma começar com 4 vCPUs, 8 GB de RAM e 120 GB de SSD, enquanto aplicações empresariais normalmente pedem 8 vCPUs, 16 a 32 GB de RAM e volumes separados para sistema, dados, logs e backups temporários. SQL Server Express serve para desenvolvimento e bancos pequenos, mas seus limites de tamanho, CPU e memória restringem o uso em produção. SQL Server Standard atende cenários maiores, embora o custo da licença possa superar o valor da própria infraestrutura.

A localização no Brasil reduz a distância de rede para usuários e aplicações nacionais, mas não corrige consultas sem índice, bloqueios longos ou disco saturado. Antes de contratar, confirme se as vCPUs são compartilhadas ou dedicadas, qual é o tipo de armazenamento, como funciona a licença do Windows Server e se o provedor permite levar uma licença existente do SQL Server. Essas condições variam entre contratos e não devem ser presumidas.

Também é necessário planejar a restauração antes de colocar o banco em produção. Uma cópia diária dentro da mesma VPS protege pouco contra exclusão acidental, ransomware ou falha completa da instância. A base segura é manter backups nativos do SQL Server, copiar os arquivos para armazenamento externo e testar a recuperação em outra máquina. O objetivo não é apenas gerar um arquivo .bak, mas conseguir retornar o serviço dentro do tempo aceito pelo negócio.

Resumo rápido

• Use pelo menos 4 vCPUs e 8 GB de RAM para uma aplicação pequena em produção, reservando memória para o Windows Server e agentes de monitoramento.
• SQL Server Express tem licença gratuita, mas limita recursos por instância e aceita bancos de até 10 GB, conforme a versão suportada pela Microsoft.
• SQL Server Standard amplia capacidade e recursos, porém exige validação do modelo de licenciamento por núcleo, servidor ou provedor autorizado.
• Prefira SSD ou NVMe com métricas conhecidas de IOPS, throughput e latência, não apenas uma grande quantidade de gigabytes.
• Mantenha dados, logs, tempdb e área de backup em volumes distintos quando o plano e a arquitetura permitirem.
• Restrinja RDP e a porta TCP 1433 por firewall, VPN ou lista de endereços autorizados.
• Combine backup completo, diferencial e log de transações de acordo com o RPO, sempre com uma cópia fora da VPS.

A escolha começa pela carga, não pelo nome do plano. Um ERP com 30 usuários pode exigir mais disco que uma API com milhares de requisições simples, especialmente se emitir relatórios pesados e realizar muitas gravações. Já uma aplicação de leitura intensiva pode aproveitar bastante a memória, pois páginas de dados acessadas com frequência permanecem no buffer pool e deixam de depender do armazenamento a cada consulta.

Há ainda uma diferença operacional entre uma VPS tradicional e uma instância de Cloud Server. Ambas podem executar Windows e SQL Server, mas a facilidade de redimensionamento, os modelos de cobrança e as opções de volumes anexáveis mudam conforme a plataforma. O artigo sobre VPS Linux ou VPS Windows ajuda a entender os custos e as responsabilidades administrativas antes de adotar o ecossistema Microsoft.

Nenhuma configuração deve ser tratada como definitiva. Depois da implantação, acompanhe uso de CPU, espera de disco, memória disponível, crescimento dos bancos e consultas mais caras. O dimensionamento melhora quando usa medições de uma semana normal e também de períodos de pico, como fechamento financeiro, importação de notas ou geração de relatórios mensais.

Windows Server, SQL Server e licenciamento

Escolha da edição do SQL Server

O SQL Server precisa de um sistema operacional e de uma edição compatíveis com a versão escolhida. Para uma instalação nova, confira a matriz oficial da Microsoft antes de definir Windows Server 2019, 2022 ou uma versão posterior. Compatibilidade não depende apenas de o instalador abrir. Ciclo de suporte, atualizações cumulativas, drivers de armazenamento e ferramentas de backup também entram na decisão.

SQL Server Express é adequado para desenvolvimento, demonstrações e aplicações pequenas. Na linha SQL Server 2022, cada banco tem limite de 10 GB, e a instância utiliza capacidade restrita de CPU e memória. Um sistema com três bancos de 8 GB não viola o limite por banco, mas ainda pode encontrar gargalos no buffer pool e no processamento. Exemplo prático: um software de estoque com 12 usuários e banco de 4 GB pode funcionar bem no Express; um ERP com histórico fiscal crescendo 1 GB por mês logo exigirá migração ou arquivamento.

Developer inclui os recursos da edição Enterprise para desenvolvimento e teste, mas não pode atender uma carga de produção. Standard é a escolha comum para sistemas empresariais que ultrapassaram o Express. Enterprise oferece recursos e limites mais amplos, com impacto significativo no licenciamento. A edição não deve ser escolhida apenas pelo tamanho atual do arquivo MDF. Recursos necessários, quantidade de núcleos e estratégia de disponibilidade também contam.

Licenças em infraestrutura de terceiros

O Windows Server pode estar incluído no valor da instância ou ser cobrado separadamente. Solicite ao provedor uma descrição escrita da edição, do número de vCPUs cobertas e das regras de ativação. O SQL Server pode ser oferecido pelo próprio provedor em um modelo autorizado ou instalado com licença do cliente, desde que os termos aplicáveis permitam esse uso.

Levar uma licença existente para uma VPS não é automático. Software Assurance, direitos de mobilidade, terceirização autorizada, tipo de contrato e dedicação do hardware podem alterar a resposta. Em um cenário de 8 vCPUs, por exemplo, a forma de licenciar núcleos virtuais precisa ser analisada antes da contratação. Não basta possuir uma chave de produto válida. Para evitar exposição jurídica, peça validação ao parceiro Microsoft ou ao responsável pelo contrato de licenciamento e guarde a documentação junto ao inventário da infraestrutura.

Como dimensionar CPU e memória

Perfis iniciais de recursos

SQL Server se beneficia de núcleos rápidos, mas o número total de vCPUs continua relevante para consultas paralelas, compactação, importações e tarefas de manutenção. Em uma VPS com CPU compartilhada, quatro vCPUs podem apresentar comportamento diferente ao longo do dia por causa da disputa no host. Se o sistema tem picos previsíveis ou requisitos rígidos de resposta, procure informações sobre política de uso, frequência sustentada e disponibilidade de núcleos dedicados.

A tabela apresenta pontos de partida, não garantias de capacidade. O resultado depende do modelo de dados, dos índices, do volume de consultas e da concorrência entre usuários.

Perfil	vCPU inicial	RAM	Disco útil inicial	Exemplo de carga	Observação operacional
Laboratório	2	4 a 8 GB	80 a 120 GB SSD	Desenvolvimento e testes unitários	SQL Server Developer ou Express, sem uso produtivo no caso da Developer
Produção pequena	4	8 a 16 GB	120 a 250 GB SSD ou NVMe	API, sistema interno ou ERP com até dezenas de usuários simultâneos	Monitorar CPU roubada, latência de disco e memória disponível
Produção média	8	16 a 32 GB	250 a 500 GB em volumes separados	ERP, SaaS B2B ou integrações com gravação frequente	Planejar disco para dados, logs, tempdb e retenção local curta
Carga intensiva	12 a 16	32 a 64 GB ou mais	A partir de 500 GB	Relatórios, ETL e múltiplas bases ativas	Exige teste de carga e análise de licenciamento por núcleo

Para um sistema comercial com banco de 60 GB, 40 usuários e pico de 15 sessões ativas, 4 vCPUs e 16 GB de RAM formam uma base razoável para homologação. Se o mesmo servidor também executar IIS, antivírus, agente de backup e rotinas de importação, 8 vCPUs e 24 ou 32 GB oferecem margem operacional maior. O guia sobre como escolher CPU, RAM e NVMe detalha por que cada recurso precisa ser observado separadamente.

Memória máxima do SQL Server

Não entregue toda a RAM ao mecanismo do banco. Em uma VPS de 16 GB dedicada ao SQL Server, uma configuração inicial de max server memory entre 11 e 12 GB deixa espaço para Windows Server, drivers, antivírus e tarefas auxiliares. Em 32 GB, uma faixa inicial de 24 a 26 GB costuma preservar margem mais confortável. Esses valores devem ser ajustados com monitoramento, não copiados mecanicamente.

Se a aplicação e o banco dividirem a mesma VPS, aumente a reserva. Um IIS consumindo 3 GB durante picos muda completamente a conta. Sintomas de pressão incluem paginação, lentidão generalizada, queda de cache e aumento de leituras físicas. Antes de comprar mais RAM, verifique também consultas que retornam milhões de linhas, planos ruins e índices ausentes. Recursos adicionais mascaram problemas por algum tempo, mas não substituem ajuste do banco.

Disco, IOPS e configuração dos arquivos

Separação de dados, logs e tempdb

Capacidade em gigabytes é apenas uma parte da análise. SQL Server depende de latência, IOPS e throughput, especialmente durante checkpoints, crescimento de arquivos, restaurações e gravações no log. Um volume NVMe pode reduzir espera de I/O, mas a tecnologia do dispositivo não revela sozinha a performance entregue pela camada virtual. Limites por volume, fila de disco e contenção no host precisam ser confirmados ou medidos.

Em uma implantação de porte médio, uma organização prática seria reservar 100 GB para Windows e binários, 250 GB para arquivos de dados, 100 GB para logs e tempdb, além de uma área temporária para backups antes do envio externo. Separar volumes facilita expansão, permissões e monitoramento. Ainda assim, quatro unidades lógicas podem usar o mesmo conjunto físico no provedor. Nesse caso, a separação melhora a operação, mas não garante independência de desempenho.

O volume de dados deve considerar crescimento e espaço livre. Um banco com MDF de 120 GB, log de 30 GB e aumento mensal de 8 GB não cabe com segurança em um disco de 160 GB. Há ainda índices, reconstruções, arquivos temporários e cópias locais. Uma projeção de 12 meses adicionaria 96 GB apenas ao banco. Com 25% de margem operacional, o planejamento passaria facilmente de 300 GB.

Crescimento e manutenção dos arquivos

Configure crescimento automático em megabytes, não em porcentagem. Para um banco de 100 GB, crescimento de 1 GB ou 2 GB produz eventos mais previsíveis que uma regra de 10%, que passaria a adicionar 10 GB de uma vez. O valor correto depende da taxa de ingestão e do desempenho do volume. Crescimentos muito pequenos fragmentam o arquivo e geram eventos frequentes; incrementos enormes podem segurar operações por tempo demais.

Formate volumes dedicados conforme as recomendações atuais da Microsoft e valide o tamanho de unidade de alocação, frequentemente configurado em 64 KB para cargas do SQL Server. Para tempdb, uma referência inicial é criar arquivos de dados de mesmo tamanho e crescimento, aumentando gradualmente a quantidade quando houver contenção. Não crie dezenas de arquivos sem evidência. Em uma VPS de 8 vCPUs, começar com quatro arquivos iguais e observar esperas pode ser mais sensato que assumir oito como regra fixa.

Acompanhe PAGEIOLATCH, WRITELOG, latência por arquivo e tamanho da fila. Se WRITELOG permanece alto durante transações curtas, investigue o volume de log, o padrão de commits e a latência de gravação. Se relatórios causam muitas leituras físicas, índices e memória podem ser mais relevantes que simplesmente trocar SSD por NVMe.

Rede, latência e segurança no Brasil

Quando a localização nacional ajuda

Uma instância no Brasil costuma reduzir o tempo de ida e volta para aplicações e usuários que também estão no país. Isso aparece com mais clareza quando uma aplicação realiza muitas chamadas pequenas e sequenciais ao banco. Se uma página executa 40 consultas em série, cada milissegundo adicional pode se acumular. A correção ideal continua sendo reduzir viagens desnecessárias, usar consultas agrupadas e manter aplicação e banco próximos.

Considere uma API hospedada em São Paulo acessando um SQL Server na América do Norte. Mesmo com uma rota estável, a distância pode acrescentar dezenas ou mais de uma centena de milissegundos por operação, dependendo da região e do provedor. Colocar ambos na mesma região brasileira tende a reduzir esse custo. Já um processamento noturno que envia um arquivo e executa uma única operação longa é menos sensível à latência do usuário.

Datacenter nacional também pode ajudar em requisitos contratuais de residência e governança, mas localização física não produz conformidade automática com a LGPD. A empresa continua responsável por controle de acesso, finalidade, retenção, descarte e resposta a incidentes. Confirme em contrato onde ficam a VPS, os backups e eventuais réplicas do provedor.

Portas, acesso administrativo e criptografia

A porta TCP 1433 não deve ficar aberta para toda a internet. Permita apenas IPs de aplicações conhecidas, uma rede privada, túnel VPN ou bastion host. Faça o mesmo com RDP na porta 3389. Um exemplo seguro é liberar RDP somente pelo IP corporativo e exigir autenticação multifator no gateway ou na camada de acesso. Se o endereço da equipe muda com frequência, uma VPN é mais administrável que sucessivas regras públicas.

Use contas de serviço separadas, senhas exclusivas e privilégios mínimos. Administradores do Windows não precisam compartilhar a conta sa, e a aplicação não deve conectar como sysadmin. Crie um login próprio, mapeie apenas o banco necessário e conceda permissões para as operações reais. Desabilitar ou renomear contas conhecidas ajuda pouco se as permissões continuarem excessivas.

Ative criptografia TLS nas conexões e valide certificados, principalmente quando aplicação e banco não compartilham rede privada. Mantenha Windows Server, SQL Server e ferramentas de gestão atualizados em uma janela controlada. Antivírus também precisa de configuração consciente, com exclusões específicas recomendadas pela Microsoft, em vez de excluir discos inteiros e reduzir a proteção do servidor.

Backup, restauração e disponibilidade

Estratégia baseada em RPO e RTO

Backup deve partir de duas perguntas. Quanto dado a empresa aceita perder e quanto tempo o serviço pode ficar indisponível? O primeiro número define o objetivo de ponto de recuperação, conhecido como RPO. O segundo orienta o objetivo de tempo de recuperação, o RTO. Sem esses limites, a equipe pode gerar muitos arquivos e ainda descobrir, durante um incidente, que a restauração demora mais que o negócio tolera.

Para um sistema interno que aceita perder até 24 horas, um backup completo diário pode atender, desde que seja copiado para fora da VPS e testado. Um ERP que aceita perder no máximo 15 minutos pede modelo de recuperação Full, backups de log a cada 5 ou 15 minutos e uma cadeia íntegra. Uma carga de 300 GB com RTO de uma hora talvez exija armazenamento rápido, compressão, restauração paralela planejada ou uma réplica pronta. Não há política única para todos os bancos.

Uma rotina comum combina backup completo semanal, diferencial diário e log de transações a cada 15 minutos. Outra opção é fazer completo diário e logs frequentes, se a janela e o armazenamento permitirem. A retenção pode manter sete cópias diárias, quatro semanais e seis mensais, ajustada às obrigações da empresa. O conteúdo sobre VPS com backup automático explica quais perguntas fazer ao provedor, mas o backup nativo do SQL Server continua necessário.

Snapshots não substituem backups do banco

Snapshots capturam o estado de um volume ou instância. Sem integração consistente com a aplicação, podem registrar arquivos de dados e log em momentos diferentes. Um snapshot crash-consistent pode ser útil na recuperação da máquina, mas não substitui um .bak validado nem garante recuperação ponto a ponto. Confirme se o mecanismo usa VSS ou integração compatível e documente como a restauração será realizada.

A regra 3-2-1 continua prática: três cópias, em dois tipos ou destinos de armazenamento, com uma fora do ambiente principal. Por exemplo, mantenha o banco ativo na VPS, uma retenção curta em volume separado e uma cópia criptografada em armazenamento de objetos de outra conta. Proteja o repositório com credenciais exclusivas, retenção imutável quando disponível e permissão que impeça o servidor de apagar todo o histórico.

Teste restaurações mensalmente em uma instância isolada. Registre duração, erros, consistência com DBCC CHECKDB e horário do último log recuperado. Um arquivo existente não prova que ele abre. Também monitore falhas dos jobs, falta de espaço e tempo de upload. Para um banco de 200 GB, medir restauração é tão relevante quanto medir backup, pois download, descompressão e recuperação podem dominar o RTO.

Recomendações por perfil

Desenvolvedor individual e laboratório

Para desenvolvimento local remoto, provas de conceito e treinamento, comece com 2 vCPUs, 4 a 8 GB de RAM e 80 a 120 GB de SSD. SQL Server Developer oferece recursos amplos para desenvolvimento e teste, mas não pode receber tráfego produtivo. SQL Server Express é outra opção quando o objetivo é reproduzir as limitações de uma aplicação pequena. Instale Windows Server compatível, limite o acesso RDP ao seu IP e desligue a instância quando a plataforma permitir cobrança por uso.

Separe ao menos o disco do sistema dos arquivos do projeto quando snapshots e recriação frequente fizerem parte do fluxo. Gere backups antes de alterações de esquema, mesmo que os dados não sejam críticos. Um laboratório com 4 GB pode sofrer paginação durante instalação, atualização ou importação; 8 GB evita boa parte desse atrito e permite manter SQL Server Management Studio aberto na própria VPS, embora administrar de uma estação remota costume consumir menos recursos do servidor.

Equipe pequena ou sistema interno

Uma equipe com sistema de atendimento, estoque ou financeiro pode iniciar a homologação com 4 vCPUs, 16 GB de RAM e 200 a 300 GB de SSD ou NVMe. Reserve de 4 a 5 GB para Windows, antivírus e agentes, deixando cerca de 11 ou 12 GB como limite inicial do SQL Server. Se IIS e banco dividirem a máquina, considere 24 GB ou separe as funções em duas instâncias.

Use SQL Server Express apenas depois de projetar o crescimento. Um banco com 7 GB e aumento de 500 MB por mês atingirá o limite de 10 GB em aproximadamente seis meses, sem contar limpeza ou arquivamento. Nesse caso, SQL Server Standard ou uma revisão da arquitetura deve entrar no orçamento desde o início. Configure backup completo diário, logs quando o modelo de recuperação exigir e cópia externa. Revise a licença com o provedor antes de ativar produção.

Produção empresarial

Para ERP, SaaS B2B ou integrações com dezenas de sessões simultâneas, um ponto inicial comum é 8 vCPUs, 32 GB de RAM e volumes separados, com 100 GB para o sistema, 300 GB ou mais para dados e capacidade própria para logs e tempdb. Execute teste de carga com uma cópia anonimizada da base. Meça duração das consultas, CPU, WRITELOG, leituras físicas, bloqueios e crescimento durante rotinas de fechamento.

Defina max server memory, configure alertas de espaço e acompanhe jobs do SQL Server Agent. Backups de log a cada 5 ou 15 minutos atendem RPOs mais curtos, mas só funcionam se a cadeia for monitorada. Restrinja RDP e SQL por VPN ou rede privada. Antes do lançamento, simule a perda total da VPS e restaure o banco em outra instância. Esse exercício revela dependências esquecidas, como logins, certificados, credenciais, linked servers e tarefas agendadas.

Operação crítica e alta disponibilidade

Sistemas com impacto financeiro elevado não devem depender apenas de uma VPS robusta. Nessa faixa, avalie duas instâncias em domínios de falha distintos, estratégia compatível com SQL Server Always On, monitoramento externo e um destino adicional de recuperação. A edição do SQL Server, o modo de cluster, o quorum e as licenças precisam ser avaliados em conjunto. Uma réplica não elimina exclusões acidentais, pois alterações incorretas também podem ser replicadas.

Comece a capacidade com base em benchmark da aplicação, não em uma tabela genérica. Uma referência de teste pode usar 16 vCPUs, 64 GB de RAM e volumes de baixa latência, mas a aprovação depende de métricas no pico. Registre RPO e RTO em contrato interno, teste failover e restauração e mantenha cópias imutáveis. Confirme ainda se o provedor oferece rede privada, proteção contra ataques, console de emergência e opções de recuperação sem presumir que esses recursos estejam incluídos no plano.