Bastidores do Lakebase, parte 2

Em parte 1 desta série, exploramos como mover o banco de dados subjacente do Backstage para o Databricks Lakebase transformou migrações de esquema arriscadas em operações de branch e teste de 1 segundo. Mas um ciclo de desenvolvimento mais rápido só leva você até certo ponto se as equipes de Segurança e Governança ainda tratarem seu banco de dados operacional como uma caixa preta.

Em uma pilha tradicional, seu banco de dados de aplicação e seu data lake vivem em dois paradigmas de segurança completamente diferentes. O grafo de propriedade da sua infraestrutura vive no Backstage, suportado por uma instância RDS isolada e governado por complexas funções IAM e concessões nativas do Postgres. Enquanto isso, os dados do seu warehouse são governados pela equipe de dados usando o Unity Catalog. Unity Catalog é um framework Open Source criado pela Databricks que fornece uma camada de governança unificada para dados, IA e agora bancos de dados operacionais – um único local para gerenciar controles de acesso, trilhas de auditoria, linhagem e conformidade em tudo na plataforma.

Para auditar a exclusão de uma única tabela no RDS, você precisaria cruzar o CloudTrail para o principal IAM, pg_stat_activity ou pgaudit logs para a instrução SQL e o CloudWatch para o timestamp, três serviços, três linguagens de consulta, três políticas de acesso. O banco de dados operacional se torna um canal lateral de conformidade.

Unity Catalog Absorve o Banco de Dados Operacional

Quando apontamos o Backstage para o Lakebase, não mudamos apenas onde os dados viviam; mudamos onde a política de acesso vivia.

Como o Lakebase é nativamente incorporado ao Databricks, o Unity Catalog se estende diretamente sobre o banco de dados Postgres operacional. Neste POC, usamos o Lakehouse Federation para expor o catálogo do Backstage como um catálogo externo (lakebase_bs) no Unity Catalog. Uma vez lá, as concessões padrão do UC controlam quem pode ver o quê, sem necessidade de gerenciamento de função em nível de Postgres:

Embora não tenhamos construído políticas de segurança em nível de linha (RLS) de ponta a ponta para o Backstage neste POC, arquiteturalmente, as mesmas regras de RLS que protegem tabelas de faturamento sensíveis podem ser aplicadas diretamente a essas tabelas operacionais. A barreira entre "operacional" e "analítico" deixa de ser um limite físico e se torna simplesmente um padrão de acesso.

Uma Trilha de Auditoria Unificada Pronta para Uso

Lembra do branching copy-on-write de 1 segundo que executamos na Parte 1? Em uma configuração tradicional, provar a um engenheiro de segurança que um desenvolvedor apenas fez o branch do banco de dados por uma hora e depois o destruiu é um exercício manual.

Com o Lakebase, cada ação do plano de controle contra o banco de dados operacional é automaticamente registrada no system.access.audit. Para provar isso, consultamos o log de auditoria para as operações exatas de branch de nosso experimento de recuperação de desastres da Parte 1:

Resultado:

Cada criação e exclusão de branch de nossos experimentos da Parte 1 é registrada. Cada evento está vinculado a uma identidade de usuário OAuth específica e IP de origem, capturado automaticamente e governado pelos mesmos controles de segurança em nível de linha (RLS) de todas as outras tabelas de auditoria no Unity Catalog. Sem cruzamento do CloudTrail. Sem análise de logs do RDS. Uma consulta SQL.

Atribuição de Custo Automatizada por Branch

Uma equipe de governança não quer apenas saber quem criou um branch, eles querem saber quanto custou.

Em um ambiente AWS tradicional, rastrear o custo de uma instância RDS efêmera requer estratégias personalizadas de marcação do CloudWatch que muitas vezes perdem cargas de trabalho de curta duração. Como o Lakebase se integra nativamente às tabelas de faturamento do sistema do Unity Catalog, os custos de computação são detalhados automaticamente por project_id, branch_id e endpoint_id.

Neste POC, o branch de produção foi cobrado em 31.6130 DBU, enquanto o branch de teste excluído foi atribuído independentemente 0.0107 DBU. A trilha de auditoria e a trilha de custo são governadas exatamente no mesmo lugar.

O Que Isso Significa para Equipes Que Fazem Branch Todos os Dias

Nossa história de governança responde à pergunta de conformidade: podemos provar quem fez o quê, quando e quanto custou? A resposta é sim – uma consulta SQL em vez de três serviços. Mas há uma segunda pergunta de governança que importa tanto quanto para as equipes de desenvolvimento que adotam o fluxo de trabalho de branching da Parte 1: o que acontece com a governança quando sua equipe cria dezenas de branches por sprint?

Na Parte 1, descrevemos um fluxo de trabalho onde cada branch de recurso e cada pull request recebem sua própria cópia isolada do banco de dados. Uma equipe de seis desenvolvedores executando sprints de duas semanas pode criar e destruir 30-40 branches em um único sprint. Isso são 30-40 cópias de dados de produção, cada uma potencialmente contendo campos sensíveis – PII de clientes, registros financeiros, dados de saúde.

