Glaspoort Trata Bancos de Dados como Computação Efêmera com Lakebase

Glaspoort, uma empresa baseada na Holanda especializada em infraestrutura de fibras, migrou sua pilha de dados de aprendizado de máquina e operacional para produção para o Databricks Lakebase. A empresa utiliza um modelo de branching de banco de dados semelhante ao Git que gera ambientes Postgres descartáveis para cada pull request, tratando migrações de esquema como o único artefato durável.

A pilha opera inteiramente dentro do ecossistema Databricks. Os gerentes de projetos da Glaspoort usam um aplicativo front-end personalizado que aproveita os produtos Databricks: Genie para análise conversacional, AI/BI Dashboards para visualização e Agent Bricks para alertas de fluxo de trabalho automatizado. Lakebase, um Postgres OLTP sem servidor, opera ao lado do lakehouse, sincronizando dados curados em uma branch de produção Lakebase onde reside em um esquema de aplicativo somente leitura. O aplicativo grava seu estado transacional em um esquema separado na mesma branch, garantindo que os dados do lakehouse e os dados gravados pelo aplicativo coexistam sem conflito.

O branching do Lakebase é central ao sistema. Uma branch é uma branch Postgres copy-on-write de um pai, criada sem copiar dados, portanto, bifurcando o estado de forma barata e instantânea. Cada branch tem seu próprio endpoint e dados isolados, alinhando uma branch de recurso no código com uma branch de recurso no banco de dados. Glaspoort mantém três ambientes lógicos - desenvolvimento, aceitação e produção - mas a topologia do branching é crucial. Para evitar a armadilha "redefinir a partir do pai", onde atualizar um ambiente obsoleto requer a exclusão e a reconstrução de tudo o que está abaixo, Glaspoort brancha dev e aceitação diretamente da produção, em vez de empilhá-los uns sobre os outros.

Cada pull request na Glaspoort dispara uma branch Lakebase descartável a partir da produção. As migrações são reproduzidas em uma imagem de aplicativo ao vivo em isolamento, provando a mudança no esquema antes de tocar em qualquer ambiente compartilhado. O pipeline é otimizado para velocidade, com PRs se fundindo assim que o CI passa e a promoção de aceitação à produção ocorrendo imediatamente após. Duas proteções garantem segurança: a revalidação da pilha reexecuta os PRs restantes abertos na branch principal atualizada para capturar conflitos de migração entre branches antes de atingirem a aceitação, e um pipeline de crise dedicado fornece um caminho rápido para a produção para hotfixes que não podem esperar pela validação de aceitação completa. A infraestrutura como código gerencia strings de conexão e concessões, persistindo através de destruições e renascidos de branches.

O estudo de caso do Databricks carece de métricas de desempenho específicas, como latência de consulta p50/p99, transações por segundo, custo por milhão de consultas ou preços de armazenamento para o Lakebase, obrigando arquitetos a executar seus próprios testes de carga ao compará-lo com o AlloyDB, Aurora ou Postgres autogerenciado. A restrição "excluir para redefinir" representa um retrocesso significativo na operação em relação ao modelo de rebase do Git. Ignorar a topologia pode levar a ambientes de desenvolvimento desviando-se da produção e pipelines de CI travando em exclusões em cascata. Além disso, cada migração deve permanecer compatível com versões anteriores com o esquema de produção enquanto o aplicativo atende ao tráfego ao vivo, pois o banco de dados é um artefato efêmero que é reconstruído e descartado diariamente. O estudo de caso também não divulga o tempo necessário para reidratar grandes branches irmãos ou se as penalidades de copy-on-write se manifestam como picos de latência sob carga de transações intensa.

Os arquitetos devem considerar o tratamento do banco de dados como computação efêmera, branchando irmãos diretamente da produção para evitar armadilhas de exclusão em cascata e promovendo migrações, e não esquemas, como a fonte durável da verdade.