Armazenamento on-premises em 2026: como escolher a solução certa sem desperdiçar capital

Este artigo compara as principais arquiteturas de armazenamento on-premises disponíveis em 2026 — SAN, NAS, object storage e HCI — com foco no que realmente importa para quem toma decisões: TCO, performance por workload, compliance e integração com ambientes híbridos. Você vai sair daqui com critérios claros para justificar uma escolha perante o conselho.

Resumo

• Não existe solução universal: a escolha entre SAN, NAS, object storage e HCI depende do workload predominante, do perfil de crescimento de dados e do TCO projetado para cinco anos.
• O mercado global de armazenamento on-premises deve atingir USD 82 bilhões em 2026, segundo o IDC, impulsionado por requisitos de soberania de dados, latência e regulação setorial.
• Os erros mais custosos na compra de storage corporativo não são técnicos: são estratégicos, e envolvem subestimar o custo de expansão, ignorar a complexidade operacional e confundir performance em pico com performance sustentada.

Introdução

Durante anos, a narrativa dominante no setor foi de que a nuvem pública tornaria o armazenamento on-premises obsoleto. Não aconteceu. O que ocorreu foi uma reconfiguração: as empresas que migraram tudo para a nuvem começaram a calcular o custo real de egress, latência e conformidade regulatória, e muitas voltaram atrás.

No Brasil, o movimento é ainda mais evidente. A Lei Geral de Proteção de Dados (LGPD), as exigências do Banco Central para instituições financeiras e os requisitos da ANVISA para dados de saúde criaram um cenário em que manter determinadas cargas de trabalho on-premises não é uma escolha conservadora, é uma obrigação contratual ou regulatória.

O problema é que "manter on-premises" não é uma decisão singular. É uma série de escolhas de arquitetura com implicações profundas de custo, performance e risco. Um CIO que decide comprar uma SAN all-flash de ponta para armazenar backups frios está desperdiçando capital da mesma forma que outro que coloca dados de produção de banco de dados crítico em um NAS de entrada. As consequências chegam sempre, só mudam o prazo.

Este artigo organiza o que você precisa saber para fazer essa escolha com clareza, independentemente do tamanho da sua operação.

O estado do mercado em 2026

O IDC projeta que o mercado global de infraestrutura de armazenamento empresarial vai movimentar USD 82 bilhões em 2026. Desse total, a parcela de sistemas on-premises ainda representa mais de 55% do gasto corporativo em storage. A nuvem cresceu, mas não substituiu.

Os vetores que sustentam essa demanda são bem definidos. O volume de dados gerados por aplicações de IA e machine learning cresceu a uma taxa de 42% ao ano entre 2022 e 2025, segundo a Gartner. Boa parte desse dado precisa residir localmente para que o modelo seja treinado com latência aceitável. Além disso, o custo de transferência de dados em hiperescaladores como AWS, Azure e Google Cloud continua sendo um item frequentemente subestimado no planejamento de migração.

No Brasil especificamente, a combinação de soberania de dados e custo do dólar torna a repatriação de workloads uma conversa recorrente nas salas de TI. Empresas de médio porte que contrataram storage em nuvem pública entre 2019 e 2021 estão revisando esses contratos agora. O câmbio mudou a conta.

As quatro arquiteturas e o que cada uma entrega de verdade

Cada arquitetura de armazenamento resolve um conjunto específico de problemas. Confundir os casos de uso é o erro mais comum e mais caro nessa categoria.

SAN: quando performance é inegociável

A Storage Area Network é a escolha padrão para workloads que exigem latência ultrabaixa e alta taxa de operações por segundo. Bancos de dados transacionais como Oracle, SQL Server e SAP HANA são os casos de uso mais representativos. Uma SAN all-flash moderna de fabricantes como Pure Storage, Dell EMC PowerStore ou NetApp AFF entrega latência abaixo de 0,5 ms e IOPS na casa de centenas de milhares por array.