É aqui que a governança em nível de branch do Unity Catalog se torna essencial, não apenas conveniente. Quando um branch do Lakebase é criado, as políticas de mascaramento em nível de atributo do Unity Catalog se propagam automaticamente para o novo branch. Um desenvolvedor trabalhando em seu branch de recurso nunca vê dados de produção não mascarados – não porque alguém se lembrou de configurá-lo, mas porque a camada de governança o impõe no momento da criação. O branch de CI que executa seus testes de PR é governado de forma idêntica à produção. O branch de QA onde um testador executa cenários destrutivos é governado de forma idêntica à produção. Não há "exceção não produtiva" onde dados sensíveis vazam porque alguém esqueceu de aplicar a política.

Isso importa mais do que parece. De acordo com o relatório State of Data Compliance de 2025 da Perforce, 60% das organizações sofreram violações ou roubos em ambientes não produtivos onde dados sensíveis foram anonimizados inadequadamente. A abordagem tradicional – mascarar dados manualmente ao provisionar ambientes de desenvolvimento/teste – não escala quando os ambientes são criados e destruídos em segundos. A governança tem que ser automática, ou não acontece.

A Nova Oportunidade do DBA

A trilha de auditoria e os dados de atribuição de custo também sinalizam uma mudança mais sutil: o papel do DBA está evoluindo do trabalho reativo de tickets para a arquitetura estratégica de plataforma.

Hoje, grande parte do tempo de um DBA é dedicado a solicitações operacionais – provisionamento de ambiente, revisões de esquema, atualizações de dados, concessões de acesso. Uma equipe de seis desenvolvedores pode gerar mais de 30 tickets por sprint, e a agenda do DBA se torna uma fila. A expertise que torna os DBAs valiosos – entender integridade de dados, desempenho e governança em um nível profundo – fica enterrada sob trabalho repetitivo de provisionamento.

Quando o branching é self-service e a governança é automática, esse trabalho repetitivo desaparece. Desenvolvedores provisionam seus próprios ambientes em um segundo. Alterações de esquema são revisadas assincronamente em pull requests – o DBA vê um diff de esquema formatado postado pelo CI, o revisa em sua própria agenda e aprova ou solicita alterações através do fluxo normal de PR. Com o tempo agora disponível, essas revisões se aprofundam: o DBA ajuda os membros da equipe a entender os dados e estruturas existentes em produção, trabalha com eles para chegar a soluções melhores e realiza revisões completas que mantêm os padrões de integridade de dados e governança. A mascaramento de dados é imposto por política, não por intervenção manual. A atribuição de custos é automática, não um exercício de reconciliação mensal.

O que se abre é o trabalho que realmente aproveita a expertise do DBA: definir políticas de branching, projetar regras de governança, arquitetar fluxos de promoção, otimizar desempenho e estabelecer os guardrails que tornam o self-service seguro. O DBA muda de fazer o trabalho para projetar como o trabalho é feito – de mais de 30 tickets operacionais por sprint para menos de 5 revisões de políticas de alto valor. O trilho de auditoria demonstrado acima não é apenas um artefato de conformidade – é o novo painel estratégico do DBA, uma visão em tempo real de como a plataforma está sendo usada e onde investir a seguir.

Da Mudança de Função às Ferramentas

O pivô do DBA de tickets operacionais para design de plataforma só funciona se as ferramentas mudarem com a função. A plataforma tem que fazer o trabalho rotineiro por conta própria, e o DBA precisa de um lugar para projetar como esse trabalho é feito.

Duas ferramentas open-source, ambas implantadas como Databricks Apps e ambas governadas pelas mesmas concessões do Unity Catalog e trilha de auditoria descritas acima, fecham esse ciclo.

LakebaseOps é o que a plataforma faz por conta própria. Três agentes – Provisionamento, Desempenho e Saúde – substituem 51 das tarefas para as quais um DBA costumava abrir tickets. Sete deles rodam como Jobs do Databricks agendados e substituem o crontab pg_cron que um DBA manteria manualmente. Uma UI de monitoramento apresenta métricas pg_stat ao vivo, regressões de consultas lentas, aplicação de TTL de branch e um painel de adoção de 9 KPIs. Um assistente de migração pontua dez motores de origem (Aurora, RDS, Cloud SQL, AlloyDB, Cosmos DB e mais) contra o Lakebase, com preços ao vivo das APIs AWS e Azure.

Lakebase MCP é o que o DBA faz em cima da plataforma. Um servidor Model Context Protocol expondo 46 ferramentas para qualquer agente de IA capaz de MCP (Claude, Copilot, GPT). O DBA para de abrir o pgAdmin e começa a descrever a intenção:

Duas escolhas de design mantêm isso seguro. Primeiro, governança de dupla camada: um guardião de instrução SQL e um guardião de acesso por ferramenta, com quatro perfis pré-construídos (somente leitura, analista, desenvolvedor, administrador) que se mapeiam nos mesmos padrões de acesso UC mostrados acima. Um assistente de codificação roda como read_only e fisicamente não pode dropar uma tabela.

Segundo, cada consulta é atribuível – o servidor marca cada instrução com a ferramenta de origem:

Combinado com a atribuição de custos em nível de branch mostrada anteriormente, você pode responder "qual agente em qual branch gerou o pico de CPU das 4 da manhã?" em uma única consulta SQL.

LakebaseOps roda para a equipe. Lakebase MCP roda com a equipe. Ambos herdam a postura de governança que você acabou de ver.

Na Parte 3 desta série, veremos o benefício final: pegar os dados de propriedade da infraestrutura dentro do Backstage e uni-los diretamente aos dados de faturamento da nuvem em uma única consulta SQL.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original