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.