O custo é o ponto de atenção. Uma solução SAN all-flash de entrada para ambientes corporativos parte de aproximadamente USD 80.000 e pode ultrapassar USD 500.000 em configurações de alta capacidade com redundância total. O modelo de licenciamento de alguns fabricantes também adiciona complexidade: funcionalidades como replicação, snapshots e deduplicação frequentemente são pagas à parte.

Para o CIO, a pergunta certa não é "a SAN é cara demais". A pergunta é: qual é o custo de uma hora de indisponibilidade do meu banco de dados de faturamento? Se a resposta for superior a USD 10.000, o custo da SAN se justifica rapidamente.

NAS: o cavalo de trabalho para dados não estruturados

O Network Attached Storage continua sendo a arquitetura mais versátil para o dia a dia corporativo. Compartilhamentos de arquivos, repositórios de mídia, dados de colaboração, backups primários e ambientes de desenvolvimento são os casos de uso dominantes. Fabricantes como NetApp ONTAP, Synology no segmento de médio porte e QNAP dominam essa categoria com soluções que variam de USD 5.000 a centenas de milhares de dólares.

A principal vantagem do NAS é a simplicidade operacional. A equipe de TI consegue provisionar, expandir e gerenciar o armazenamento sem conhecimento especializado em Fibre Channel ou iSCSI. O protocolo SMB/CIFS e o NFS são universalmente compreendidos. Isso reduz o custo de operação ao longo do tempo, um componente do TCO frequentemente ignorado na fase de compra.

O limite do NAS aparece quando o workload exige IOPS intenso e consistente. Colocar uma aplicação de banco de dados de alta transação em um NAS, mesmo de alto desempenho, vai resultar em degradação de performance em momentos de pico. Isso não é uma falha do produto, é uma incompatibilidade de arquitetura.

Object storage: a arquitetura para escala massiva

O object storage on-premises é a solução para quem precisa armazenar volumes imensos de dados não estruturados com acesso via API, principalmente em formato compatível com S3. Logs de auditoria, dados de telemetria, arquivos de treinamento de modelos de IA, imagens médicas e conteúdo de mídia são os casos de uso mais frequentes.

Soluções como MinIO, Ceph e Dell EMC ECS permitem construir infraestruturas que escalam a petabytes sem a complexidade de uma SAN tradicional. O custo por terabyte do object storage on-premises tende a ser significativamente mais baixo que o das outras arquiteturas, frequentemente abaixo de USD 50 por TB em escala, considerando hardware e licenciamento.

A desvantagem é que o object storage não foi projetado para acesso aleatório de baixa latência. Aplicações que precisam ler e escrever arquivos com frequência e imprevisibilidade não se beneficiam dessa arquitetura. Ela foi criada para leitura sequencial em alta escala, não para substituir um sistema de arquivos tradicional.

HCI: quando a simplicidade operacional vale mais que a performance máxima

A Infraestrutura Hiperconvergente combina computação, armazenamento e rede em um único stack gerenciado por software. Fabricantes como Nutanix, VMware vSAN e StarWind HCA popularizaram o modelo. A proposta é clara: menos complexidade operacional, expansão modular e um painel único de gerenciamento.

Para ambientes de virtualização de médio porte, o HCI entrega uma relação custo-benefício difícil de bater. Uma instalação inicial de três nós com Nutanix ou vSAN consegue suportar centenas de máquinas virtuais com alta disponibilidade integrada, por um investimento entre USD 100.000 e USD 300.000.

O ponto de atenção está no modelo de escala. No HCI, você escala computação e armazenamento juntos. Se a sua necessidade de crescimento for assimétrica, ou seja, se você precisar de mais armazenamento sem mais CPU, o modelo se torna ineficiente. Empresas que não mapeiam o perfil de crescimento antes de escolher o HCI acabam comprando capacidade de processamento que não precisam só para adicionar disco.

Matriz de decisão: como escolher sem errar

A escolha entre as arquiteturas deve ser conduzida por quatro variáveis principais. Ignore qualquer uma delas e a decisão vai ser revisada em 18 meses.

