Fala pessoal! Tudo bem com vocês? Animados para mais um post???
Recentemente, tive a honra de participar de uma live sensacional no CanaldotNET, ao lado dos meus grandes amigos Renato Groffe e Thiago Bertuzzi. Foram mais de três horas de conversa intensa sobre o ecossistema de dados, as mudanças no papel do DBA e as tendências de IA que estão batendo à nossa porta.
Como o conteúdo foi extremamente denso e rico, resolvi criar este post que é praticamente um resumo do que discutimos, detalhando cada tópico relevante para quem vive o dia a dia da “trincheira” dos dados. Se você quer entender para onde o mercado está indo e como não ficar para trás, este post é para você.
Para quem quiser conferir o vídeo completo e as demonstrações práticas do Renato Groffe e do Bertuzzi, o link é este aqui:
O Quadrado de Ouro dos Bancos de Dados (0:15:20)
Começamos o papo desmistificando o surgimento de novos bancos de dados a cada semana. Embora tecnologias como SurrealDB ou CockroachDB tragam inovações interessantes, o mercado corporativo de missão crítica ainda é dominado pelo que eu chamo de “Quadrado de Ouro”: SQL Server, Oracle, MySQL e PostgreSQL.
Minha visão como DBA é pragmática: surgem modas o tempo todo, mas o mercado de trabalho sólido e os sistemas de missão crítica giram em torno destes 4 principais SGBDs. Muitas vezes, o NoSQL é vendido como substituto do relacional, mas na prática ele costuma servir como uma camada de ingestão rápida ou cache, enquanto a verdade do dado acaba morrendo em um banco relacional robusto por conta da consistência ACID.
O PostgreSQL tem ganhado um destaque absurdo, não só por ser open source, mas pela sua facilidade de extensões. No entanto, o SQL Server continua sendo a ferramenta mais completa em termos de gestão, diagnóstico e integração com o ecossistema Microsoft.
IA e a Ascensão dos Bancos Vetoriais (0:42:15)
Um dos pontos altos da live foi a discussão sobre Vector Stores e Embeddings. Com o avanço das LLMs (como o GPT-4), os bancos de dados agora precisam lidar com dados não estruturados transformados em vetores numéricos para buscas semânticas. IA Generativa não é só chat. Para aplicações reais (RAG – Retrieval-Augmented Generation), precisamos de Vector Stores.
Expliquei como o PGVector deu uma vantagem competitiva ao Postgres, mas destaquei que o SQL Server já está integrando suporte nativo a vetores. Isso permitirá que façamos buscas por “proximidade de significado” diretamente via T-SQL, sem precisar exportar dados para bancos de nicho.
Discutimos também o uso do Semantic Kernel para abstrair essa camada de dados, permitindo trocar o modelo de IA ou o banco de vetores sem precisar reescrever toda a lógica de negócio.
Carreira: O “Fim” do DBA e o Surgimento do Engenheiro de Dados (1:05:40)
Discutimos muito sobre como o papel do DBA tradicional mudou. Hoje, não basta apenas saber instalar o SQL Server e criar usuários. O profissional moderno precisa entender de Infrastructure as Code (IaC), containers e automação.
A linha entre o DBA e o Engenheiro de Dados está cada vez mais tênue. Enquanto o DBA foca na estabilidade e performance da engine, o engenheiro foca na fluidez do pipeline de dados. Mas uma coisa é certa: ambos precisam ser mestres em SQL.
Arquitetura para IoT e Streaming de Dados (1:10:15)
Uma dúvida comum no chat foi sobre onde salvar dados de sensores e IoT. Aqui o segredo não é o banco, é a Arquitetura. Jogar milhões de eventos por segundo direto em uma tabela relacional vai gerar um gargalo de WRITELOG violento.
O fluxo correto geralmente envolve:
- Ingestão via Kafka ou Azure Event Hubs.
- Armazenamento bruto em um Data Lake (ADLS).
- Processamento via Spark (Databricks ou Fabric) em micro-batches.
Séries Temporais com TimescaleDB (1:25:40)
Se o seu problema é especificamente série temporal (Time Series), o TimescaleDB foi muito elogiado. Ele é uma extensão do Postgres que otimiza a escrita e leitura de dados cronológicos, mantendo toda a flexibilidade do SQL.
Outras opções citadas foram o Cosmos DB, Elasticsearch e Redis.
Migração para a Nuvem e o Custo do IOPS (1:32:10)
Falamos sobre os desafios de migrar ambientes On-Premise para o Azure SQL ou AWS RDS. O maior erro que vejo é o “Lift and Shift” sem planejamento de performance.
Na nuvem, IOPS é dinheiro. Se você tem uma consulta mal escrita que faz um Scan em uma tabela de milhões de linhas, você não está apenas deixando o sistema lento; você está queimando o orçamento da empresa. Discutimos ferramentas como o Azure Database Migration Service (DMS) para facilitar esse processo com o mínimo de downtime.
SQL Server Barato na Azure para POCs e MVPs (1:45:10)
Muita gente acha que o Azure SQL é caro, mas mostrei na tela como começar com o modelo de DTU (Basic ou S0). Você consegue um banco SQL Server de verdade, com backup automático e alta disponibilidade, pagando entre R$ 25,00 e R$ 80,00 por mês.
Provisionado vs. Serverless no Azure (2:05:30)
Expliquei a diferença crucial entre esses dois modelos:
- Provisionado: Você reserva o recurso e paga 24×7, uma vez que no caso do Azure SQL Database, não tem opção pra desligar o banco. Ideal para cargas de trabalho constantes.
- Serverless: O banco “pausa” quando ninguém usa. É perfeito para ambientes de teste ou processos de BI que só rodam de madrugada.
Microsoft Fabric e OneLake: A Revolução Analítica (2:05:45)
Entramos a fundo no Microsoft Fabric. A proposta de unificar o storage em um único lugar (OneLake) usando o formato aberto Delta/Parquet é um divisor de águas.
O conceito de Shortcut é fenomenal: você pode “apontar” para dados que estão no S3 da AWS e consultá-los de dentro do Fabric como se fossem tabelas locais, sem precisar mover um único byte fisicamente (zero ETL). Isso resolve o pesadelo da fragmentação de dados em silos.
Mergulhando no Azure Database for PostgreSQL (2:25:15)
Mostrei o provisionamento do Postgres no Azure. Ele segue o modelo PaaS (Platform as a Service), onde você não se preocupa com o sistema operacional.
Vimos os perfis de máquina:
- Burstable: O mais barato, para uso leve e picos ocasionais.
- General Purpose: Equilíbrio entre CPU e memória.
- Memory Optimized: Para bancos que precisam de muito cache (RAM) para performance.
Microsserviços e a Escolha do Banco (2:45:00)
Hoje, o PostgreSQL é o padrão de fato para microsserviços. Ele é leve, robusto e escala muito bem em containers. A recomendação de ouro aqui é o isolamento: tente manter um banco (ou pelo menos um schema/usuário isolado) por microsserviço para evitar que uma query lenta de um serviço derrube todos os outros.
O Perigo do Raspberry Pi como Servidor de Banco (2:55:20)
Surgiu a pergunta: “Posso usar um Raspberry Pi para o banco da empresa?”
A resposta curta é: Não. Para estudo é fantástico, mas para produção você não tem redundância física, os cartões SD falham constantemente sob estresse de I/O e você não tem uma estratégia de backup gerenciada. O custo de um Azure SQL Basic é menor que o risco de perder seus dados.
Carreira e Certificações (3:05:45)
Para quem quer se destacar na área de dados, recomendei dois caminhos da Microsoft:
- DP-900 (Azure Data Fundamentals): Para quem quer a base de tudo (Relacional, NoSQL, Data Lake).
- DP-300 (Administering Azure SQL Solutions): Para quem já tem experiência e já trabalha administrando bancos de dados na nuvem.
Conclusão
A live foi uma verdadeira maratona de conteúdos voltados para a área de dados, mas o recado final é simples: a tecnologia evolui rápido, mas os fundamentos de dados são eternos. Seja no SQL Server, Oracle, MySQL ou PostgreSQL, quem entende como o dado é processado sempre terá espaço no mercado.
Espero que tenham gostado dessa dica, um grande abraço e até a próxima!
Portuguese 
English