por Bryan Smith
nOps, um parceiro Databricks Built On que gerencia mais de US$ 4 bilhões em gastos anuais com nuvem, migrou sua aplicação de produção para o Databricks Lakebase. O resultado foi uma arquitetura mais rápida e simples que eliminou a "cola" entre sua aplicação e sua análise de dados, e um guia para ISVs que buscam fazer o mesmo.
Todo ISV que constrói no Databricks eventualmente atinge o mesmo ponto de inflexão arquitetônico: suas análises de dados residem no Lakehouse, mas sua aplicação precisa de um banco de dados relacional para leituras e gravações de baixa latência. Então, você adiciona uma instância Postgres separada (talvez RDS, talvez algo autogerenciado) e, de repente, você está mantendo pipelines ETL, jobs cron e lógica de detecção de alterações apenas para manter dois sistemas sincronizados.
A nOps viveu essa realidade por anos. E então eles encontraram um caminho melhor.
Para quem não conhece, nOps é uma plataforma automatizada de otimização de custos de nuvem que gerencia descontos baseados em compromissos em AWS, GCP e Azure. Sua abordagem é distintamente "sempre ativa". Eles monitoram, compram e trocam compromissos de nuvem em base horária, usando machine learning para equilibrar as taxas de economia efetivas contra o risco de bloqueio de compromisso. O modelo é baseado em desempenho: a nOps cobra apenas uma porcentagem da economia incremental que geram.
É uma operação intensiva em dados. A cada hora, a nOps analisa padrões de uso em milhares de contas de clientes, avalia portfólios de compromissos em três grandes provedores de nuvem e dezenas de serviços, e toma decisões de compra automatizadas. Além disso, eles fornecem visibilidade de custos, previsão e detecção de anomalias por meio de uma plataforma FinOps centralizada.
O backbone analítico para tudo isso tem sido há muito tempo o Databricks Lakehouse. Mas a aplicação front-end, a plataforma na qual os clientes fazem login para ver suas economias, gerenciar orçamentos e explorar dados de custos, precisava de algo mais.
A arquitetura anterior da nOps era um padrão familiar para ISVs no Databricks. Análises avançadas e computação de métricas eram executadas no Lakehouse. Dados voltados para o cliente (configurações de conta, preferências do usuário, estado específico do cliente em rápida mudança) residiam em um banco de dados relacional separado, alimentado por fornecedores terceirizados e soluções próprias.
As emendas entre esses dois sistemas criavam atrito real. Jobs agendados e detecção de alterações baseada em cron eram necessários para manter o banco de dados front-end e o Lakehouse sincronizados. Dados que estavam "ao vivo" em um sistema podiam levar minutos ou mais para aparecer no outro. E a sobrecarga operacional de gerenciar uma pilha de banco de dados separada, com suas próprias preocupações de escalonamento, backup e segurança, desviava o tempo de engenharia do que a nOps realmente faz de melhor: construir automação de compromissos.
Quando a nOps expandiu de cobertura apenas AWS para multi-cloud em GCP e Azure no início de 2026, as cargas de trabalho crescentes sobrecarregaram essa arquitetura. A equipe decidiu reconstruir a plataforma, focando desta vez em sua especialidade e escolhendo infraestrutura que simplesmente funciona.
A nOps selecionou o Databricks Lakebase, um banco de dados PostgreSQL totalmente gerenciado e integrado diretamente ao Lakehouse, como o backbone OLTP para sua nova plataforma.
Jordan Stein, Diretor de Produto na nOps, apontou três fatores que fizeram do Lakebase a escolha certa:
Veja como é a nova arquitetura da nOps:
O Lakebase serve como o banco de dados Postgres central e única fonte de verdade tanto para a aplicação front-end quanto para sua infraestrutura de IA.
O Databricks Lakehouse consome continuamente dados do Lakebase para análise e computação de métricas.
A plataforma nOps descobre e expõe automaticamente Databricks Metric Views, para que métricas padronizadas computadas no Lakehouse apareçam consistentemente no front-end.
Os dados fluem em uma direção, do Lakebase para o Lakehouse para análise, sem necessidade de escrita direta. Isso mantém a arquitetura limpa e a fonte de verdade inequívoca.
O restante da pilha segue a mesma abordagem: Vercel para hospedagem e observabilidade, WorkOS para autenticação e Databricks para tudo relacionado a dados.
Jordan Stein recentemente apresentou a história completa da migração do nOps para o Lakebase em uma apresentação de destaque de parceiro. Assista ao vídeo para saber como foi a transição, o que os surpreendeu sobre o desempenho e como a integração do Lakehouse mudou seus fluxos de trabalho de engenharia de dados:
A história da nOps não é única. Quase todo ISV que constrói no Databricks enfrenta a mesma tensão entre OLTP e análise. O que vale a pena prestar atenção é como o Lakebase resolve isso de forma tão limpa.
Elimine o imposto de sincronização. O código mais caro em qualquer pilha de ISV é frequentemente o código que move dados entre sistemas. A integração nativa do Lakebase com o Unity Catalog e a sincronização Delta Lake com um clique substituem pipelines ETL personalizados por infraestrutura gerenciada. Isso é tempo de engenharia que você recupera.
Um modelo de governança. Quando seu banco de dados OLTP é registrado como um ativo do Unity Catalog, você obtém governança unificada, linhagem e controle de acesso em dados operacionais e analíticos. Chega de gerenciar políticas de segurança em dois lugares.
Compatibilidade com Postgres significa reescrita zero. O Lakebase é PostgreSQL totalmente gerenciado. Suas bibliotecas existentes, ORMs e ferramentas SQL funcionam imediatamente. Extensões como pgvector e PostGIS são suportadas. Você migra apontando sua aplicação para uma nova string de conexão, não reescrevendo consultas.
Economia de escala que faz sentido. Preços baseados no uso com escala para zero significam que você não está pagando por capacidade ociosa. Para ISVs com cargas de trabalho variáveis (e qual ISV não tem cargas de trabalho variáveis?) isso impacta diretamente a economia unitária.
Entregue mais rápido. Quando o banco de dados da sua aplicação e seu data warehouse são a mesma plataforma, uma categoria inteira de trabalho de integração desaparece. Sua equipe entrega recursos em vez de manter a infraestrutura.
A nOps é um bom exemplo do que é um parceiro Built On inovador. Em vez de esperar o Lakebase amadurecer através de múltiplos ciclos de lançamento, eles reconheceram o encaixe arquitetônico cedo, comprometeram-se com uma migração de produção e já estão vendo resultados: pipelines de dados mais rápidos, menor sobrecarga operacional e uma melhor experiência para seus clientes.
Essa disposição de agir cedo também é estrategicamente inteligente. Ao construir no Lakebase agora, a nOps tem uma integração mais estreita com a plataforma Databricks do que concorrentes que ainda estão juntando pilhas de banco de dados separadas. Sua plataforma é mais simples de operar e mais rápida de estender.
Explore o Lakebase. Se você é um ISV construindo no Databricks, ou considerando isso, saiba mais sobre o Lakebase e como ele pode simplificar sua arquitetura.
Explore a nOps. Se sua organização busca reduzir custos de nuvem em AWS, GCP ou Azure sem o risco de compromisso, visite a nOps para ver como sua plataforma de otimização automatizada, agora alimentada pelo Databricks Lakebase, pode ajudar.
(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original
Assine nosso blog e receba os posts mais recentes diretamente na sua caixa de entrada.