• Perfil de workload: bancos de dados transacionais pedem SAN; colaboração e arquivos corporativos pedem NAS; dados em escala massiva com acesso via API pedem object storage; virtualização consolidada pede HCI.
• TCO em cinco anos: inclua licenciamento, expansão de capacidade, custo de operação da equipe, suporte do fabricante e custo de energia. A solução mais barata na compra raramente é a mais barata no ciclo completo.
• Requisitos de compliance: dados sujeitos à LGPD, regulação do Banco Central ou normas setoriais precisam de controles específicos de acesso, auditoria e residência. Nem todo fabricante entrega isso sem licenças adicionais.
• Estratégia híbrida: a solução on-premises precisa se integrar com a nuvem de forma nativa? Replicação, tiering automático e failover para AWS ou Azure são funcionalidades que alguns fabricantes oferecem de forma madura e outros apenas prometem no roadmap.

Os erros que custam mais caro

Depois de acompanhar dezenas de projetos de storage corporativo, os padrões de erro se repetem com regularidade preocupante.

O primeiro é comprar pela performance de pico, não pela performance sustentada. Todo fabricante mostra o número de IOPS em condição ideal no pitch de venda. O que importa é o desempenho com o array a 70% de capacidade, com deduplicação ativa e com múltiplos workloads simultâneos. Exija esse benchmark antes de assinar o contrato.

O segundo erro é subestimar o custo de expansão. Muitos arrays têm um preço de entrada atraente, mas cobram uma proporção desproporcional na expansão de capacidade. O custo por terabyte adicional pode ser duas ou três vezes o custo inicial. Simule o crescimento projetado para cinco anos antes de fechar o negócio.

O terceiro é ignorar a complexidade operacional. Uma SAN Fibre Channel de alto desempenho requer profissionais com certificação específica para operação e troubleshooting. Se a sua equipe não tem esse perfil e o orçamento para contratação é restrito, o custo real da solução vai aparecer na primeira falha de produção.

O quarto erro, e talvez o mais estratégico, é não mapear a integração com o plano de disaster recovery. Armazenamento on-premises sem uma estratégia clara de replicação e failover é uma concentração de risco. A pergunta não é "quanto custa proteger esse storage". A pergunta é "quanto custa perder esses dados".

Tendências que vão mudar as decisões em 2026

Três movimentos merecem atenção especial para quem está planejando investimentos agora.

O primeiro é o storage orientado a IA. Fabricantes como Pure Storage e NetApp já embarcam funcionalidades de análise preditiva nos próprios arrays, com capacidade de identificar anomalias de performance, prever falhas de disco e otimizar o layout de dados automaticamente. Isso reduz o trabalho operacional e muda o perfil da equipe necessária para gerenciar o ambiente.

O segundo é o edge storage. Com a proliferação de aplicações industriais, varejo e logística que processam dados na borda da rede, cresce a demanda por soluções de armazenamento compactas, robustas e gerenciáveis remotamente. Esse é um segmento ainda em formação, mas que vai exigir decisões de arquitetura nos próximos 24 meses para empresas com operações distribuídas.

O terceiro é a pressão por sustentabilidade. Regulações europeias e compromissos ESG estão forçando fabricantes a publicar métricas de consumo energético por terabyte. Soluções all-flash consomem significativamente menos energia por TB que arrays híbridos ou sistemas baseados em disco giratório. Para empresas com metas de redução de carbono, essa métrica começa a entrar no critério de decisão ao lado do custo por GB.

Conclusão

O armazenamento on-premises não é uma categoria em declínio. É uma categoria que amadureceu e se fragmentou. Cada arquitetura tem um lugar bem definido no portfólio de infraestrutura corporativa, e a competência do CIO está em mapear os workloads com precisão antes de qualquer decisão de compra.

A combinação mais comum em grandes empresas brasileiras em 2026 é um array SAN all-flash para dados de produção críticos, um NAS escalável para colaboração e arquivos, e uma camada de object storage para retenção de longo prazo e dados de IA. O HCI ocupa o espaço de ambientes de virtualização consolidados, especialmente em filiais ou operações regionais onde a simplicidade operacional vale mais que a performance máxima.

