DBaaS é o modelo em que o provedor instala, opera e mantém o banco de dados — o cliente define o mecanismo, o tamanho e conecta a aplicação. Instalação, patching, backup automático e alta disponibilidade são responsabilidade do provedor. O cliente gerencia esquemas, dados e usuários de banco.
O que muda na prática com DBaaS
Operação tradicional de banco de dados envolve uma sequência longa de responsabilidades: instalar o SGBD, configurar o sistema de arquivos, dimensionar storage, configurar réplicas de leitura, implementar backup automático, monitorar espaço em disco, aplicar patches de segurança do banco, gerenciar failover e — em produção — acordar às 3h quando o disco enche ou a réplica fica para trás.
Com DBaaS, o provedor assume essa pilha inteira. Você recebe um endpoint de conexão. A aplicação conecta como faria com qualquer banco de dados — a string de conexão muda, o código não.
O que o cliente ainda gerencia:
- Modelagem de dados e esquemas
- Queries e índices (otimização é sua responsabilidade)
- Usuários e permissões de banco
- Configuração de parâmetros de banco (dentro dos limites que o provedor expõe)
- Custo de armazenamento e compute conforme os dados crescem
Exemplos por tipo de banco
Bancos relacionais (SQL)
| Serviço | Provedor | Motor |
|---|---|---|
| Amazon RDS | AWS | MySQL, PostgreSQL, MariaDB, Oracle, SQL Server |
| Amazon Aurora | AWS | MySQL e PostgreSQL compatível, motor próprio |
| Azure SQL Database | Microsoft | SQL Server gerenciado |
| Azure Database for PostgreSQL | Microsoft | PostgreSQL |
| Cloud SQL | Google Cloud | MySQL, PostgreSQL, SQL Server |
| AlloyDB | Google Cloud | PostgreSQL compatível, motor próprio |
Bancos NoSQL
| Serviço | Provedor | Tipo |
|---|---|---|
| Amazon DynamoDB | AWS | Chave-valor / documento |
| Azure Cosmos DB | Microsoft | Multi-modelo (documento, grafo, chave-valor) |
| Google Firestore | Documento | |
| MongoDB Atlas | MongoDB Inc. | Documento |
Cache em memória
| Serviço | Provedor | Motor |
|---|---|---|
| Amazon ElastiCache | AWS | Redis, Memcached |
| Azure Cache for Redis | Microsoft | Redis |
| Google Memorystore | Google Cloud | Redis, Memcached |
Analytics e data warehouse
| Serviço | Provedor | Uso principal |
|---|---|---|
| Amazon Redshift | AWS | Data warehouse colunar |
| Google BigQuery | Analytics serverless | |
| Azure Synapse Analytics | Microsoft | Data warehouse + analytics integrado |
| Snowflake | Snowflake | Multi-cloud data platform |
Vantagens do DBaaS
Alta disponibilidade automática: Multi-AZ e failover automático são configurações de alguns cliques. Em banco autogerenciado, implementar réplica síncrona com failover transparente é semanas de projeto.
Backup automático com point-in-time recovery: A maioria dos DBaaS oferece backups automatizados e restauração para qualquer ponto no tempo dentro da janela de retenção configurada. Em banco próprio, implementar isso de forma confiável exige infraestrutura adicional.
Escala sem downtime: Aumentar a instância (vertical) ou adicionar réplicas de leitura (horizontal) geralmente sem interrupção ou com janela mínima.
Patches de segurança aplicados pelo provedor: Atualizações do motor do banco — incluindo patches de vulnerabilidade — são gerenciadas pelo provedor, com opção de janela de manutenção configurável.
Monitoramento integrado: Métricas de conexões ativas, latência de queries, uso de CPU e storage disponíveis por padrão. Em banco self-managed, você monta o stack de monitoramento.
Cuidados críticos que precisam ser gerenciados
Vendor lock-in de banco
Este é o risco mais subestimado. Amazon Aurora e Google AlloyDB são “compatíveis com PostgreSQL”, mas têm extensões proprietárias, comportamentos específicos e APIs de administração exclusivas do provedor. Uma aplicação que usa recursos específicos do Aurora — como Aurora Serverless v2 com auto-pause ou Aurora Global Database — não migra para PostgreSQL padrão sem trabalho de adaptação.
Escolha entre:
- Usar apenas o subconjunto padrão do motor (PostgreSQL puro, MySQL puro) mesmo em DBaaS — mantém portabilidade
- Usar recursos proprietários consciente do lock-in — com plano de saída documentado
Egresso de dados
Mover dados para dentro do provedor cloud é barato ou gratuito. Mover para fora (egresso) tem custo — e esse custo cresce com o volume. Uma aplicação que processa e exporta grandes volumes de dados pode ter surpresas na fatura de egresso, especialmente em analytics.
Planeje a arquitetura considerando onde os dados gerados precisam ir: se o destino final está fora do provedor, calcule o custo de egresso antes de adotar o DBaaS.
LGPD quando o banco está fora do Brasil
Este ponto é crítico para empresas sujeitas à LGPD. O banco de dados frequentemente é onde dados pessoais ficam concentrados — nomes, CPFs, endereços, dados de saúde, dados financeiros.
Se o DBaaS está em região fora do Brasil:
- A transferência internacional de dados pessoais exige salvaguardas legais (cláusulas contratuais padrão, DPA, adequação do país receptor)
- O controlador (sua empresa) é responsável perante a ANPD — não o provedor cloud
- Em caso de incidente, a comunicação ao titular e à ANPD é obrigação sua
AWS, Azure e Google Cloud têm regiões no Brasil (São Paulo). Usar a região correta e verificar a localização de backups (que podem ser replicados para outras regiões por padrão) são verificações obrigatórias.
Custo de armazenamento em escala
DBaaS cobra separadamente pelo compute (instância) e pelo storage. À medida que os dados crescem, o custo de storage cresce linearmente — sem a opção de usar disco mais barato que você compraria em hardware próprio. Para bases de dados muito grandes com crescimento contínuo, o custo de storage do DBaaS pode ser relevante no TCO.
Quando DBaaS compensa vs. banco autogerenciado
| Situação | DBaaS | Banco autogerenciado |
|---|---|---|
| Equipe sem DBA dedicado | Recomendado fortemente | Risco operacional alto |
| Startup ou produto em crescimento | Recomendado — foco no produto | Overhead desnecessário |
| Alta disponibilidade exigida sem equipe de SRE | Recomendado | Complexo de implementar corretamente |
| Base de dados muito grande (>10 TB) | Avaliar custo de storage | Pode ser mais econômico |
| Requisitos de compliance com localização de dados | Verificar região disponível | Controle total da localização |
| Banco com configurações muito específicas de kernel/SO | Limitado pelo provedor | Necessário |
| Migração de banco legado com extensões proprietárias | Verificar compatibilidade | Mais seguro |
| Analytics em alta escala com grande egresso | Cuidado com custo de egresso | Pode ser mais econômico |
A regra geral: se sua equipe não tem um DBA experiente, DBaaS elimina riscos operacionais reais. Se você tem escala muito grande, custos previsíveis e expertise interna, banco autogerenciado pode ser mais econômico.
A Adentro oferece infraestrutura de cloud privada no Brasil para hospedar bancos de dados com soberania de dados, SLA 99,99% e suporte técnico 24/7 em português — sem preocupações com LGPD e egresso internacional. Fale com um especialista.