A decisão certa é aquela que você consegue defender com números claros de TCO, performance e risco. Tudo o mais é preferência de fabricante.

Perguntas frequentes

Qual é a diferença prática entre SAN e NAS para um ambiente corporativo?

A SAN oferece armazenamento em bloco com latência ultrabaixa, ideal para bancos de dados transacionais que precisam de acesso direto e intenso ao disco. O NAS oferece armazenamento baseado em arquivos, acessível por protocolo de rede como SMB ou NFS, e é mais adequado para compartilhamento de documentos, backups e dados de colaboração. Usar NAS para cargas de banco de dados crítico compromete a performance. Usar SAN para arquivos corporativos é desperdício de capital.

O HCI substitui uma SAN tradicional?

Em parte. O HCI consolida computação e armazenamento em um stack unificado e gerenciável, o que reduz a complexidade operacional em ambientes de virtualização. No entanto, para workloads que exigem o máximo de IOPS e latência abaixo de 0,3 ms, como bancos de dados de missão crítica de alto volume, a SAN dedicada ainda entrega performance superior. O HCI é a escolha certa quando a simplicidade de gestão e a expansão modular pesam mais que o desempenho absoluto.

Como o armazenamento on-premises se integra com uma estratégia de nuvem híbrida?

Os principais fabricantes de storage corporativo oferecem integrações nativas com os grandes hiperescaladores. O NetApp Cloud Volumes ONTAP, por exemplo, permite replicar dados entre o ambiente on-premises e a AWS ou Azure com consistência de snapshot e failover automatizado. O Pure Storage oferece o modelo Evergreen//One com tiering para nuvem integrado. A chave é definir a política de dados antes de escolher o produto: quais dados precisam estar sempre on-premises por razões regulatórias, quais podem ser movidos para nuvem fria, e qual é o RTO aceitável em caso de desastre.

Quais são os principais critérios de compliance que afetam a escolha do storage no Brasil?

A LGPD exige controles de acesso auditáveis, capacidade de exclusão de dados pessoais sob demanda e rastreabilidade de quem acessou o quê e quando. Para instituições financeiras, a Resolução CMN 4.893 e as diretrizes de segurança cibernética do Banco Central adicionam requisitos de resiliência, segregação de dados e planos de continuidade documentados. Para o setor de saúde, a CFM e a ANVISA exigem retenção mínima de dados clínicos por períodos específicos com garantia de integridade. Qualquer solução de armazenamento on-premises que não suporte logs de auditoria granulares e controles de acesso baseados em função cria um passivo regulatório real.

DBaaS no Brasil: o que os grandes fornecedores não explicam antes de você assinar o contrato

Este artigo examina o modelo de Database as a Service (DBaaS) sob a perspectiva de quem toma a decisão de adoção e não de quem vende a solução. Você vai encontrar aqui uma análise comparativa entre os principais provedores, os custos reais que os calculadores online omitem, os riscos de compliance que afetam diretamente operações no Brasil e os critérios objetivos para decidir se o DBaaS faz sentido para o seu perfil de negócio.

Resumo

• O custo total de adoção do DBaaS vai muito além da assinatura mensal, inclui egress de dados, licenciamento oculto e o custo de reversão em caso de troca de provedor.
• A Lei Geral de Proteção de Dados (LGPD) e as normas do Banco Central impõem restrições específicas à residência de dados que alteram significativamente a equação de custo-benefício para empresas dos setores financeiro e de saúde.
• A decisão entre DBaaS gerenciado, banco de dados autogerenciado na nuvem e infraestrutura on-premises não é binária — o modelo híbrido é a realidade operacional da maioria das grandes empresas brasileiras.

 

Introdução

O mercado brasileiro de serviços de banco de dados em nuvem cresceu 34% entre 2022 e 2024, segundo o relatório anual da IDC Brasil. Esse número, isolado, conta muito pouco. O que ele não revela é que uma parcela relevante das empresas que migraram para o modelo de DBaaS nesse período reportou custos operacionais acima do projetado nos primeiros 18 meses de contrato.

O problema raramente está na tecnologia. Está na ausência de um processo de avaliação estruturado antes da assinatura. Fornecedores como AWS, Microsoft Azure e Google Cloud oferecem calculadoras de preço sofisticadas  mas todas partem de premissas que favorecem o cenário de uso ideal, não o cenário real de uma empresa com picos de demanda, requisitos de conformidade e dependências legadas.

Este artigo foi escrito para preencher esse intervalo entre o discurso comercial e a realidade operacional. A análise cobre desde a arquitetura técnica do modelo até os critérios que um CIO deveria usar para estruturar um Request for Proposal (RFP) competitivo nessa categoria.

O que o DBaaS realmente entrega e o que não entrega

O modelo de Database as a Service transfere para o provedor a responsabilidade pela infraestrutura subjacente do banco de dados: provisionamento de servidores, aplicação de patches, backups automatizados, alta disponibilidade e, em graus variáveis, monitoramento de performance. O que ele não transfere é a responsabilidade pelo design do schema, pela qualidade das queries, pela estratégia de indexação e pela governança dos dados.

Essa distinção é mais importante do que parece. Equipes que adotam o DBaaS esperando reduzir o tamanho do time de banco de dados frequentemente descobrem que os DBAs (Database Administrators) continuam sendo necessários,  apenas com um escopo de atuação diferente, mais voltado para performance e arquitetura do que para operações rotineiras.

Um levantamento da Gartner publicado em 2023 apontou que 62% das organizações que adotaram serviços de banco de dados gerenciado mantiveram ao menos um DBA dedicado na equipe interna. A narrativa de que o DBaaS elimina a necessidade de especialistas em banco de dados é, na prática, uma simplificação que leva a decisões de contratação equivocadas.

Comparativo entre os principais provedores no contexto brasileiro

A escolha do provedor de DBaaS no Brasil tem uma variável que os benchmarks internacionais frequentemente ignoram: a presença de regiões de disponibilidade locais e o impacto disso na latência e no compliance. Os três grandes provedores globais têm posicionamentos distintos nesse aspecto.

AWS RDS e Aurora no Brasil

A Amazon Web Services opera a região sa-east-1 em São Paulo desde 2011, o que a torna a provedora com o maior histórico de operação local. O Amazon RDS suporta os principais engines de banco de dados, como MySQL, PostgreSQL, Oracle, SQL Server e MariaDB e o Amazon Aurora oferece um engine proprietário compatível com MySQL e PostgreSQL com performance significativamente superior em cargas de leitura intensiva.

O ponto de atenção com a AWS no Brasil é o custo de transferência de dados para fora da região. O egress pricing na região de São Paulo é historicamente mais alto do que nas regiões norte-americanas — chegando a US$ 0,25 por GB em alguns cenários de saída para a internet, contra US$ 0,09 por GB na região us-east-1. Para empresas com arquiteturas que movimentam grandes volumes de dados entre serviços e a internet, essa diferença tem impacto real no custo mensal.

Azure SQL e Cosmos DB

A Microsoft possui duas regiões no Brasil (Brazil South e Brazil Southeast) o que oferece uma opção de redundância geográfica inteiramente dentro do território nacional. Para empresas sujeitas às normas do Banco Central do Brasil (BCB) ou à Resolução CMN 4.893, que regulamenta a contratação de serviços de processamento e armazenamento de dados por instituições financeiras, a existência dessas duas regiões locais é um diferencial competitivo relevante.

O Azure SQL Managed Instance é a oferta mais próxima da paridade com um SQL Server on-premises, o que reduz o esforço de migração para empresas com grandes investimentos no ecossistema Microsoft. A desvantagem é o custo, pois o Managed Instance é consistentemente mais caro do que o Azure SQL Database padrão, e a comparação com AWS RDS for SQL Server frequentemente favorece a AWS para workloads menores.

Google Cloud SQL e AlloyDB

O Google Cloud opera a região southamerica-east1 em São Paulo e tem avançado no mercado brasileiro com agressividade de pricing nos últimos dois anos. O Cloud SQL cobre os engines tradicionais, enquanto o AlloyDB é a resposta do Google ao Aurora, com foco em performance para PostgreSQL.

O diferencial do Google nessa categoria é a integração nativa com as capacidades de BigQuery e com os serviços de inteligência artificial da plataforma. Para empresas que têm o uso de dados analíticos e modelos de machine learning como parte central da estratégia, essa integração reduz a complexidade arquitetural e o custo de movimentação de dados entre sistemas transacionais e analíticos.

O custo real do DBaaS: o que as calculadoras não mostram

Toda calculadora de custo de nuvem parte de parâmetros que o cliente define. O problema é que a maioria dos times técnicos subestima os parâmetros de uso real durante o processo de avaliação. Há pelo menos quatro categorias de custo que costumam aparecer nas faturas sem terem sido adequadamente contempladas no orçamento inicial.

Custo de I/O em bancos de dados provisionados

No modelo Amazon Aurora e em parte das configurações do Cloud SQL, o custo de operações de leitura e escrita é cobrado separadamente da instância. Em workloads com alto volume de transações, como os de e-commerce em períodos de pico ou sistemas de fintech com processamento em tempo real, o custo de I/O pode representar 30% a 50% da fatura total do serviço de banco de dados.

A migração para o modelo Aurora I/O Optimized, lançado pela AWS em 2023, elimina a cobrança por operação de I/O em troca de uma instância com custo fixo maior. Para workloads com alto volume de operações, esse modelo tende a ser mais previsível e, em muitos casos, mais barato. A decisão exige análise dos padrões reais de uso, não de estimativas.

Custos de backup e retenção

Os provedores oferecem um volume de armazenamento de backup gratuito equivalente ao tamanho do banco de dados. Acima disso, a cobrança começa. Para bancos de dados com políticas de retenção de 30 dias ou mais comum em empresas que precisam atender a requisitos de auditoria , o custo de armazenamento de backup pode ser substancial.

Custo de suporte técnico

Os planos de suporte dos grandes provedores têm preços que variam de US$ 100 a mais de US$ 15.000 por mês, dependendo do nível de SLA e do tempo de resposta garantido. Empresas que migram de um ambiente on-premises, onde o suporte está incorporado nos salários da equipe interna frequentemente subestimam esse componente no comparativo de custo total de propriedade (TCO).

Custo de reversão

A saída de um provedor de DBaaS tem custo real. Além do egress de dados, há o custo de reengenharia das aplicações que dependem de features proprietárias do provedor, como tipos de dados específicos, funções nativas ou integrações com outros serviços da mesma plataforma. Esse custo de reversão é o principal mecanismo de lock-in no modelo de banco de dados em nuvem.

Compliance, LGPD e as especificidades do mercado brasileiro

A Lei Geral de Proteção de Dados (LGPD) não proíbe o armazenamento de dados de cidadãos brasileiros fora do Brasil, mas impõe obrigações ao controlador dos dados que precisam ser contratualmente asseguradas com o provedor. A transferência internacional de dados pessoais exige que o país de destino ofereça grau de proteção adequado ou que o controlador adote salvaguardas específicas, como cláusulas contratuais padrão.

Para a maioria das empresas fora do setor financeiro regulado, a adoção de um provedor global de DBaaS com região local no Brasil resolve a questão da residência dos dados operacionais. O risco está nos dados que saem dessa região para serviços de monitoramento, logs centralizados, pipelines de análise ou ferramentas de suporte, que precisam ser mapeados e cobertos por acordos contratuais adequados.

Para instituições financeiras, a Resolução CMN 4.893 e a Circular BCB 3.909 estabelecem requisitos adicionais de governança, auditabilidade e continuidade de negócios que vão além do que os contratos padrão dos provedores de nuvem oferecem. A adoção de DBaaS por bancos, corretoras e fintechs reguladas exige um processo de due diligence contratual que raramente está contemplado nas estimativas de prazo de implementação.

Quando o DBaaS não é a decisão certa

Parte do valor de uma análise honesta sobre DBaaS está em identificar os cenários em que o modelo não oferece vantagem real. Há pelo menos três perfis de operação em que o banco de dados gerenciado na nuvem apresenta desvantagens estruturais.

Workloads com latência ultrabaixa

Aplicações que exigem latência consistentemente abaixo de 1 milissegundo no acesso ao banco de dados, como sistemas de trading de alta frequência, processamento de transações em ponto de venda com requisitos de tempo real ou algumas aplicações industriais,  frequentemente encontram no DBaaS um gargalo de latência que não existe em uma infraestrutura física co-localizada com a aplicação.

  

Bases legadas com dependências de engine proprietário

Empresas com grandes investimentos em Oracle Database, especialmente aquelas que utilizam features avançadas como Oracle RAC, Advanced Security ou pacotes APEX — enfrentam uma equação de migração para DBaaS que raramente é simples. O Amazon RDS for Oracle e o Oracle Database@Azure oferecem caminhos de migração, mas com restrições de features e custos de licenciamento que frequentemente tornam o modelo on-premises mais atrativo no curto prazo.

Volumes de dados que tornam o egress proibitivo

Para operações de análise que exigem movimentação frequente de grandes volumes de dados — na ordem de múltiplos terabytes por mês —, o custo de transferência de dados pode tornar o DBaaS mais caro do que alternativas on-premises ou co-location. Esse cenário é mais comum em empresas de mídia, plataformas de streaming e operações de ciência de dados com pipelines de processamento em lote.

O modelo híbrido como realidade operacional

A dicotomia entre "nuvem" e "on-premises" perdeu a utilidade prática como framework de decisão. A maioria das grandes empresas brasileiras opera em um modelo híbrido — não por falta de visão estratégica, mas porque diferentes workloads têm perfis de custo, performance e compliance distintos que apontam para plataformas distintas.

O papel do DBaaS nesse contexto não é substituir toda a infraestrutura de dados, mas absorver os workloads para os quais o modelo gerenciado oferece vantagem real: novos projetos sem dependências legadas, aplicações com demanda variável, bases de desenvolvimento e homologação, e workloads analíticos que se beneficiam da integração com serviços de big data e machine learning do provedor.

A governança desse ambiente híbrido exige ferramentas de observabilidade e gerenciamento de custo que operem de forma unificada sobre os dois ambientes. Produtos como Datadog, New Relic e as ofertas nativas dos próprios provedores — como o AWS Cost Explorer e o Azure Cost Management — são componentes da arquitetura de operação, não opcionais.

Critérios objetivos para estruturar a decisão de adoção

Uma avaliação de DBaaS que resulte em uma decisão defensável para um conselho de administração precisa cobrir pelo menos cinco dimensões com dados concretos: custo total de propriedade em um horizonte de três anos, adequação ao perfil de latência da aplicação, aderência aos requisitos de compliance do setor, risco de lock-in tecnológico e capacidade do time interno de operar o modelo.

O TCO de três anos precisa incluir não apenas os custos diretos de infraestrutura, mas o custo de migração, o custo de treinamento da equipe, o custo de adaptação das aplicações e o custo de reversão hipotético. A comparação honesta com o modelo on-premises precisa incluir os custos de depreciação de hardware, licenciamento, espaço físico, energia e o custo de oportunidade do time de infraestrutura dedicado à manutenção rotineira.

O RFP para DBaaS deve exigir dos fornecedores clareza sobre: SLA de disponibilidade com créditos contratuais em caso de falha, prazo e processo de exportação de dados em caso de encerramento do contrato, localização física dos dados em repouso e em trânsito, mecanismos de auditoria de acesso compatíveis com os requisitos da LGPD e suporte a configurações de criptografia gerenciada pelo cliente (BYOK — Bring Your Own Key).

Conclusão

O DBaaS é um modelo maduro, com benefícios reais e documentados para uma parcela significativa dos workloads de dados das empresas brasileiras. A questão não é se o modelo funciona — é se ele funciona para o seu perfil específico de operação, compliance e custo.

A decisão de adoção que se sustenta no tempo é a que foi construída sobre dados reais de uso, análise contratual rigorosa e uma visão honesta dos custos que os modelos comerciais dos fornecedores não têm interesse em destacar. Para um CIO ou CTO, o valor de um processo de avaliação bem estruturado não está apenas na escolha correta do provedor — está em chegar à negociação com informação suficiente para extrair condições contratuais que o ciclo de vendas padrão raramente oferece espontaneamente.

O mercado brasileiro tem particularidades regulatórias e de infraestrutura que tornam a replicação direta de benchmarks e recomendações do mercado norte-americano um exercício de risco. A análise precisa começar pelos dados da própria operação — não pelos casos de sucesso publicados pelos fornecedores.

Perguntas frequentes

O DBaaS é adequado para empresas que precisam cumprir a LGPD?

Sim, desde que a adoção seja estruturada com atenção a três pontos: a escolha de regiões de processamento e armazenamento dentro do Brasil ou em países com grau de proteção adequado reconhecido pela ANPD, a formalização de um Data Processing Agreement (DPA) com o provedor que cubra as obrigações do operador de dados conforme a LGPD, e o mapeamento de todos os fluxos de dados que saem da região principal — incluindo logs, backups e pipelines de monitoramento. A LGPD não impede o uso de DBaaS; ela define as condições sob as quais esse uso é legal e auditável.

Qual é a diferença prática entre DBaaS e um banco de dados autogerenciado em uma instância de nuvem?

No modelo DBaaS gerenciado — como o Amazon RDS, o Azure SQL Database ou o Google Cloud SQL —, o provedor é responsável pela operação da camada de infraestrutura e do próprio engine de banco de dados: patches de segurança, backups automatizados, failover e, em grau variável, monitoramento de performance. No modelo autogerenciado — uma instância de EC2 ou VM com o banco de dados instalado manualmente —, toda essa responsabilidade permanece com a equipe interna. O modelo autogerenciado oferece maior controle sobre a configuração e frequentemente mais flexibilidade para features avançadas, mas exige um time com disponibilidade e expertise para absorver as tarefas operacionais que o DBaaS elimina.

Como avaliar o risco de lock-in ao adotar DBaaS de um único provedor?

O risco de lock-in no DBaaS tem duas dimensões principais: a técnica e a econômica. A dimensão técnica está no uso de features proprietárias do provedor — tipos de dados, funções nativas, integrações com outros serviços da mesma plataforma — que tornam a migração para outro provedor um projeto de reengenharia, não apenas de movimentação de dados. A dimensão econômica está no custo de egress de dados. Para mitigar esse risco, a estratégia mais eficaz é priorizar engines de código aberto — PostgreSQL e MySQL têm a maior portabilidade entre provedores —, evitar features proprietárias em aplicações com horizonte de longo prazo e manter backups periódicos fora da plataforma do provedor principal. A portabilidade deve ser tratada como um requisito arquitetural desde o início do projeto, não como uma preocupação para o momento em que a troca se tornar necessária.

Como o DBaaS afeta o papel do DBA na estrutura do time de tecnologia?

O DBaaS redistribui o trabalho do DBA, mas raramente o elimina. As tarefas operacionais de baixo valor — aplicação de patches, configuração de backups, provisionamento de instâncias — são absorvidas pelo provedor. O que permanece com a equipe interna, e que ganha importância relativa, é o trabalho de maior complexidade: design de schema, otimização de queries, definição de estratégias de indexação, análise de planos de execução, governança de acesso e planejamento de capacidade. Empresas que adotam o DBaaS esperando reduzir o headcount de banco de dados no curto prazo frequentemente comprometem a performance dos sistemas por ausência de expertise técnica no momento em que ela mais faz falta — durante os picos de uso e nas fases de crescimento acelerado da plataforma.